web-dev-qa-db-ja.com

SANとSNI SSL証明書の違いは何ですか?

誰かが私にこれらの証明書の違いを簡単に説明できますか?私はいくつかの記事を読みましたが、それらは同じ仕事、つまり1つの証明書で多くのドメインを暗号化しているようです。

22
AFA Med

[〜#〜] san [〜#〜](件名の別名)は X509証明書 仕様の一部で、ここで証明書には、サブジェクトに対しても有効な代替名のリストを含むフィールドがあります(単一の共通名/ CNに加えて)。このフィールドとワイルドカード名は、基本的に1つの証明書を複数の名前に使用する2つの方法です。

[〜#〜] sni [〜#〜](サーバー名表示)は TLSプロトコル拡張 ですHTTPホストヘッダーに相当するTLSプロトコル。クライアントがこれを送信すると、サーバーは、サーバー側で個別のIPアドレスを使用するという制限なしに、適切な証明書を選択してクライアントに提示できます(プレーンHTTPでHTTPホストヘッダーが頻繁に使用される方法と同様)。

SNIは証明書に反映されるものではなく、実際に質問が求めるものとは正反対のことを実現することに注意してください。 1つの証明書をさまざまな目的で使用するのではなく、多数の証明書を持つことを簡素化します。

一方、実際にどのパスが望ましいかは状況に大きく依存します。例として、質問が求めることは、ほぼ確実に、異なるエンティティの証明書が必要な場合に実際に必要なものではありません。

38

[〜#〜] san [〜#〜]Subject Alternative Nameを表し、x509証明書プロパティであり、 [〜#〜] sni [〜#〜]は、SSL/TLSクライアントがサポートできる機能であるため、完全に異なるエンティティです。

[〜#〜] san [〜#〜]で証明書を使用すると、クライアントが[〜#をサポートしていない場合でも、1つのIPアドレスで複数のHTTPS対応サイトをホストできます〜] sni [〜#〜]。この場合、すべてのサイトに対して1つの証明書を保持し、そのような証明書にはすべてのサイト名(Apache座標ではServerNamesまたはServerAliases、またはNginxではserver_name)が含まれている必要があります)SANsのままです。これは、「個別のIPアドレスごとに1つのHTTPS対応サイト」を拡張した従来のアプローチのサブセットです。現在、大きなCDNのみ[〜#〜] san [〜#〜]が付いています。

[〜#〜] sni [〜#〜]を使用して、1つのIPで複数のHTTPS対応サイトをホストすることもできます。サイトごとに個別のx509証明書を保持し、これらのいずれも、 [〜#〜] san [〜#〜]プロパティですが、TLSクライアント(つまり、wgetcurlなどのブラウザおよびコンソールクライアント)はサポートする必要があります- [〜#〜] sni [〜#〜]。最後のOSがサポートしていない[〜#〜] sni [〜#〜]そのままでWindowsだったため、これは最新のアプローチでしたWindows XP with IE 6.x、覚えていれば。今日では[〜#〜] san [〜#〜]プロパティを見ると、wildcard証明書-たとえば、このような*.example.comの証明書には、共通名of *.example.comおよび[〜#〜] san [〜#〜] of example.com

15
drookie

これは、証明書プロセスの2つの部分を混合します。

SANはサブジェクトの別名です。これは、複数のドメインに対して1つの証明書を作成する方法です。証明書のSANフィールドに、証明書が必要な他のドメインを追加するだけです。その後、ブラウザはこれらのドメインの有効性も受け入れます。

SNIはサーバー名表示であり、SSLの一部です。目的のサーバー名はSSLハンドシェイクで送信され、サーバーは回答に正しい証明書を選択できるため、1つのIPで複数のSSLサイトをホストできます。

4

ここで(おそらく)より人間が読める答え:

SNIはクライアント側で行われ、TLSスタックに「[サーバーX]という名前のサーバーと通信したい」と伝えます。サーバーはこの[サーバーX]文字列を確認し、適切な証明書で応答します。 1つの実用的な例は、単一のサーバーが複数のドメインのトラフィックを処理する必要がある場合です。 (DNSルックアップの遅延を回避するために)クライアントがIPを使用したが、証明書CNがIPについて言及していない場合にも役立ちます。

SANは、証明書の「別名」のリストです。この方法では、サーバーは多くの名前に対して単一の証明書を使用できます。多くのドメインを同じ証明書に追加したり、IPのリストを追加したりすることもできます。

ご覧のように、物事は重なり合っています。 1つまたは両方を選択するかどうかは、制御できる場所によって異なります。一部のクライアントは、SAN=で名前を認識しない場合があり、SNIに基づいて適切な証明書を提供することでアドレスを指定する唯一の方法です。単一の証明書にAPIを提供するサーバーまたはクライアントがSNIを送信しないシナリオがあります。これらの場合、SANが唯一の解決策です。

私の会社は両方を利用しています。それらは柔軟性を提供し、後方互換性と前方互換性を容易にします。

0
Igor Gatis