X.509 证书的“公用名”属性中允许使用哪些字符串？答案

【问题标题】：What strings are allowed in the "common name" attribute in an X.509 certificate?X.509 证书的“公用名”属性中允许使用哪些字符串？
【发布时间】：2011-07-05 09:43:38
【问题描述】：

在 X509 证书的 DN 的 common name 字段中，如 ASN.1 表示法中为 OID“2.5.4.3”定义的那样，允许的值是多少？

我知道限制是最多 64 个字符，但是否允许所有字符？数字？
例如。是否允许.s？根据 ASN 定义，IP 地址 (x.x.x.x) 是否是有效序列？
是否允许使用域名？

【问题讨论】：

该标准允许在通用名称中使用任何字符串。字符串的含义取决于它的解释。
@GregS：如果是这样，为什么这是评论而不是答案？
@GregS: 你指的是哪个标准？因为我对 ASN 表示法中声明的类型感兴趣
抱歉，我正在阅读 RFC 5280。我没有将其作为答案，因为我认为它不够详细，无法提供答案。

标签： security x509 asn.1

【解决方案1】：

专有名称中的通用名称属性编码为：

X520CommonName ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-common-name)),
      printableString   PrintableString (SIZE (1..ub-common-name)),
      universalString   UniversalString (SIZE (1..ub-common-name)),
      utf8String        UTF8String      (SIZE (1..ub-common-name)),
      bmpString         BMPString       (SIZE (1..ub-common-name)) }

其中ub-common-name 是64。最后三种编码允许使用所有Unicode 代码点（对于超过0xFFFF 的代码点使用UTF-16 和bmpString）； UTF-8 是首选编码（至少标准是这样说的）。

就 X.509 而言（请参阅RFC 5280），DN 元素的内容与相等比较无关；这意味着您可以放置任何您想要的字符序列，只要您始终如一地这样做。 RFC 5280 要求对 UTF-8 编码的名称元素进行不区分大小写的比较，这在 Unicode 的一般上下文中并不容易：参见第 7.1 节，它链接到 RFC 4518 和 3454。此外，“通用名称”经常显示给用户（至少在使用具有显示和物理用户的 X.509 证书的系统上），因此您可能希望使用有意义或至少不太可怕的字符串对于人类，您可以尝试避免使用非拉丁文字。

将 DNS 名称放在“通用名称”属性中是 HTTPS 服务器证书的常见做法：请参阅RFC 2818（服务器证书包含服务器名称，客户端与 URL 中的服务器名称匹配；通常，主题替代名称扩展是首选，但通用名称在某种程度上受到客户更广泛的支持）。

【讨论】：

非常详尽且参考充分的答案。
这回答了我长期以来一直在问但根本没有找到答案的问题。对 RFC 的引用特别有用。
任何人都可以使用除 DNS 名称之外的其他名称作为通用名称提供指向网站的链接吗？（因此站点名称必须在 SAN 中）
@JeffPuckett 我查了很多，我能想到的最接近的是www-cs-01.oracle.com，它用于www.oracle.com，因此CN与DNS名称不同，尽管它不是什么你在问。由于 CA 通常从门户网站发布证书，并且门户网站过去一直使用 CN 中的域，因此我认为您很难找到其中包含 DNS 名称以外的其他内容的站点。甚至letsencrypt.org 也遵循这个约定，而且它们是一个相对较新的CA。

【解决方案2】：

如果您的主要问题是知道您是否可以（或应该）将 IP 地址放入主题 DN 的公用名中，答案是否定的。

这与 X.509 格式无关，而是与说明如何解释所读取内容的规范有关。

谈到 HTTPS，RFC 2818 对 IP 地址有如下说法：

在某些情况下，URI 被指定为 IP 地址而不是主机名。在这种情况下，iPAddress subjectAltName 必须是存在于证书中，并且必须与 URI 中的 IP 完全匹配。

这意味着 CN 根本不应该用于 IP 地址，并且 SAN 条目类型必须是 IP 地址，而不是 DNS。（某些浏览器不会完全实现这一点，因此它们可能更宽容。Java 默认主机名验证器将是严格的。）

现在RFC 6125 中也定义了证书身份验证的最佳实践，但它考虑了IP addresses out of scope（值得阅读本节以了解反对在那里使用 IP 地址的论点）。如果你通过excerpts of RFCs regarding other protocols，有些关于 IP 地址的限制（例如 LDAP）。

【讨论】：

DNS 对 SAN 扩展有效。
@TravisThomas 确实（在dNSName 扩展中）。为了澄清起见，我专门解决了关于 IP 地址的部分问题（因为其余部分已经有了其他答案）。

【解决方案3】：

虽然上述答案涵盖了您通常会在其中找到的内容，但请不要忘记，因为这是 X.509，您实际上可以在其中放置几乎任何东西。例如，下面的证书使用 0.9.2342.19200300.100.1.5，这是“最喜欢的饮料”（参见 http://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html）。 Openssl 明白这一点，所以常用名称显示为 CN=example.com/emailAddress=test@example.com/favouriteDrink=tequila。证书公用名中还有很多其他字段。

您可以使用 openssl x509 -text 来验证证书是否按照我的描述显示。

【讨论】：

由于证书错误，无法加载指向该站点的链接。

【解决方案4】：

X.509 证书的“公用名”属性中允许使用哪些字符串？

我无法真正回答其中的内容，但我可以告诉您 not 中的内容：服务器名称，如主机名 (www.example.com)、内部名称（如www) 和 IP 地址（如 127.0.0.1 或 100.100.100.100）。

IETF 和 CA/浏览器论坛均不赞成在通用名称 (CN) 中放置 DNS 名称或服务器名称。虽然已弃用，但目前并未禁止。 CA/B 很重要，因为这是浏览器遵循的 - 浏览器不遵循 IETF。

IETF 弃用了 RFC 6125 第 2.3 节中的做法，而 CA/B 弃用了基线要求第 9.1.1 节中的做法。

所有服务器名称都包含在主题备用名称 (SAN) 中。 CA/B 基线要求第 9.2.1 节要求将服务器名称放在 SAN 中。 IETF 在发布 RFC 5280 时更加宽容，但根据 RFC 6125 的第 6.4.4 节要求在验证期间这样做。

【讨论】：

很棒的答案！你能分享一个链接到任何在其 CN 中没有 DNS 名称的网站吗？
@JeffPuckett - 试试 Crypto++ 网站 (cryptopp.com)。 CN 被完全省略了。不过，我认为这是侥幸。我要求 "Crypto++" 的通用名称，但我认为处理发行的软件过滤了该名称，因为某些脚本可能会将加号解释为正则表达式。德普……
谢谢，太好了！如果您碰巧在野外遇到一个具有值或除 DNS 名称以外的任何内容的名称，请再次 ping 我。
@JeffPuckett - 还要记住 CN 只是专有名称 (DN) 的一部分或一部分。有两个重要的 DN。第一个是主体的 DN（证书颁发给谁），第二个是颁发者的 DN（颁发者）。整个 DN 字符串是重要的部分；并且缺少像 CN 或 State 这样的 RDN 并不重要。有一个涵盖 DN 的 RFC；它包含目录名称。