CSR解码器

在下方粘贴证书签名请求，这个 CSR 解码器会向您展示其中实际包含的内容：通用名称和其余的可分辨名称、公钥及其密钥长度、签名算法，以及请求所涵盖的每一个使用者备用名称。

阅读这些字段只需几秒钟。跳过它们则要付出重新签发的代价。证书颁发机构会毫不犹豫地为一个域名拼写错误的 CSR 签名，而您只会在浏览器对着已经付费并安装好的证书抛出名称不匹配错误时才会发现问题。

解码您的 CSR 文件

将 CSR 的完整文本粘贴到框中，包括开头和结尾行：

有效的 CSR 以 —–BEGIN CERTIFICATE REQUEST—– 开头，以 —–END CERTIFICATE REQUEST—– 结尾。

运行 IIS 的 Windows 服务器会将开头行写为 —–BEGIN NEW CERTIFICATE REQUEST—–。两种形式在这里都适用。文件可能以 .csr、.pem 或 .txt 扩展名出现；只有其中的文本内容才重要。这个免费的在线 CSR 解码器能读取 PEM 格式，也就是几乎所有服务器和主机面板都会生成的 Base64 格式。

还没有 CSR？使用我们的CSR 生成器生成一个，或参照适用于您平台的 CSR 指南操作。

CSR 解码器向您展示的内容

每一个 CSR 都携带证书颁发机构所需的两项信息：您声称自己是谁，以及您想要认证的公钥。身份部分被称为主体（Subject），或可分辨名称（Distinguished Name），它是一组带标签的字段，而不是一长串字符串。解码器会将可分辨名称拆分为各个部分，并连同关键的密钥信息一起呈现。

下表列出了这个 CSR 解码器返回的每一个字段，一个有效值应该是什么样子，以及当它出错时会造成什么问题。

CSR 中还可以包含可选属性和请求的扩展字段，大多数解码器会跳过这些内容。挑战密码是一个可选字符串，某些 CA 曾用它来授权撤销证书；除非您的 CA 要求填写，否则将其留空即可。请求的扩展字段，如 keyUsage、extendedKeyUsage 和 basicConstraints，描述了证书应被允许执行的操作，不过最终数值由 CA 决定。

CSR 解码的工作原理

CSR 是一种 PKCS#10 证书请求，其格式由 RFC 2986 定义。其内容用 ASN.1 描述，序列化为二进制的 DER 格式，然后经过 Base64 编码，并用 PEM 的开头和结尾行包裹起来，以确保请求在通过电子邮件发送和复制粘贴时不会损坏。

解码过程正好相反。工具会剥离 PEM 包装，将 Base64 转换回 DER，解析 ASN.1 结构，并为其中发现的每一个值加上标签。

整个过程中不会发生任何解密操作，因为 CSR 中并没有任何加密的内容。CSR 携带的是您的公钥。私钥保留在生成它的服务器上，从不会进入请求本身。任何截获 CSR 的人都能读取其内容，这正是为什么将 CSR 通过电子邮件发送给证书颁发机构是安全的。

CSR 确实携带一个签名。该请求是用与其中公钥相匹配的私钥签名的，这证明您持有该密钥。这被称为持有证明（Proof of Possession），正是通过这种方式，CA 才能知道申请证书的人确实控制着要被认证的那个密钥。

一旦 CA 验证了请求，它就会签发一份包含您公钥以及其能够核实的主体字段的 X.509 证书。

提交 CSR 前应检查的事项

在将请求提交给证书颁发机构之前，先按照这份清单核对解码后的输出结果。在这个阶段把解码器当作 CSR 检查工具使用，只需花费您一分钟时间。而在签发之后才发现同样的错误，则要付出重新签发和重新部署的代价。

1. 通用名称与您的完全限定域名完全匹配，包括是否按您的意图带有 www。 example.com 和 www.example.com 是两个不同的名称。
2. 您需要的每个域名都出现在 SAN 列表中，而不仅仅是在通用名称里。
3. 国家代码恰好是两个字母。 如果不确定，请对照 ISO 3166-1 alpha-2 列表进行核实。
4. 州和地区名称已完整拼写，而不是缩写形式。
5. 如果您购买的是 OV 或 EV 证书，组织字段是您注册的法定名称。域名验证型证书会忽略此字段。
6. 密钥是 2048 位或更大的 RSA，或者是 256 位或更大的 ECDSA。
7. 签名算法是 SHA-256 或更强的算法。
8. 通配符语法为 *.example.com，仅覆盖一个层级。它不会覆盖 shop.eu.example.com。
9. 您仍持有生成该 CSR 所用的私钥。 下单前请使用证书密钥匹配工具进行确认。

解码器会揭示的常见 CSR 问题

名称不匹配。 通用名称或 SAN 列表与服务器实际响应的域名不一致。这是证书安装后在浏览器中仍然出错的最常见原因。

缺少 SAN。 证书已签发，通用名称看起来没问题，但某个主机名仍然报错。解码 CSR 并检查该主机名是否曾出现在 SAN 列表中。如果没有，那它就从未被覆盖过。

国家代码被拒绝。 写成了三个字母而不是两个。CA 会拒绝该请求，通常提示信息中不会指明具体字段。

州名被缩写。 写成 CA 而不是 California，写成 NY 而不是 New York。域名验证型订单可以通过。组织验证和扩展验证型订单会在验证阶段卡住，直到您重新提交。

密钥太小。 1024 位 RSA 已经多年不被公共 CA 接受。请用 2048 位或更大的密钥重新生成 CSR；仅编辑请求本身无法解决这个问题。

OU 字段消失了。 您在组织单位字段中填写了一个部门名称，但它没有出现在签发的证书中。这是自 2022 年 9 月起的预期行为，并不是 CA 一方的错误。 了解 OU 字段被移除的原因。

CSR 与您的私钥不匹配。 这通常是因为生成了第二个 CSR，导致混淆了哪个密钥对对应哪个请求。使用证书密钥匹配工具，一步即可解决。

国际化域名格式不正确。 非 ASCII 域名必须以 Punycode 形式（即 xn-- 形式）出现，而不能使用其原生文字。

使用 OpenSSL 解码 CSR

如果您已安装OpenSSL，无需浏览器即可读取 CSR：

openssl req -in example.csr -noout -text

加上 -verify 可以同时检查请求自身的签名，从而确认该 CSR 自生成以来未被更改过：

openssl req -in example.csr -noout -text -verify

输出结果会将整个可分辨名称放在 Subject: 这一行中，以逗号分隔的连续形式呈现，而不是作为单独的字段，因此要从左到右阅读： C、ST、L、O、OU、CN。在这之下， Public Key Algorithm 标明是 RSA 还是 ECDSA，而 Public-Key: 则在括号中给出位长。 Signature Algorithm 会出现两次，一次在靠近顶部的位置，另一次在底部签名区块旁边；两者都指的是 CSR 自身的签名。

使用者备用名称很容易被忽略。它们并不属于 Subject 那一行。要在下方找到 Requested Extensions 区块以及其下方的 X509v3 Subject Alternative Name 条目。如果没有这个区块，说明该 CSR 根本没有任何 SAN。

当未安装 OpenSSL、您使用的是没有 WSL 的 Windows，或者 CSR 是从主机面板中生成、只以文本形式存在于浏览器标签页中时，上面的网页工具是更快捷的选择。输出的信息是相同的，只是用通俗易懂的语言进行了标注。

为 Sectigo、DigiCert 或任何其他 CA 解码 CSR

CSR 是一种 PKCS#10 文件，其格式不会因签发方而改变。不存在专属于 Sectigo 或 DigiCert 的 CSR 格式，因此一个解码器就能适用于发往任何证书颁发机构的请求。

不同 CA 之间真正有差异的，是哪些字段会被验证以及验证的严格程度。域名验证型证书只检查对域名的控制权，完全忽略组织字段。组织验证和扩展验证型证书则要求组织、地区、州和国家字段与公开记录相匹配，这正是为什么在验证等级越高的情况下，这些字段的准确性就越重要。

常见问题