web-dev-qa-db-ja.com

SSL-共通名（CN）とサブジェクトの別名（SAN）はどのように連携しますか？

SSL証明書のサブジェクトの別名（SAN）プロパティに2つのDNS名が含まれると仮定する

  1. domain.tld
  2. Host.domain.tld

ただし、共通名（CN）は両方の一方のみに設定されます：CN=domain.tld。

  • このセットアップには特別な意味がありますか、または両方のCNを設定する上での[不利な]利点はありますか？
  • サーバー側で何が起こるか、もう一方、Host.domain.tld、要求されていますか？

編集：

Eugeneの答えで最近わかったように、動作は実装によって異なるため、より具体的になりたいと思います：OpenSSL 0.9.8b +はどのように特定のシナリオを処理しますか？

sslhttpsssl-certificate
67
Jürgen Thelen

これは実装に依存しますが、一般的な規則は、ドメインがすべてのSANおよび共通名に対してチェックされることです。そこにドメインが見つかった場合、証明書は接続に問題ありません。

RFC 528 、セクション4.1.2.6には、「サブジェクト名は、サブジェクトフィールドおよび/またはsubjectAltName拡張で伝達される場合があります」と書かれています。つまり、ドメイン名は、証明書のSubjectAltName拡張機能とSubjectプロパティ（つまり、共通名パラメーター）の両方に対してチェックする必要があります。これらの2つの場所は互いに補完するものであり、複製することはできません。また、SubjectAltNameは、www。domain.comまたはwww2。domain.comなどの追加の名前を置く適切な場所です

更新： RFC 6125 に従い、 '2011年に公開されたバリデーターは、SAN最初にチェックし、SANが存在する場合、CN RFC 6125は比較的最近のものであり、CNの「メイン」ドメイン名とSANの代替ドメイン名を含む証明書とCAがまだ存在していることに注意してください。 SANが存在する場合、それ以外の場合は有効な証明書を拒否できます。

71
Eugene Mayevski 'Allied Bits

完全に正確にするには、すべての名前をSANフィールドに入力する必要があります。

CNフィールドにはドメイン名ではなくサブジェクト名を含める必要がありますが、NetscapeがこのSSLのことを発見したとき、彼らはその最大の市場を定義するのを逃しました。サーバーURLに証明書フィールドが定義されていません。

これは、ドメインをCNフィールドに入れるために解決され、今日ではCNフィールドの使用は非推奨ですが、まだ広く使用されています。 CNは1つのドメイン名のみを保持できます。

これに関する一般的なルール：CN-メインURLをここに配置します（互換性のため）SAN-ここにすべてのドメインを配置し、CNを繰り返します。 ...

正しい実装が見つかった場合、質問に対する答えは次のようになります。

  • このセットアップには特別な意味がありますか、または両方のCNを設定する上での[不利な]利点はありますか？ CNは1つの名前しか保持できないため、両方のCNを設定することはできません。 1つのCN + SAN証明書の代わりに2つの単純なCN証明書で作成できますが、これには2つのIPアドレスが必要です。

  • 他のHost.domain.tldが要求されている場合、サーバー側で何が起こりますか？サーバー側で何が起こるかは関係ありません。

つまり、ブラウザークライアントがこのサーバーに接続すると、ブラウザーは暗号化されたパッケージを送信します。このパッケージは、サーバーの公開キーで暗号化されます。サーバーはパッケージを復号化し、サーバーが復号化できる場合、サーバー用に暗号化されました。

接続を介してIPアドレスのみが暗号化されないため、サーバーは復号化する前にクライアントから何も知りません。これが、2つの証明書に2つのIPが必要な理由です。 （SNIを忘れてください、XPまだまだあります。）

クライアント側では、ブラウザはCNを取得し、すべてがチェックされるまでSAN。名前のいずれかがサイトに一致する場合、URL検証はブラウザによって実行されました。証明書の検証について話していません。もちろん、毎回多くのocsp、crl、aiaの要求と回答がネット上を移動します。

42
Viktor Varga

CABForumベースライン要件

ベースライン要件のセクションについては誰もまだ言及していません。それらは重要だと思います。

Q：SSL-共通名（CN）とサブジェクトの別名（SAN）はどのように連携しますか？
A：まったくありません。 SANがある場合、CNは無視できます。 -少なくとも、チェックを行うソフトウェアがCABForumのベースライン要件に非常に厳密に準拠している場合。

（つまり、これはあなたの質問の「編集」に答えることができないことを意味します。元の質問のみです。）

CABForumベースライン要件、v。1.2.5（2015年4月2日現在）、9-10ページ ：

9.2.2サブジェクト識別名フィールド
a。サブジェクト共通名フィールド
証明書フィールド：subject：commonName（OID 2.5.4.3）
必須/オプション：推奨されていません（推奨されませんが、禁止されていません）
Contents：存在する場合、このフィールドには、単一のIPアドレスまたはに含まれる値の1つである完全修飾ドメイン名が含まれなければなりません証明書のsubjectAltName拡張（セクション9.2.1を参照）。

編集：@Brunoのコメントからのリンク

RFC 2818：HTTP Over TLS、2000、 セクション3.1：サーバーID =：

DNSName型のsubjectAltName拡張が存在する場合、それをIDとして使用する必要があります。それ以外の場合、証明書のSubjectフィールドの（最も具体的な）Common Nameフィールドを使用する必要があります。共通名の使用は既存の慣習ですが、廃止されており、代わりにdNSNameを使用することを証明機関に推奨します。

RFC 6125：X.509（PKIX）を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証トランスポート層セキュリティ（TLS）のコンテキストでの証明書、2011、 セクション6.4.4：共通名の確認 ：

[...]提示された識別子に、クライアントがサポートするDNS-ID、SRV-ID、URI-ID、またはアプリケーション固有の識別子タイプが含まれていない場合にのみ、クライアントは最後の手段として件名フィールドの一般名フィールドの完全修飾DNSドメイン名（CN-IDなど）の形式と一致する形式の文字列。

10
StackzOfZtuff