“通用名称”中允许使用哪些字符串? X.509 证书中的属性?
在 X509 证书 DN 的通用名称字段中(如 OID“2.5.4.3”的 ASN.1 表示法中所定义),允许的值是什么?
我知道限制最多为 64 个字符,但是否允许所有字符?数字?
例如,允许使用 .
吗? IP 地址 (xxxx) 是否符合 ASN 定义的有效序列?
允许使用域名吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
可分辨名称中的通用名称属性编码为:
其中 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< /a> (服务器证书包含服务器名称,客户端将其与 URL 中的服务器名称进行匹配;通常,首选主题替代名称扩展,但客户端更广泛地支持通用名称)。
The common name attribute in a Distinguished Name is encoded as:
where
ub-common-name
is 64. The last three encodings allow the use of all Unicode code points (using UTF-16 for code points beyond 0xFFFF withbmpString
); UTF-8 is the preferred encoding (at least the standards say so).As far as X.509 is concerned (see RFC 5280), the contents of DN elements are irrelevant beyond equality comparisons; which means that you can put whatever sequence of characters you wish, as long as you do so consistently. RFC 5280 mandates case-insensitive comparisons for UTF-8 encoded name elements, and this is not easy in the general context of Unicode: see section 7.1, which links to RFC 4518 and 3454. Also, the "common name" is frequently displayed to the user (at least on systems using X.509 certificates which have a display and a physical user), so you probably want to use a string which is meaningful or at least not too scary for a human, and you may try to avoid non-latin scripts.
Putting a DNS name in the "common name" attribute is common practice for HTTPS server certificates: see RFC 2818 (the server certificates contains the server name, which the client matches against the server name in the URL; normally, the Subject Alt Name extension is preferred for that, but the common name is somewhat more widely supported by clients).
虽然上面的答案涵盖了您通常会在其中找到的内容,但不要忘记,因为这是 X.509,所以您实际上可以在其中放置几乎任何内容。例如,下面的证书使用 0.9.2342.19200300.100.1.5,这是“最喜欢的饮料”(请参阅 https://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html)。 OpenSSL 理解这一点,因此通用名称显示为
CN=example.com/[电子邮件受保护]/favouriteDrink=龙舌兰酒
。还有许多其他字段可以放入证书通用名称中。您可以使用
openssl x509 -text
来验证证书是否按照我的描述显示。Whilst the above answers cover what you'll usually find in there, don't forget that because this is X.509 you can actually put pretty much anything in there. The certificate below for example uses 0.9.2342.19200300.100.1.5 which is 'favourite drink' (See https://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html). OpenSSL understand this, so the common name is displayed as
CN=example.com/[email protected]/favouriteDrink=tequila
. There are many other fields that can be put in the certificate common name.You can use
openssl x509 -text
to verify that the certificate displays as I've described.如果您的主要问题是知道是否可以(或应该)将 IP 地址放入主题 DN 的公用名中,那么答案是否定的。
这与 X.509 格式无关,而是与说明如何解释所读取内容的规范有关。
对于 HTTPS,RFC 2818 对 IP 地址有以下规定:
这意味着 CN 根本不应该用于 IP 地址,并且 SAN 条目类型必须使用 IP 地址,而不是 DNS。 (某些浏览器不会完全实现这一点,因此它们可能会更宽容。Java 默认主机名验证程序将很严格。)
证书身份验证的最佳实践现在也在 RFC 6125,但它考虑 IP 地址超出范围(值得阅读本节,了解反对在那里使用 IP 地址的论据)。
如果您仔细阅读有关其他协议的 RFC 摘录,您会发现其中一些有关 IP 地址(例如 LDAP)的类似限制。
If your main problem is to know whether or not you can (or should) put an IP address in the Subject DN's Common Name, the answer is no.
This isn't related to the X.509 format, but to the specifications that say how to interpret what they read.
When it comes to HTTPS, RFC 2818 says the following about IP addresses:
This means that the CN shouldn't be used at all for an IP address, and that the SAN entry type must by IP address, not DNS. (Some browsers, won't implement this fully, so they might be more tolerant. The Java default host name verifier will be strict.)
Best practices for certificate identity verification are also now defined in RFC 6125, but it considers IP addresses out of scope (it's worth reading this section for arguments against using IP addresses there).
If you go through the excerpts of RFCs regarding other protocols, some have similar constraints regarding IP addresses (e.g. LDAP).
我无法真正回答其中包含的内容,但我可以告诉您其中不包含哪些内容:服务器名称,例如主机名(www.example.com)、内部名称(例如 www)和IP 地址(如 127.0.0.1 或 100.100.100.100)。
IETF 和 CA/浏览器论坛均不赞成将 DNS 名称或服务器名称放在通用名称 (CN) 中。尽管已弃用,但目前并未禁止。 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 节进行验证时要求如此。
I can't really answer what goes in there, but I can tell you what does not go in there: server names, like hostnames (www.example.com), Internal Names (like www) and IP Addresses (like 127.0.0.1 or 100.100.100.100).
Placing a DNS name or server name in the Common Name (CN) is deprecated by both the IETF and CA/Browser Forums. Though deprecated, it's currently not prohibited. The CA/B is important because that's what browsers follow - browsers do not follow the IETF.
The IETF deprecated the practice in RFC 6125, section 2.3, while the CA/B deprecated the practice in the Baseline Requirements, section 9.1.1.
All server names go in the Subject Alternative Name (SAN). Placing server names in the SAN is required by CA/B Baseline Requirements, section 9.2.1. The IETF is more forgiving during issuance with RFC 5280, but requires it during validation under section 6.4.4 of RFC 6125.