回答:
SAN（サブジェクトの別名）はX509証明書仕様の一部であり、証明書には、サブジェクトにも有効な代替名のリストを持つフィールドがあります（単一の共通名/ CNに加えて）。このフィールドとワイルドカード名は、基本的に、1つの証明書を複数の名前に使用する2つの方法です。
SNI（サーバー名表示）は、HTTPホストヘッダーに相当するTLSプロトコルの一種であるTLSプロトコル拡張です。クライアントがこれを送信すると、サーバーは、サーバー側で個別のIPアドレスを使用するという制限を受けることなく、クライアントに提示する適切な証明書を選択できます（HTTPホストヘッダーがプレーンHTTPで頻繁に使用される方法と同様）。
SNIは証明書に反映されるものではなく、実際に質問が求めるものとは反対のことを実現することに注意してください。1つの証明書を多くの目的に使用するのではなく、多くの証明書を持つことが簡単になります。
一方、それは実際にどのパスが望ましいかによって大きく異なります。例として、さまざまなエンティティの証明書が必要な場合、質問で求められるのは、実際に必要なものではありません。
SANは、の略サブジェクトの別名、それはx509証明書のプロパティだし、SNIは全く異なるエンティティしたがって、SSL / TLSクライアントがサポートできる機能です。
SANで証明書を使用すると、クライアントがSNIをサポートしていない場合でも、1つのIPアドレスで複数のHTTPS対応サイトをホストできます。この場合、すべてのサイトに対して1つの証明書を保持し、その証明書にはすべてのサイト名（Apache座標ServerNameのsまたはServerAliases、またはserver_namenginxのSAN）が含まれている必要があります。これは、「個別のIPアドレスごとに1つのHTTPS対応サイト」を拡張したレガシーアプローチのサブセットです。現在、大きなCDNのみがSANに固執しています。
使用SNIをあなたもホスト複数のIP上のサイトをHTTPSに対応することができ、各サイトに別々のx509証明書を保持し、これらはその内の他のサイト名言及もないのSANのプロパティを、しかし、TLSクライアント（つまりブラウザとコンソールクライアントのようなwgetやcurl）SNIをサポートする必要があります。正しく覚えていれば、これは最新のアプローチです。SNIをすぐにサポートしていない最後のOSはIE 6.xを搭載したWindows XPでした。今では見ることができるのSANあなたが購入した場合の特性を、ワイルドカード証明書を-例えばこのような証明書が*.foobar.com含まれています共通名の*.foobar.comとSANのをfoobar.com。
これにより、証明書プロセスの2つの部分が混在します。
SANはサブジェクトの別名です。これは、複数のドメインに対して1つの証明書を作成する方法です。証明書のSANフィールドに、証明書が必要な他のドメインを追加するだけです。ブラウザは、これらのドメインの有効性も受け入れます。
SNIはサーバー名表示であり、SSLの一部です。目的のサーバー名がSSLハンドシェイクで送信され、サーバーが答えに正しい証明書を選択できるため、単一のIPで複数のSSLサイトをホストできます。
ここで、（おそらく）より人間が読める答え：
SNIはクライアント側で実行され、TLSスタックに「[サーバーX]という名前のサーバーと通信したい」と伝えます。サーバーはこの[Server X]文字列を見て、適切な証明書で応答します。1つの実用的な例は、単一のサーバーが複数のドメインのトラフィックを処理する必要がある場合です。クライアントが（DNSルックアップの遅延を避けるために）IPを使用したが、証明書CNがIPに言及していない場合にも役立ちます。
SANは、証明書の「別名」のリストです。この方法では、サーバーは多くの名前に対して単一の証明書を使用できます。同じ証明書に多数のドメインを追加し、IPのリストを追加することもできます。
ご覧のとおり、物事は重複しています。どちらかまたは両方を選択するかどうかは、どこで制御できるかによって異なります。一部のクライアントは、SAN内の名前を認識せず、SNIに基づいて適切な証明書を提供することによる唯一の対処方法です。サーバーが単一の証明書にAPIを提供するシナリオ、またはクライアントがSNIを送信しないシナリオがあります。これらの場合、SANが唯一の解決策です。
私の会社は両方を利用しています。それらは柔軟性を提供し、後方および前方互換性を容易にします。