☰

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

tag-icon • tag-icon openssl google-chrome
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 をプロキシしており、ドメインに対してローカルで信頼されている CA によって署名された証明書が生成されるためです。これは上記以外のすべてのドメインで機能しますが、新しい証明書は OpenSSL を使用して生成されるため CN が一致しません。

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

編集- この問題は SNI が原因であることは承知していますが、Squid と SSL_Bump で問題が発生する理由に関する情報を記入してください。

このプロジェクトでは、SSL サーバー名表示 (SNI) 情報のオリジン サーバーへの転送はサポートされないため、このようなサポートは少し難しくなります。ただし、SNI 転送には、転送に伴う困難さをはるかに上回る深刻な課題 (このドキュメントの範囲外) があります。

出典:http://wiki.squid-cache.org/Features/BumpSslServerFirst

答え1

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

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

答え2

Chromeはサポートしていますスニ、どの証明書を送信するかをサーバーに指示します。s_clientコマンドでは指示しません。

CloudFrontのSNIの使用に関する詳細はここ。

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

そして：

SNI カスタム SSL は、トランスポート層セキュリティ プロトコルの 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 バージョンを読み込むことができません。SNI カスタム SSL は、標準の CloudFront データ転送およびリクエスト料金以外の追加料金なしでご利用いただけます。

関連情報