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 信任库不能证明所有浏览器都兼容。

来源