证书链追溯不到受信任的根：新根交叉签名与私有 CA

这条结论的意思很具体:服务器发来的链,最上面那张证书的颁发者,不在验证方的信任库里。链断在了半空中,而不是「这家 CA 有问题」。

两种完全不同的成因,修法也完全不同。绝大多数情况是第一种:链没发全。CA 启用新根时会用旧根交叉签名一份,少了这一张,尚未收录新根的客户端就接不上。第二种才是真的由私有 CA 签发。

先分清是哪一种

看颁发者是不是一家公开 CA。如果证书是 Let's Encrypt、DigiCert、Sectigo、Amazon 这类签的,那就是第一种——链没发全,不是 CA 不受信任。

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

2 张通常就是问题所在:服务器只发了「证书 + 中间证书」。3 张说明它还发了交叉签名的那一张,这是新根切换期间正确的做法。

成因一:新根切换期,链少发了交叉签名证书

CA 启用一个新根时,新根自己有一份自签名版本,同时会用已经被广泛信任的老根再签一份。这份「交叉签名」的副本让还没收录新根的客户端也能一路验到老根。

所以链上会出现一张名字里带 Root、却被标成「中间证书」的东西。这不是标错:那一份不是自签名的,它的颁发者是老根,它在这条链里承担的正是中间证书的角色。

怎么修

1. 用 CA 给的完整链文件部署,通常叫 fullchain.pem,而不是只有一张的 cert.pem。
2. nginx 的 ssl_certificate 就应该指向 fullchain 文件——它期望「证书在前、中间证书在后」拼在同一个文件里。
3. Apache 用 SSLCertificateChainFile,或在新版本里同样把完整链放进 SSLCertificateFile。
4. 改完重载服务,再用上面那条 openssl 命令确认张数变了。

ssl_certificate     /etc/ssl/example.com/fullchain.pem;  # 不是 cert.pem
ssl_certificate_key /etc/ssl/example.com/privkey.pem;

成因二:确实由私有 CA 签发

如果颁发者是公司内部的 CA、某个自建的根,或者名字你完全没见过,那就是第二种。这时公网访客的浏览器确实不会信任它,而且没有任何服务器配置能改变这一点——信任来自客户端的信任库,不来自服务器。

• 内网服务:把私有根证书装进内网机器的信任库,这是私有 CA 的正常用法。
• 公网服务:必须换成公开 CA 签发的证书。本站基于 Let's Encrypt 的签发是免费的。
• 两者混用:同一个域名在内外网走不同的证书是可行的,但要确认公网那一侧用的是公开 CA。