证书链是一条应当能打印出来的路径

Mon, 08 Jun 2026 00:00:00 +0000

TLS 客户端必须构建通向既有信任锚的有效证书路径，并验证请求的主机名。打印证书有助于诊断，但单靠打印不能证明这两点。

叶证书不是全部

端点首先出示叶证书。其中包含公钥、有效期，以及用于主机名检查的主体备用名称。公共 CA 的部署通常还应发送构建路径所需的中间证书。缺少中间证书时，没有缓存它、也无法另行取得它的客户端可能失败。

通常不必发送自签名根证书：信任来自客户端配置的信任锚，而不是服务器把某张证书放进列表。主体名称包含“Root”的交叉签名证书，在所选路径中也可能充当中间证书。因此，证书数量本身不能判断完整性或信任。

阅读边缘实际发送的列表

OpenSSL 文档把 s_client -showcerts 定义为服务器发送的证书列表，而不是已经验证的链。本笔记先前版本记录过以下站点快照：

certificate 0: CN=www.xbcatm.com
 issuer : C=US, O=Let's Encrypt, CN=YE1
 notAfter : Nov 19 08:37:12 2026 GMT

certificate 1: CN=YE1 (intermediate)
 issuer : C=US, O=ISRG, CN=Root YE

certificate 2/3: Root YE / ISRG Root … (CA certificates)

原记录统计了四个证书块。这里没有保留原始握手日志，本轮审阅也未重现在线握手；这些值应视为历史报告，而不是当前边缘证据。Let’s Encrypt 的证书链文档确实列出 YE1 与 Root YE 的交叉签名路径，因此仅凭这些名称不能判定链无效。具体在哪张证书处终止信任，取决于客户端信任库与路径构建。

把签发授权单独看待

中间 CA 使根密钥可以保持离线，并将签发操作分离。吊销中间证书可能令依赖它的叶证书路径失效，甚至需要替换证书；并不会自动保全每张叶证书。

CAA 在签发时授权 CA 文档规定的签发者域标识。它不固定某张中间证书，不改变浏览器信任，也不能证明已有证书符合历史 CAA 策略。dns-caa-records 笔记讨论的是这项独立的策略检查。

数量用于盘点，验证用于信任

原记录使用的盘点命令如下：

$ echo | openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com -showcerts 2>/dev/null | grep 'BEGIN CERT' | wc -l
4

它产生只读网络流量，但隐藏诊断信息，且即使前面的命令失败，最后的计数仍可能成功。不要把 4 或其他固定数量设为健康阈值。只有叶证书时，应检查预期签发路径，而不是认定所有单证书链都无效。

实际验证时，应使用 OpenSSL 的 -verify_hostname 与 -verify_return_error 选项，要求检查主机名并在验证错误时失败，保留诊断信息，同时记录信任库与客户端版本。还要测试实际支持的客户端；一套 OpenSSL 信任库不能证明所有浏览器都兼容。

来源

RFC 8446 — TLS 1.3，第 4.4.2 节的证书列表顺序与可省略信任锚，已核验 2026-10-15。
RFC 5280 — X.509 PKI，第 6 节的信任锚输入与路径验证，已核验 2026-10-15。
Let’s Encrypt FAQ，证书兼容性概览，已核验 2026-10-15。
Let’s Encrypt: Chains of Trust，YE1 与 Root YE 的交叉签名路径，已核验 2026-10-15。
OpenSSL s_client，呈现列表与验证选项，已核验 2026-10-15。
RFC 8659 — CAA，签发授权与客户端信任的区别，已核验 2026-10-15。

Certificates · XB 现场笔记

证书链是一条应当能打印出来的路径

叶证书不是全部

阅读边缘实际发送的列表

把签发授权单独看待

数量用于盘点，验证用于信任

来源