SSL 证书解码
一次粘贴多张 PEM 证书（完整证书链），逐张解析有效期、剩余天数与是否过期，检查 issuer / subject 的链顺序，并用 SAN 里的 DNS / IP 条目匹配你输入的域名（支持 *.example.com 通配符）。只解析本地文本，不发起任何 TLS 连接。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
证书链与域名
解析由自研的 ASN.1 / X.509 解析器在本地完成（复用 pem-decoder 与 certificate-decoder 的实现），只读取你粘贴的文本。
解析结果
粘贴 PEM 证书链（可带域名）后点击「解析证书链」。
这个工具能做什么
- 拿到服务器上导出的 fullchain.pem 后，一次粘贴整条链，确认每张证书的有效期与剩余天数，避免「换了叶子证书但中间证书忘了换」这种经典事故。
- 排查域名不匹配：填上出问题的域名，工具会告诉你命中的是精确 SAN、通配符还是只命中了已废弃的 CN，并指出是不是 `*.example.com` 写成了 `*.sub.example.com`。
- 确认链顺序：正确的顺序是「终端实体证书 → 中间证书 → 根证书」，顺序颠倒或缺少中间证书时，issuer / subject 的衔接检查会直接指出是哪一张。
- 做续期前的体检：把新的证书链先粘进来跑一遍，确认没写错域名、没配错 CA 标记（basicConstraints 的 CA:TRUE/FALSE）。
示例
输入
按顺序粘贴三张证书（openssl 生成的测试链）：leaf（CN=www.example.com，SAN 含 example.com、*.example.com、127.0.0.1、admin@example.com）+ inter（UniKit Test Intermediate CA，pathlen:0）+ root（UniKit Test Root CA，自签）；域名填 www.example.com
输出
共 3 张证书；顺序检查通过（0/1/2 的 issuer 都与下一张的 subject 一致，链尾是自签根证书）；有效期检查通过；域名匹配成功，命中条目 *.example.com（SAN 通配符匹配）；leaf 有效期 2026-10-10T08:28:53.000Z → 2027-11-11T08:28:53.000Z，根证书有效期到 2036-10-07T08:28:53.000Z
把域名改成 a.b.example.com 会得到「不匹配」：通配符只覆盖一级标签；改成 127.0.0.1 则命中 SAN 里的 IP 条目。
常见问题
这个工具会去连接我的服务器抓证书吗？
不会。它只解析你粘贴的 PEM 文本，既不发起 TLS 握手也不下载中间证书，因此不需要联网、也不存在被中间人影响的问题。要抓线上的证书请用 `openssl s_client -connect host:443 -showcerts`。
链顺序应该怎么排？
从终端实体证书（leaf）开始，接着是签发它的中间 CA，最后是自签的根 CA——这也正是 fullchain.pem 的顺序。顺序错了工具仍会解析，但会提示某一张的 issuer 与下一张的 subject 不一致；只放了 leaf + root 时也会提示，因为缺少中间证书。
`*.example.com` 到底能匹配哪些域名？
按 RFC 9525，通配符只能替换最左侧的一个标签：`*.example.com` 匹配 `www.example.com`、`api.example.com`，但不匹配 `example.com`（少一级）也不匹配 `a.b.example.com`（多一级）。工具会按这个规则匹配，并告诉你命中的是精确条目还是通配符条目。
为什么提示「仅 CN 匹配」？
因为这张证书的 SAN 里没有任何 DNS 条目，工具按 RFC 6125 的旧规则回退到 CN。现代浏览器（Chrome、Safari、Edge）只看 SAN，只有 CN 的证书会直接被判为无效，所以看到这个提示就应该重新签发带 SAN 的证书。
「顺序正确」是否代表链可信？
不代表。这里的检查只是文本层面的：上一张证书的 issuer 是否等于下一张的 subject，链尾是否自签。真正的可信度还需要用签发者的公钥验证签名、检查有效期、吊销状态（CRL / OCSP）以及根证书是否在本机信任库里——这些都需要额外的信任库或网络访问，本工具明确不做。
关键词：ssl certificatecertificate chainpem chainsan matchwildcard certificateexpiry checkSSL 证书证书链有效期剩余天数域名匹配通配符证书