【发布时间】：2016-01-29 21:50:05
【问题描述】：
我想知道如果我尝试使用 ip 地址而不是域名访问站点，为什么会出现证书错误。比如说nslookup 说google.com 是173.194.43.96，所以我尝试浏览https://173.194.43.96，我得到证书错误，说这个网站提供的安全证书是为不同的网站地址颁发的。为什么会这样？
【问题讨论】：
标签： ssl
【发布时间】：2016-01-29 21:50:05
【问题描述】：
这是因为 SSL 证书是为特定域名颁发的。如果证书名称与访问域不匹配，浏览器会报错。
SSL 的主要功能之一是向用户证明他们确实连接到他们请求的站点，而不是向伪装成终端站点的攻击者证明。如果不将域名链接到证书，这是不可能的。
可以想象，浏览器证书系统可以设计为在证书中包含 IP 地址，但这会导致难以使用 DNS 负载平衡，甚至更改托管服务提供商，因为必须使用新证书每次发生这种情况时发出。如果证书仅包含 IP 地址而不包含域，这将使用户无法抵御 DNS 欺骗攻击。所以唯一的出路就是单独使用域名。
有趣的是，IP 地址是possible to obtain an SSL certificate - 由于 Google 是他们自己的证书颁发机构，他们可以为自己颁发 173.194.43.96 的证书，从而可以通过 IP 地址安全地浏览 google ，只要他们使用 SNI 提供正确的证书。然而，这似乎不值得增加额外的复杂性......
如果您想了解更多，这是对 SSL 的一个很好的介绍：
【讨论】：
公用名通常由主机 + 域名组成，类似于 www.yoursite.com 或 yoursite.com。 SSL 服务器证书特定于在主机级别颁发的公用名。公用名必须与连接到安全站点时要访问的 Web 地址相同。例如，如果访问名为 www.domain.com 或 secure.domain.com 的站点，则域 domain.com 的 SSL 服务器证书将收到警告，因为 www.domain.com 和 secure.domain.com 与 domain.com 不同。
【讨论】：
-
实际上对于真正的（公共）证书，CommonName（在 Subject 中）自 2010 年左右以来已被 SubjectAlternativeName 扩展（缩写为 SAN）所取代，尽管 Chrome 在它真正是 SAN 时通过重用错误代码“COMMON_NAME_INVALID”而无济于事。
证书是发给 www.google.com 的，而不是发给它的 IP 地址。因此，您的浏览器将无法验证将 www.google.com 列为实体的证书。
欲了解更多信息，请参阅：www.digicert.com/ssl-support/certificate-name-mismatch-error.htm
【讨论】：
在 MAC High Sierra 和 Python 3.6.4 上，我尝试了解决方案：requests toolbelt:HostHeaderSSLAdapter 1st，不幸的是，它对我不起作用，然后我尝试了 forcediphttpsadapter，终于成功了。
作者在自述文件部分解释了所有内容，并提供了一个示例脚本，可以轻松遵循。
1.通过pip install requests[security] forcediphttpsadapter安装库
2.运行示例脚本：
import requests
from forcediphttpsadapter.adapters import ForcedIPHTTPSAdapter
session = requests.Session()
session.mount("https://example.com", ForcedIPHTTPSAdapter(dest_ip='1.2.3.4'))
response = session.get(
'/some/path', headers={'Host': 'example.com'}, verify=False)
注意：在某些情况下，您可能需要从 url 中删除前缀：'www'。
【讨论】：