由于使用.local顶级域名,Chrome会显示SSL错误

我刚刚取代了我们几台服务器上的SSL证书(全部托pipe在IIS7上)。 在我们的IT经理的build议下,我们使用一个主题备用名称证书,而不是每个服务器的单独证书。 我们从Digicert购买了这个证书(不是自签名的)。我已经在我们的服务器上安装了证书,这些网站没有任何警告地加载,并在Firefox和Internet Explorer中显示出良好的locking。 但是,Chrome会通过locking图标显示一个红色“x”,并在URL的“https”部分显示删除线字体。 连接选项卡显示以下错误:

“本网站的身份未经validation,您连接的服务器的身份无法完全validation,您使用的名称仅在您的networking中有效,而外部证书颁发机构无法validation由于某些authentication机构将为这些名称颁发证书,无论如何,都无法确保您连接到预期的网站而不是攻击者。

点击“证书信息”,我会看到完整的证书链(我们的证书,Digicert的中级证书和Digicert的CA证书)以及所有三个证书的证书状态为“此证书正常”。 我有四重检查,我在URL中使用的主机名是完全匹配的通用名称或证书中的主题替代名称之一。 我们在这些站点上的先前证书是* .mycompany.local的通配证书,而新的通用名称和SAN名称是针对mycompany.local域(即eng-wiki.mycompany.local)内的特定主机。

从Chrome的解释几乎听起来好像它已经检测到内部的DNS服务器被用来解决服务器的IP,但也是旧的通配证书的情况下,如果这是一个有效的理由声称身份不能被validation,它应该与旧的通配符证书(但它没有)相同的方式失败。此外,这种解释意味着没有公司内部服务器可以validation他们的身份,这样做会有更多的伤害安全性比好,因为我们都必须教导我们的用户忽略Chrome中的安全警告,尽pipe专门为了避免这种情况而在合法证书上下了数百美元。

我会很感激任何帮助。

谢谢!

– 编辑 –

今天进一步挖掘,我search了铬源的错误信息的文本,并发现这个问题是由Chrome的结论是主机名是不唯一的。 还有其他一些职位用这个问题来报告这个问题,如果使用短名称作为他们的URL,那么这个问题就是 SAN证书 但是我使用完全限定的服务器名称,例如wiki.mycompany.local

确定我的主机名为非唯一的代码在这里 ,我看到一些讨论gTLD的意见,我怀疑这是gTLD的根本原因。 我对全球顶级域名不太了解,但我的公司使用.local伪顶级域名。 维基百科似乎说这不再是一个好主意(我不能做3链接B / C我的声誉太低服务器故障,请随时编辑这个,并使其成为一个链接en.wikipedia.org/wiki /.local),尽pipe多年前当我们的IT团队build立我们的networking时,这是一个推荐的做法。 要求他们改变现在并不是一件容易的事情

我试图编辑我的问题,删除公式中的SAN元素,除了我使用通配符证书mycompany.local时没有这个问题。 所以我仍然怀疑使用SAN证书是问题的一部分。 仍然感谢任何帮助。

此外,这种解释意味着没有公司内部的服务器可以validation他们的身份,这对安全造成的损害远远大于好处,因为我们都必须教导我们的用户忽略Chrome中的安全警告,尽pipe已经减less了数百美元在一个合法的证书专门为了避免这一点。

但是,无论证书有多贵,他们的身份certificate都不能由第三方来validation。

只有一个公司可以在公共互联网上“拥有”contoso.com,该公司可以指定server1.contoso.com是什么,而没有其他人可以。

DigiCert(或任何人)可以validationserver1.contoso.com的证书请求来自拥有contoso.com的同一家公司,因此(可能)不是欺诈请求。 他们也可以为server1.contoso.com发出一个证书,然后再发送一个证书。

任何人都可以拥有contoso.local。 很多人一次。 Digicert不能做任何事情来validation你是否有这个名字的服务器。 而且他们可以一次又一次地向不同的人颁发证书。

所以安全警告是一个真正的警告 – Chrome无法validation这是预期的server1.contoso.local,因为完全相同的证书可以安装在世界各地的称为“server1.contoso.local”的一千台计算机上。

如果你正在考虑把你的信用卡信息放入一个网站,一个.local证书不应该让你放心。

显然,IE和FireFox对此有不同的看法,select假装没事的时候是好的。

让您的服务器可以通过真正的FQDN访问,并购买相应的证书。

DigiCert不会将Chrome列为其网站上受支持的浏览器。 正如其他地方所讨论的,SAN的解释取决于SSL的实现,我怀疑Chrome与Firefox或Internet Explorer相比可能会做一些奇怪的事情(tm)。

你有机会在SubjectAltName中使用IP地址吗? 看一个在线的Chrome应用程序代码示例似乎表明他们期望在那里的主机名(而不是IP)。

这很简单,归结为authentication。 正如TessellatingHeckler所说,安全警告是真实的,有一个解决方法。 在Chrome中这不是一个缺陷,而是一种IE或FF可能需要追赶的最佳安全实践的主动方法。 有没有想过为什么一些CA还在销售5年的证书,而其他的只有3年? 证书有效期也将有所改变。

当颁发组织authentication(OV)证书时,CA必须authentication该域名已在域名注册商处完全注册,并且该业务有权使用该域名。 它通过查看WHOIS和D&B来validation此信息。 例如.com / .net / .edu。 另一方面.local可以由任何人拥有,不能由任何CAauthentication。 不知道如何在Digicert身份validation,但它不应该有。 当您购买SSL证书时,您支付更多的authentication。

以下是来自CA Browser论坛的链接,指出到2016年10月,所有内部名称的使用将被取消,以实现最佳安全实践。 希望这会给ITpipe理团队带来一些启发,让他们开始采取主动的方式,而不是等到最后一刻。

https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf

我可以问你这个证书有多less年了? 我问的原因是,目前有一个解决办法,所以你可以整理有关内部名称的服务器configuration。 当您生成CSR时,将通用名称设为www.yourcompany.com,并在SAN字段中input“yourcompany.local”。这样,当CA处于authentication过程中时,可以validation您是否拥有权限到www.yourcompany.com,在SAN字段中,yourcompany.local的IP地址也将被保护。 这个解决方法是时间敏感的,因为如果CA在有效期内通过强制更改,CA将不会在这种情况下颁发3年期的证书。

我希望这些信息有一定帮助。