![三个在线检查器都表示有效](https://linux22.com/image/600735/%E4%B8%89%E4%B8%AA%E5%9C%A8%E7%BA%BF%E6%A3%80%E6%9F%A5%E5%99%A8%E9%83%BD%E8%A1%A8%E7%A4%BA%E6%9C%89%E6%95%88.png)
SSL 证书在 Safari、Chrome、SeaMonkey、K-Meleon、QtWeb、Firefox 和 Opera 上都可以正常工作。但是,Internet Explorer 声称存在错误menswearireland.com
:www.menswearireland.com
此网站提供的安全证书不是由受信任的证书颁发机构颁发的。此网站提供的安全证书是为其他网站的地址颁发的。
安全证书问题可能表明有人试图欺骗您或拦截您发送到服务器的任何数据。
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
在同一托管服务器上托管的另一个站点没有显示任何错误:achill-fieldschool.com
并且www.achill-fieldschool.com
在 IE 上运行良好,尽管据我所知证书设置相同。
我究竟做错了什么?
这是一个运行 Plesk 的 LAMPP 服务器。
看起来服务器向不同的客户端显示了不同的证书。对于某些客户端,它显示一份发给 的 RapidSSL 证书,www.menswearireland.com
并menswearireland.com
作为有效的备用名称。对于其他客户端,它显示一份发给 的 Parallels Panel 证书Parallels Panel
。以下是几个不同的在线 SSL 检查器的结果:大多数都说没问题,而两个则显示错误。
三个在线检查器都表示有效
通用名称:www.menswearireland.com
SAN:www.menswearireland.com, menswearireland.com
有效的2012年10月2日至2013年11月4日
序列号:559425(0x88941)
签名算法:sha1WithRSAEncryption
发行人:RapidSSL 证书
另一个在线检查器似乎看到了完全不同的证书
通用名称:Parallels 面板
组织:相似之处
有效的2012年8月15日至2013年8月15日
发行人:Parallels 面板
另一个在线检查器看到多个证书
证书安装检查器连接到 Web 服务器并读取其证书,但无法确定哪个是 Web 服务器的主要证书。
顺便说一句,这两个网站上的menswearireland.com
主页achill-fieldschool.com
都会从 HTTPS 重定向到 HTTP。要查看 SSL 详细信息,请访问这两个网站上的页面/account
(该页面将从 HTTP 重定向到 HTTPS)。
我在更详细的在线 SSL 检查器中找到了更多信息。
https://www.ssllabs.com/ssltest/analyze.html?d=menswearireland.com
此网站仅在支持 SNI 的浏览器中运行
我的理解是,SNI(RFC 6066)是一种将多个 SSL 站点放在一个共享 IP 地址和端口上的方法。这在旧版 Windows 上的 Internet Explorer 上不起作用(这与 Windows 的版本有关,而不是 Internet Explorer 的版本)。但是,我们所有的 SSL 站点都在一个唯一的 IP 地址上,所以我们不需要 SNI。
答案1
因此,事实证明,在 Plesk 11.0 中,为专用 IP 地址上的网站分配 SSL 证书是不够的。您还必须转到 IP 地址列表(服务器管理 > 工具和设置 > 工具和资源 > IP 地址),并将每个 IP 地址的“默认站点”设置为该地址上的站点。
如果您不这样做,Plesk 将以需要 SNI 的方式提供证书,这反而消除了将每个安全站点放在专用 IP 地址上的好处。
您也可以在那里设置 SSL 证书,但那没有必要。这似乎比必要的更令人困惑。
答案2
当我访问网站时https://www.menswearireland.com我从公司局域网 (防火墙代理和所有) 收到一个 SSL 错误:
VERIFY DENY: depth=0, (18) self signed certificate: "Parallels Panel"
VERIFY DENY: depth=0, CommonName "Parallels Panel" does not match
URL "www.menswearireland.com"
这意味着该证书显然是一个自签名证书,而这对于 Internet Explorer 来说是大忌。
答案3
我知道这是一个老话题,但它帮助我解决了类似的问题。我确定它与 IPv6 有关,而不是 SNI。事实证明,Verizon Wireless 和其他 ISP 越来越多地使用 IPv6 而不是 IPv4。这是一个令人沮丧的问题,因为我能想到的唯一共同点是,遇到此问题的大部分客户都在使用 Verizon,但并非所有 Verizon LTE 连接都使用 IPv6,因此有些连接可以正常工作。就我而言,我需要将证书分配给我的 Plesk Server 上的 IPv6 地址以及 IPv4 地址,这样问题就解决了。