web-dev-qa-db-ja.com

ChromeおよびFirefoxがOpenSSLとは異なるサーバー証明書および発行元を報告するのはなぜですか？

ChromeまたはFirefoxを使用してhttps://somesite.orgにアクセスし、サーバー証明書を検査すると、すべて問題ないように見えます。

SSLサーバー証明書、CN、O、OUがthawte SSL CA-G2によって発行されたsomesite.orgと一致しているようです。

しかし（ここで私はこれが初めてであることを明らかにします）

openssl s_client -connect somesite.org:443 -showcerts

私は非常に異なる何かを得ます：

depth=0 C = XX, ST = XXX, L = Strawberry Hills, O = Department
of Misadventure and Zebras, OU = Somesite, CN = www.domz.gov
verify error:num=20:unable to get local issuer certificate
verify return:1

注：OU = SomesiteはDept. of Misadventure and Zebras.と矛盾しています

Certificate chain 0 s:/C=XX/ST=XXX/L=Strawberry Hills/O=Department of Misadventure and Zebras/OU=Somesite/CN=www.domz.gov i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-------

証明書を抽出して処理すると

openssl x509 -in abnote.pem -text

s_clientの結果を確認する結果が得られます。

certificatesopensslchromefirefox
11
philcolbourn

正確な使用例は不明ですが、それが Server Name Indication TLS拡張が正確に対処するものです。

HTTPSでは、サーバーが証明書を提示するSSLハンドシェイクは、サーバーがHTTPヘッダーを検査する前に発生します。 SNIにより、クライアントはTLSネゴシエーションの一部として仮想ドメインの名前を送信できます。これにより、サーバーは多数の証明書から1つの証明書を選択できます。したがって、SNIを実装するクライアントとサーバーでは、単一のIPアドレスを持つサーバーが、異なる証明書を使用して異なるドメイン名を処理できます。

SNIは、2003年6月にRFC 3546、トランスポート層セキュリティ（TLS）拡張を介してIETFのインターネットRFCに追加されました。標準の最新バージョンはRFC 6066です。

大規模なデータセンターでは、フロントプロキシが数百または数千のサイトにサービスを提供でき、アカマイやCloudFrontなどのコンテンツデリバリーネットワークとは言えないため、これは事実上の標準となっています（その部分についてはマイクウンズワースに感謝します）。

参照ページの詳細。

ところで、opensslはservernameオプションでSNIを使用できます。

openssl s_client -connect somesite.org:443 -servername somesite.org -showcerts

ブラウザが取得するものと同じ証明書を取得するのに十分でなければなりません

17
Serge Ballesta