为什么网站为不同的浏览器提供不同的SSL证书？
menswearireland.com和www.menswearireland.com上的SSL证书可在Safari，Chrome，SeaMonkey，K-Meleon，QtWeb，Firefox和Opera上正常运行。 但是，Internet Explorer声称有一个错误：
本网站提供的安全证书不是由可信任的证书颁发机构颁发的。 本网站提供的安全证书是针对不同网站的地址发布的。
安全证书问题可能表示试图欺骗您或拦截您发送给服务器的任何数据。
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
在同一个托pipe服务器上托pipe的另一个站点显示没有错误： achill-fieldschool.com和www.achill-fieldschool.com在IE上工作正常，尽pipe据我所知，证书的设置完全相同。
我究竟做错了什么？
这是运行Plesk的LAMPP服务器。
它看起来像服务器显示不同的证书不同的客户端。 对某些客户来说，它显示了www.menswearireland.com上的一个www.menswearireland.com证书， menswearireland.com是一个有效的替代名称。 对于其他客户，它展示了一个Parallels面板证书，由Parallels Panel 。 以下是几种不同的在线SSL检查程序的结果：大多数人说这很好，而两个显示错误。
三个在线检查员说这是有效的
Comodo SSL Check将其显示为有效
DigiCert SSL Check将其显示为有效
SSL购物者SSL检查将其显示为有效
通用名称： www.menswearireland.com
SANs： www.menswearireland.com，menswearireland.com
有效期为2012年10月2日至2013年11月4日
序列号： 559425（0x88941）
签名algorithm： sha1WithRSAEncryption
发行人： RapidSSL CA
另一个在线检查似乎看到一个完全不同的证书
GeoCerts SSL Check将其显示为无效
通用名称： Parallels Panel
组织： Parallels
有效期为2012年8月15日至2013年8月15日
发行人： Parallels Panel
另一个在线检查器看到多个证书
Symantic SSL Check将其显示为无效
证书安装检查程序连接到Web服务器并读取其证书，但无法确定哪个是Web服务器的主要证书。
顺便说一下，在menswearireland.com和achill-fieldschool.com ，主页将从HTTPSredirect到HTTP。 要查看SSL详细信息，请访问两个页面/account （该页面将从HTTPredirect到HTTPS）。
我在更详细的在线SSL检查程序中find了更多信息。
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。
所以事实certificate，在Plesk 11.0中，仅在专用IP地址上分配SSL证书是不够的。 您还必须转到IP地址列表（服务器pipe理>工具和设置>工具和资源> IP地址），并将每个IP地址的“默认站点”设置为该地址上的站点。
如果您不这样做，Plesk将以需要SNI的方式提供证书，而不必将首先将每个安全站点放置在专用IP地址上的好处。
您也可以在那里设置SSL证书，但这是不必要的。 这似乎比必要的更混乱。
当我从我的公司局域网（防火墙代理和所有）访问网站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来说，这是一个很大的问题。
我知道这是一个古老的线索，但它帮助我解决了类似的问题。 我确定它与IPv6相关，而不是SNI。 事实certificate，Verizon Wireless和其他ISP越来越多地使用IPv6而不是IPv4。 这是一个令人沮丧的问题，因为我能想出的唯一共同点就是我的客户中有大多数人都在使用Verizon，但并不是所有的Verizon LTE连接都使用IPv6，所以有些工作是正确的。 在我的情况下，我需要将证书分配给我的Plesk服务器上的IPv6地址以及IPv4地址，并解决了问题。