证书与密钥匹配器

放入任意组合的证书、私钥和 CSR——PEM 或 DER——这个工作台会证明哪把密钥与哪份证书匹配，把证书排成链，转换格式并生成 CSR。私钥从不离开你的浏览器：一切都在这个标签页中本地解析，密钥只保存在内存中，从不上传、记录或存储，本页面不发出任何网络请求。如需深入解码一份证书，请使用SSL 证书解析器；如需快速生成自签名证书，请使用自签名证书生成器。

添加证书、密钥和 CSR

匹配结论

添加一份证书和一把私钥，结论就会出现在这里：哪把密钥与哪份证书匹配——由相同的公钥证明，绝不靠文件名猜测。

链构建器

加载两份或更多证书后，构建器会按颁发者与主题名称的匹配把它们排序：叶子在前，然后是中间证书，最后是根——然后，在浏览器的密码学能力允许时，它会校验每一环上的实际签名，而不是只信任名称。

生成 CSR

为在这里、你的浏览器中生成的密钥制作一份证书签名请求：填写主题，选择密钥类型，下载 CSR 发送给你的 CA——外加私钥，私钥必须由你自己妥善保存。密钥只在这里显示；本页面不会保留它。

匹配实际上是如何工作的

证书和私钥不是一个文件的两半；它们是共享同一个数学对象的两个文件。生成密钥对时，公钥一半被放进证书（以及用该密钥制作的任何 CSR）中，私钥一半则留在密钥文件中。两个条目恰好在它们携带同一把公钥时匹配——对 RSA 而言是相同的模数和指数；对 EC 而言是同一条曲线上的同一个点。本页面把这把公钥编码进它的标准包装（SubjectPublicKeyInfo），用 SHA-256 对编码做哈希，并按该哈希对每个已加载条目分组。因此每张卡片上显示的哈希是证据，而不是摘要：相同的哈希不可能是巧合，不匹配同样确定，这就是为什么结论可以直白地说——这把密钥与这份证书匹配，或者没有任何已加载的密钥匹配。这一检查能抓住的经典故障写在当你的密钥与证书不匹配时里：凌晨 2 点的重载，磁盘上续好的证书属于另一把密钥，而不是服务器已加载的那一把。

文件名什么都证明不了。一个目录里满是 server.crt、server.key、final-v2.pem 和一份去年续签尝试留下的 CSR，这是接手来的基础设施的常态，而这些名称是考古学，不是文档。相同的文件扩展名或相同的日期同样证明不了什么。那么传统的 openssl 检查呢——比较证书的模数哈希与密钥的模数哈希？那正是本页面的检查，只是它限于 RSA、一次只能查一对，而且完全漏掉 EC 密钥，因为 EC 密钥没有模数。公钥指纹统一覆盖每种算法，这就是它在这里作为分组键的原因。

链、顺序，以及“已验证”的含义

服务器应当先出示叶子证书，然后按顺序出示每一份中间证书，这样客户端就能沿颁发者到主题的链接一路走到它已经信任的根。以错误的顺序出示同样的证书——或者缺了一份中间证书——就会产生经典的“unable to get local issuer certificate”系列错误，来自那些无法自己获取缺失环节的客户端。上面的构建器仅从名称重建顺序，这总是做得到的，然后它更进一步：对 RSA 和 ECDSA 签名，它导入颁发者的公钥并校验对证书签名内容的签名。标有签名已验证的环节是经过密码学证明的。标有仅名称匹配的环节则不是——名称能接上，但签名使用的算法本平台不校验（RSA-PSS 是常见情形），页面会如实说明，而不是把名称匹配包装成证明。如果签名校验失败，名称只是巧合或伪造，构建器会用红色显示失败，而不是悄悄产出一个包。

格式：PEM、DER 与 .pfx 问题

PEM 是把 DER 字节用 Base64 包装并加上带标签的头；DER 是原始编码。两者之间转换不损失什么，也不证明什么——是同一个对象换了信封——这就是为什么每张卡片都提供两种下载。Windows 和一些 Java 工具偏好 DER 或 PKCS#12；大多数 Unix 工具想要 PEM。PKCS#12（.pfx/.p12）是另一回事：它是一个带自身完整性 MAC 的加密容器，做出一个每个消费者都接受、且保护名副其实的文件，不是应该在网页里手工拼凑的东西。本工具刻意不提供它。要自己打包一对已匹配的文件，就在文件所在之处运行 openssl：openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx——在本页面告诉你哪把密钥、哪份证书和哪条链真正配套之后。

解析与组链是为本站手写的 DER 代码（BSD 风格，无第三方解析器）；哈希、签名验证和密钥生成使用浏览器的 WebCrypto。本工具的任何部分都不发出网络请求。

常见问题

匹配器如何证明一把密钥和一份证书配套？

靠比较公钥，而不是文件。每份证书、CSR 和私钥都能给出同一份编码的公钥（SubjectPublicKeyInfo）；本页面用 SHA-256 对它做哈希，并把哈希一致的条目分组。公钥相同意味着这把私钥在数学上就是这份证书签发时所用的那一把——与 openssl 用模数比较所做的检查相同，只是一次对所有文件进行，且对 EC 密钥和 RSA 同样适用。

把真实的私钥加载到网页里安全吗？

在本页面上是安全的，因为它的构建方式：一切都在你的浏览器中本地解析，密钥只保存在这个标签页的内存中，什么都不上传、不记录、不写入任何存储，本页面不发出网络请求。要保持的习惯是：在粘贴密钥之前，先在任何工具上核查这一说法——并且永远不要把私钥粘贴到聊天、工单或在远程处理它的服务器端“检查器”中。

链构建器中的“仅名称匹配”是什么意思？

链构建器先把每份证书的颁发者名称与下一份证书的主题名称匹配来排序，然后尝试用颁发者的公钥验证实际签名。当签名算法是浏览器的 WebCrypto 能校验的算法时（实际中是 RSA 和 ECDSA），这一环会被标为“签名已验证”，或者校验失败时标为“签名失败”。其他一切情况——RSA-PSS 是常见情形——会被如实标为“仅名称匹配”：名称能对上，但本页面没有用密码学证明这一环。

为什么没有 PKCS#12（.pfx）导出？

PKCS#12 文件把密钥和证书包装在基于口令的加密中，并带 MAC 完整性——这是一个需要谨慎、经过充分测试的编码的格式。与其发布一个手工拼凑的版本、可能产出其他软件拒绝的文件（或者更糟，保护薄弱的密钥），本页面在 PEM 和 DER 之间转换，把 .pfx 打包留给 openssl：页面上给出了命令，你可以在密钥已经所在之处运行它。

本页面能读取加密的私钥吗？

它能识别出一把并如实说明，但不能使用它：加密的（口令保护的）密钥在解密之前不会暴露其公钥，而配对正是基于公钥。用 openssl 在本地解密一份副本（pkcs8 -topk8 -nocrypt，或 rsa/ec）并加载解密后的副本——在一台你信任的机器上，之后删除该副本。