OpenSSLは、Chromeで表示されるものとは異なるSSL証明書を返します

次のコマンドでOpenSSLを使用してSparkfunのCDN URLを照会する場合：

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

証明書で返される共通名はであり、*.sparkfun.com検証に失敗しますが、ホストをChromeにロードすると、表示される共通名は*.cloudfront.net

ここで何が起こっていますか？

これは、私の環境がSquid SSL_Bumpを介してSSLをプロキシするため、問題が発生します。このSSL_Bumpは、ドメインのローカルに信頼されたCAによって署名された証明書を生成します。これは、OpenSSLを使用して新しい証明書が生成されるためCNが一致しないため、上記以外のすべてのドメインで機能します。

編集 -プロキシやフィルタリングを伴わずにインターネットに直接接続しているリモートデータセンターのサーバー上のOpenSSLでも同じことが発生することを確認しました。

編集 -問題は受け入れられたSNIによるものですが、SquidとSSL_Bumpで問題を引き起こす理由に関する情報を記入することです：

このプロジェクトは、SSLサーバー名表示（SNI）情報のオリジンサーバーへの転送をサポートせず、そのようなサポートを少し難しくします。ただし、SNIフォワーディングには、この文書の範囲を超えて、追加のフォワーディングの難しさをはるかに上回る重大な課題があります。

から取得：http : //wiki.squid-cache.org/Features/BumpSslServerFirst

CloudFrontは、単一のIPで複数の証明書を使用できる方法であるSNIを使用します。opensslのs_clientコマンドと同様に、最新のブラウザーはすべてこれをサポートしていますが、s_clientは魔法のようにこれを行いません。それを使用するように指示する必要があります。

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

ChromeはSNIをサポートし、サーバーに送信する証明書を伝えます。s_clientコマンドにはありません。

CloudFrontのSNIの使用法の詳細については、こちらをご覧ください。

SNIカスタムSSLを使用すると、一部の古いブラウザーはSNIをサポートせず、CloudFrontとの接続を確立してコンテンツのHTTPSバージョンをロードできないため、一部のユーザーがコンテンツにアクセスできない場合があります。サポートされているブラウザのリストなど、SNIの詳細については、FAQページをご覧ください。

そして：

SNIカスタムSSLは、Transport Layer SecurityプロトコルのSNI拡張機能に依存しています。これにより、複数のドメインが、接続しようとしているホスト名を含めることで、同じIPアドレスでSSLトラフィックを処理できます。専用IPカスタムSSLと同様に、CloudFrontは各Amazon CloudFrontエッジロケーションからコンテンツを配信し、専用IPカスタムSSL機能と同じセキュリティを備えています。SNIカスタムSSLは、Chromeバージョン6以降（Windows XP以降またはOS X 10.5.7以降で実行）、Safariバージョン3以降（Windows Vista以降またはMac OS X 10.5で実行）など、ほとんどの最新ブラウザーで動作します。 6.以降）、Firefox 2.0以降、およびInternet Explorer 7以降（Windows Vista以降で実行）。SNIをサポートしない古いブラウザーは、CloudFrontとの接続を確立してコンテンツのHTTPSバージョンをロードできません。