CSR 解码器 (PKCS#10)

使用方法

1. 粘贴 CSR，或把 .csr、.pem 文件拖到输入框上。它以 -----BEGIN CERTIFICATE REQUEST----- 开头。
2. 先看 SAN 列表：证书需要覆盖的每一个主机名都必须出现在那里，包括写在 Common Name 里的那个。
3. 确认自签名通过校验；如果不通过，请重新生成请求，不要提交。
4. 看密钥长度和签名算法：公共 CA 要求至少 2048 位 RSA（或任意 EC 曲线）以及 SHA-256 及以上的签名。
5. 提交前把琥珀色的条目解决掉——被 CA 拒绝通常要多花好几个小时来回。

常见问题

既然已经有 Common Name，证书为什么还需要 SAN？

因为客户端已经不看 Common Name 了。RFC 2818 在 2000 年就把它用于主机名匹配一事标为废弃，Chrome 在 2017 年的 58 版停止支持，其他浏览器随后跟进；如今 CA/Browser Forum 的基线要求更是强制 CA 无论如何都要把所有名称写进 subjectAltName 扩展。主机名只出现在 CN 里的 CSR，要么被 CA 拒绝，要么产出一张所有现代浏览器都以 ERR_CERT_COMMON_NAME_INVALID 拒绝的证书。而各种工具仍然会显示 CN，这正是这个错误容易被忽略的原因。

CSR 上的自签名证明了什么？

证明制作这份请求的一方持有与其中公钥配对的私钥。请求用那把密钥对自身内容签名，因此 CA 只凭这份请求就能校验——正是这一点使得别人无法拿着你的公钥去构造 CSR、从而取得以你为名的证书。它不证明域名归属，那由 CA 另行核验。如果签名校验不过，说明文件在签名之后被改动过，通常是传输中损坏或被手工编辑过。

在这里粘贴 CSR 安全吗？

安全。CSR 里只有公开信息——你申请的名称和密钥对的公开那一半——而且它本来就是要交给 CA 的。即便如此，本页面也不会把它发送到任何地方：ASN.1 解析和签名校验都通过 WebCrypto 在你的浏览器里完成，你可以打开页面后断开网络再粘贴一份请求来确认。私钥则完全是另一回事：任何地方都不要粘贴；如果贴到这里，本工具会拒绝。

为什么有时签名没有被校验？

因为校验需要浏览器能导入这把公钥，而 WebCrypto 支持的算法是固定的那几种。RSA 和 NIST 曲线上的 ECDSA 到处都能用；Ed25519 在较新的浏览器里可用，在旧浏览器上会被跳过。当密钥类型无法导入时，本工具会明说签名未经校验，而不是暗示它通过了——未校验的签名和有效的签名是截然不同的两件事，把二者混为一谈才是这个工具真正可能造成危害的地方。

这里也能解码证书吗？

不能——证书和证书签名请求是不同的结构，本工具只读 PKCS#10 请求。CSR 是你发出去的东西，证书是回来的东西，证书里有颁发者、有效期窗口和 CA 的签名，而这些在请求里一个都没有。请把 -----BEGIN CERTIFICATE----- 的块放进证书解码器。

挑战口令是做什么用的？

它是原始 PKCS#10 规范里的一个可选属性，本意是作为共享秘密，让你日后可以据此请求 CA 吊销证书。现在几乎没有公共 CA 还在用它——吊销是通过你登录认证的账户来处理的——但一些企业环境和 SCEP 注册流程仍然要求填写，微软的证书服务也会读取这个值。如果它被设置了，本工具会显示出来；这值得知道，因为它是明文随请求一起传输的。

相关工具