使用SAN证书时,公共名称无效

时间:2014-09-22 09:28:00

标签: ssl certificate ssl-certificate

我为内部服务器生成了一个证书,该证书也可以从外部访问。根据{{​​3}} SO回答CN和SAN字段相互补充,因此我将CN设置为server.domain.local并且在SAN中我有DNS:server.domain.tld

但是,至少使用Chrome,我可以浏览到server.domain.tld(SAN条目)而不会出现错误,但我在server.domain.local(CN)上遇到了常见的名称不匹配错误

这是Chrome上的NSS中的实现错误还是我做错了什么?我应该在SAN字段中同时拥有server.domain.local和server.domain.tld吗?

3 个答案:

答案 0 :(得分:6)

  

.. CN和SAN领域相互补充..

仅在一般PKI情况下才是这样,但特定协议具有不同的行为。用于在HTTPS中检查证书的相关RFC是RFC2818(或更高版本的RFC6125),其中声明:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

这意味着,如果您有SAN部分,它必须包含所有名称,因为CN不会被检查。

答案 1 :(得分:4)

  

CN和SAN字段相互补充,因此我将CN设置为server.domain.local,而在SAN中我设置了DNS:server.domain.tld

不(但那篇文章现在有点老了。)

放置DNS名称是IETF和CA /浏览器论坛不推荐使用的公用名(CN)。您应将所有DNS名称放在主题备用名称(SAN)中。使用CN作为友好名称,例如“示例LLP”,因为它显示给用户。

根据CA /浏览器基准要求(BR),CN中的DNS名称也必须存在于SAN中。请参阅CA/B BR, Section 9.2


  

Chrome至少,我可以浏览到server.domain.tld(SAN条目)而不会出现错误,但我在server.domain.local(CN)上遇到了常见的名称不匹配错误

Chrome正确拒绝证书,如果CN中存在 server.domain.local ,但SAN中 。如果它不存在,则违反CA / B BR。


  

我应该在SAN字段中同时拥有server.domain.local和server.domain.tld

是的,将两个DNS名称都放在SAN中。不要在CN中放置DNS名称。使用CN作为友好名称。


为了完整性,CA / B代表 CA 浏览器。他们有自己的小封闭俱乐部,他们有自己的一套颁发证书的政策。不要指望浏览器按照IETF文档中的规定执行操作。

如果您要验证由CA / B成员的CA颁发的野外使用的X509证书,则应使用CA / B BR进行验证,而不是使用IETF文档进行验证。

答案 2 :(得分:1)

最初的问题已得到解答,但我想反驳其中一个答案中的观点。

CA / B BR不支持使用CN作为友好名称,虽然对我有吸引力且明智。 在CA / B BR的先前版本中,这是第9.2.2节,但它似乎最近已移动。 https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf

7.1.4.2.2。主题专有名称字段

一个。证书字段:subject:commonName(OID 2.5.4.3) 必填/可选:已弃用(不鼓励,但未被禁止)

内容:如果存在,此字段必须包含单个IP地址或完全限定域名,该域名是证书subjectAltName扩展名中包含的值之一。

恭敬地, - obivon