为什么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

— Totor
source

gmail.com 甚至不适合我。我将猜测正确的网站是什么，它内部定向到mail.google.com，这是一个扩展的验证证书。 Chrome会以静默方式处理Google网站。 换句话说，Chrome知道该网站是否为Google。我假设你在所有浏览器上使用当前版本？

— Ramhound

@Ramhound它发送一个 301 Moved Permanently 至 mail.google.com。如果您之前访问过它，您的浏览器将缓存重定向，甚至不会进行重定向 gmail.com 请求。它可能提供不同的证书。

— Bob

@Bob - 是的;我有点认识谷歌那样做了;

— Ramhound

Answers:

gmail.com使用一个好的证书，但你连接的服务器正在使用服务器名称指示在单个地址+端口上运行虚拟主机。为此，客户端必须告知服务器在SSL / TLS协商完成之前它正在查找哪个虚拟主机。 Firefox和Chromium（以及类似大小的其他客户端）会自动执行此操作。

获得有效证书 openssl s_client，你需要使用 -servername 选项。

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

谷歌的结果 lynx SNI 看起来不太好看。

— Wumpus Q. Wumbley
source

+1此外，它不是真正重要的CN，但它是主题备选名称在这里很重要（在查看证书的完整细节时可见，例如使用 echo | openssl s_client -connect gmail.com:443 -servername gmail.com | openssl x509 -text -noout ）。

— Bruno

@Bruno服务的证书上没有SAN https://mail.google.com/，除非我错过了什么。虽然他们可能在证书上 https://gmail.com，这正是问题所针对的问题。虽然，是的，SAN应该是首先要检查的东西。

— Bob

@Bob，你错过了什么，试试OpenSSL命令来显示细节 mail.g..： X509v3 Subject Alternative Name: DNS:mail.google.com。这与问题的反面并不完全相同，因为提问者实际上是在想为什么它不在主题DN中，这不应该首先检查。它可以两者都是SAN的单一证书 mail.google.com 和 gmail.com （事实并非如此）。在任何情况下，SAN都是第一个要检查的东西，因为当SAN存在时应该忽略CN，因此在问题和答案中仅提及CN有点无关紧要。

— Bruno

@Bruno我不知道 subjectAltName 的存在意味着CN应该被忽略（RFC2818§3.1如果有其他人感兴趣的话） - 我一直认为它是此外。抱歉。至于我的回答 - “由于SSL证书主机名与浏览器URL不匹配，为什么这会起作用？” 是我的回答 - 它不匹配浏览器加载的URI，这与输入的URI不同。（我没有提及/检查/回答OpenSSL输出，是的 - 忽略了这一点）。

— Bob

@Bob确实，这是在RFC 2818.现在还有RFC 6125，但它并没有在任何地方实现（据我所知，它在Chrome中），它主要是兼容的，但澄清了几点（主要是CN和通配符）。有些工具比其他工具更严格（见这个问题例如）。

— Bruno

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请求中的实际响应类型是a 301 Moved Permanently 至 https://mail.google.com/。这有两个影响：

浏览器将重定向到目标，发出新请求，使用新隧道（因为不同的域）和不同的证书。这就是你看到的原因 mail.google.com 证书 - 这是后重定向。如果您查看地址栏，您所在的实际站点是 http://mail.google.com/不是 http://gmail.com/。在浏览器中捕获预重定向证书有点困难，这就是我使用Fiddler2的原因。
浏览器将缓存此重定向并在将来自动执行，从不再发出请求 https://gmail.com/ （这就是重点 Moved Permanently ）。这对于这个问题并不重要，但它确实让发现重定向更加困难 - 您需要先清除缓存或打开隐私浏览窗口。

— Bob
source

为什么 openssl s_client -connect gmail.com:443 找到mail.google.com的证书呢？为什么 lynx https://gmail.com 产生SSL错误，而 lynx https://mail.google.com 不？

— Totor

@Totor可能是因为他们如何处理HTTP重定向？

— BlueCacti