X.509证书中的可分辨名称长度限制

Question

在ASN.1表示法中OID为“2.5.4.3”的X509证书的DN的通用名称字段中，限制为最多64个字符。如果我们想要一个超过64个字符的通用名称，是否有任何解决方法？

- gingerNinja

---

Stack Overflow是一个关于编程和开发问题的网站。这个问题似乎不属于编程或开发范畴。请参阅帮助中心中的我可以在这里问什么样的问题。也许超级用户或信息安全堆栈交换会更适合提问。此外，还有我应该在哪里发布Dev Ops相关的问题？。 - jww

相关的，***CN=www.example.com*** 可能是错误的。主机名总是放在 SAN 中。如果它出现在 CN 中，则必须在 SAN 中也出现（在这种情况下必须列出两次）。有关更多规则和原因，请参见如何使用您的认证机构签署证书签名请求和如何使用openssl创建自签名证书？ - jww

我在ub-common-name-length中看到了64个字符的限制，它在CommonName ::= PrintableString(SIZE (1..ub-common-name-length))中。但是***CN**是向用户显示的友好名称，例如Example, LLC Widgets*，所以在实践中可能不是问题。如前所述，DNS名称放在SAN中，因此在实践中不应该有问题。您能否缩短友好名称以适应64个字符的限制？ - jww

不，我不能缩短我的友好名称以适应64个字符的限制。那么@jww有没有进一步的解决方法？ - gingerNinja

您可能会对 PKIX 邮件列表上的这个讨论感兴趣: CABF 基线要求的修订。PKIX 是 IETF 工作组，负责互联网 PKI。请关注讨论 LDAP 规范（有界）和 CAB 规范（无界）之间的差异。这是一个重要的区别，因为浏览器遵循 CAB 规范，而不是 IETF 规范。 - jww

Answer 1

即使您可以通过劝说证书生成代码来延长CN的长度，但是也需要更改客户端，而其中大多数您无法控制。客户端可能会拒绝具有过长CN的证书，然后您将根本没有证书。

如评论中所述，您可以（并且应该）将其和其他域名放入Subject Alternate Name扩展中，并将CN留空。不是整个“Subject”，而只是其中的CN部分。

- Chris Cogdon

Answer 2

如果你想像@Chris Cogdon暗示的那样“哄骗”证书生成代码，这并不难。我需要在反向工程挑战中这样做，所以违反标准并不重要。我完全同意你不应该这样做的信息，但我还是会解释一下我是如何做到的，因为这花了我一点时间去找出来。

以下是（粗略的）步骤：

1. 从https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/下载最新的libressl源代码（我使用2.6.0，因为它是macOS Mojave上的版本） 2. 解压缩/解包/压缩，并在您喜欢的编辑器中打开/crypto/asn1/a_mbstr.c 3. 查找类似下面这样的内容：

    if ((maxsize > 0) && (nchar > maxsize)) {
        ASN1error(ASN1_R_STRING_TOO_LONG);
        ERR_asprintf_error_data("maxsize=%ld", maxsize);
        return -1;
    }

并将其注释掉。对于版本2.6.0，在第155-159行上。删除这些行将删除最大CN长度检查。

4. 按照README文件中的说明构建二进制文件。在macOS上进行构建时，我不需要安装任何库，但您的情况可能会有所不同。我使用了cmake，将新的openssl二进制文件放置在/build/apps/openssl中。

5. 使用命令行标志生成CSR（注意：不是交互式工具--它具有特殊检查，此修改不能修补！）。

例如：

/build/apps/openssl/openssl req -new -newkey rsa:2048 -nodes -out a.csr -keyout a.key -subj "/CN=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

6. 使用原始的openssl二进制文件（或者如果您愿意，可以使用修改后的文件）签署CSR：openssl x509 -req -in a.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out a.crt -days 500 -sha256

之后，您应该准备好使用非符合证书。正如评论中许多人和Chris Cogdon所指出的那样，使用CN长于64个字符的证书存在许多问题（macOS curl无法与使用这些证书的服务器通信，Wireshark在展示中截断CN等）。然而，至少可以确认这些证书在某些特定情况下是可用的，因为该证书正好适用于我所需要的工作。

- Allison

Answer 3

我在实际应用中看到的一个技巧是使用通配符证书。

例如，使用CN='*.example.com'的证书来保护'very-truly-tremendously-[...]-long-hostname.example.com'。

- Happyblue