CSR（证书签名请求）解码器
粘贴 PEM 格式的 CSR（证书签名请求），即可在提交 CA 之前确认待申请的 CN、SAN、组织名称与公钥算法。免费工具，帮助提前发现录入错误。
CSR 解码器是什么
CSR 解码器是一款免费工具，只需粘贴 PEM 格式的 CSR（Certificate Signing Request，证书签名请求），即可一览待申请的 Subject（CN、组织名称等）、SAN（Subject Alternative Name，使用者备用名称）、公钥算法与签名算法。在提交给 CA（证书颁发机构）之前，可以当场确认录入内容是否符合预期。
与解析已签发证书的「X.509 证书解码器」不同，本工具面向的是尚处于 CA 审核、签发之前阶段的 CSR 本身。适合在证书尚未签发，或重新生成私钥之前做最终确认。
CSR 解码器的使用方法
- 粘贴 PEM 格式的 CSR 将以「-----BEGIN CERTIFICATE REQUEST-----」开头的文本原样粘贴到输入框中。
- 支持一次粘贴多个 CSR 将多个 CSR 一起粘贴时，工具会按区块自动识别并分别检测。
- 点击「解析」按钮 确认检测到的 CSR 数量无误后，点击按钮由服务器端进行解析。
- 查看解析结果 Subject、SAN、公钥算法等信息将以列表形式展示。
用好本工具的小技巧
- 提交前请务必确认 CN（通用名称）与 SAN 中是否包含了所有需要签发的主机名。SAN 遗漏会带来重新申请的麻烦。
- 此时顺便检查公钥算法是否低于 RSA 2048 位，或是否使用了不推荐的 EC 曲线，能有效降低被 CA 退回审核的概率。
- 在多台服务器复用同一份 CSR 之前，请再次核对 Subject 与 SAN 中的组织名称、域名是否与实际申请对象一致。
- 本工具只能确认 CSR 中记载的申请内容，CA 最终实际签发哪些 SAN 仍取决于审核结果，可能会有出入。
适用场景
提交 CA 前的最终确认
在购买付费 SSL 证书之前，确认生成 CSR 时录入的 CN、SAN 是否正确。
验证内部系统的 CSR 生成流程
即使不熟悉命令行操作的负责人，也能直观确认通过 openssl req 等方式生成的 CSR 内容是否符合预期。
核查历史签发申请的 CSR 内容
无需接触私钥，即可安全地重新核对以文件形式保存的历史 CSR 内容。
排查多域名证书的 SAN 遗漏
在用一张证书统一申请多个主机名时，可在提交前排查 SAN 是否有遗漏。
术语表
- CSR（证书签名请求）
- Certificate Signing Request 的缩写。向 CA 申请签发证书时提交的数据，包含公钥与申请信息（Subject、SAN 等）。
- CA（证书颁发机构）
- Certificate Authority 的缩写，是审核 CSR 内容并实际签发 SSL/TLS 证书的第三方机构。
- CN（通用名称）
- Subject 中表示证书主要对象的主机名或服务名称的字段。早期浏览器仅校验 CN，如今则以 SAN 为优先依据。
- SAN（使用者备用名称）
- 额外列举证书生效的主机名或 IP 地址的扩展字段。在 CSR 阶段，它被记录为「Requested Extensions（请求的扩展）」。
- Requested Extensions（请求的扩展）
- CSR 申请者要求「签发时请包含此扩展」的属性，SAN 便包含在其中，但 CA 未必会原样采纳。
- 公钥算法
- CSR 中所含公钥的生成方式，常见有 RSA、EC（椭圆曲线密码）等，强度会因密钥长度或曲线选择而不同。
常见问题
闲话 ― CSR 为什么要包含「签名」
仔细观察 CSR 的内容会发现，Subject、公钥信息之后紧跟着签名算法与签名值。这乍看有些奇怪：一份用来请求 CA「请为我签发证书」的文件，为什么会包含自己的签名呢？答案在于「Proof of Possession（私钥持有证明）」这一设计思想。申请者用与 CSR 中所附公钥配对的私钥，对整个 CSR 内容（Subject、公钥等）进行签名，从而向 CA 证明「自己确实持有与该公钥对应的私钥」。如果有人擅自用他人的公钥拼凑出一份 CSR，由于没有对应的私钥就无法生成正确的签名，这一机制也就有效防止了冒名申请。
CSR 这套机制最早由 RSA 公司制定的公钥密码标准系列 PKCS（Public-Key Cryptography Standards）中的 PKCS#10 规定，公布于 1986 年。如今 IETF 已将其以 RFC 2986 的形式重新定义，但在实际工作中，「PKCS#10」这一称呼至今仍被广泛使用。它在 TLS 证书体系中并不起眼，却是整个证书签发流程不可或缺的起点。
在 CSR 的 Requested Extensions（请求的扩展）中加入 SAN 的标准化其实并不算久远。最初的 CSR 标准（PKCS#10）只考虑了 Subject 和 CN，随着多域名证书、通配符证书的普及，各家 CA 才逐渐以各自的方式接受 SAN 信息。如今 openssl 等主流工具已经标准支持通过 RFC 2985 定义的 Extension Request 机制将 SAN 写入 CSR，本工具也正是从这一标准位置（Attributes 内的 extensionRequest 属性）读取 SAN 信息的。