web-dev-qa-db-ja.com

不正な証明書を使用しているときにhttps://gmail.com/でSSLエラーが発生しないのはなぜですか?

https://gmail.com ホスト名用のSSL証明書を使用しているようですmail.google.com。 SSL証明書のホスト名がブラウザのURLと一致しないのに、なぜこれが機能するのですか?代わりに警告が表示されます。

FirefoxとChromiumでテストしました( 以前は機能しませんでした のようです)。

次のコマンドで証明書を確認しました:echo | openssl s_client -connect gmail.com:443これは:

Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
5
Totor

gmail.comは適切な証明書を使用していますが、接続しているサーバーは サーバー名表示 を使用して単一のアドレス+ポートで仮想ホストを実行しています。これが機能するためには、SSL/TLSネゴシエーションが実行される前に、クライアントはサーバーに探している仮想ホストを通知する必要があります。 FirefoxとChromium(および同様のサイズの他のクライアント)はこれを自動的に行います。

openssl s_clientで有効な証明書を取得するには、-servernameオプションを使用する必要があります。

openssl s_client -servername gmail.com -connect gmail.com:443

lynx SNI のGoogleの結果はよく見えません。

7
user240960

https://gmail.com/は不正な証明書を使用していません。 Fiddler2によって傍受された現在の証明書は次のとおりです。

== Server Certificate ==========
[Subject]
  CN=gmail.com, O=Google Inc, L=Mountain View, S=California, C=US

[Issuer]
  CN=Google Internet Authority G2, O=Google Inc, C=US

[Serial Number]
  4F4A246099981C2C

[Not Before]
  16/07/2014 10:04:37 PM

[Not After]
  14/10/2014 11:00:00 AM

[Thumbprint]
  8F1065D237732F71CAD350A3FD0089AEEAAB675E

CN=gmail.comに注意してください。

HTTPリクエストからの実際の応答タイプは301 Moved Permanentlyからhttps://mail.google.com/です。これには2つの効果があります。

  1. ブラウザは宛先にリダイレクトし、新しいトンネル(ドメインが異なるため)と証明書が異なる新しいリクエストを作成します。これがmail.google.com証明書が表示される理由です-これはリダイレクトです。アドレスバーを見ると、実際にアクセスしているサイトはhttp://mail.google.com/ではなくhttp://gmail.com/です。ブラウザでリダイレクト前の証明書を取得するのは少し難しいので、Fiddler2を使用しました。

  2. ブラウザはこのリダイレクトをキャッシュし、将来自動的に実行します。https://gmail.com/に別のリクエストを行うことはありません(これがMoved Permanentlyのポイントです)。これはこの質問にとってそれほど重要ではありませんが、リダイレクトを見つけるのが少し難しくなります。最初にキャッシュをクリアするか、プライベートブラウジングウィンドウを開く必要があります。

9
Bob