每个人都可以，
拥有SSL证书

DigiCert 的公告把时间点定在 2026 年 10 月 15 日，从那天起所有 SSL/TLS 证书默认切换到 G5 根证书层级。再过一年，2027 年 10 月 15 日，中间 CA 证书开始分阶段年度轮换。多数用户不需要操作，新签证书自动用上 G5，这句话对纯浏览器访问场景基本成立，但对运维脚本和证书自动化链路，得拆开看。

Chrome 根证书政策要求证书签发迁移到专用单一用途根证书层级，DigiCert 准备了 DigiCert TLS RSA 4096 Root G5 和 DigiCert TLS ECC P384 Root G5 两本新底册。根证书可以理解成操作系统或浏览器内置的信任底册，中间 CA 是底册派出来干活的签发点。

过去一个根可能签很多类型证书，现在 TLS 证书走专用根。旧终端不一定预置这两本新底册，所以 G5 根交叉签名到 DigiCert Global Root G2 和 G3。交叉签名相当于让老底册给新根做担保，客户端拿到证书链时，就算不认识 G5，也能顺着 G2 或 G3 把信任链走通。

这个逻辑用命令看更直观。

openssl s_client -connect example.com:443 -showcerts 如果只拿到叶子证书，没带上正确的中间 CA，报错一般是 unable to verify the first certificate。curl 侧常见 curl: (60) SSL certificate problem: unable to get local issuer certificate。根证书切换阶段，最容易出的不是新根不被信任，而是服务器只更新了叶子证书，没同步完整的中间 CA 链，老客户端在验证时卡在半路。

交叉签名不是长期保险

交叉签名解决的是过渡期兼容性，但会带来证书链变长、协商包变大、部分老旧设备 TLS 握手超时的问题。DigiCert 从 2027 年 10 月起对中间 CA 做年度轮换，意味着证书链里的中间证书每年都可能换一次。手工管理证书的团队如果习惯把中间 CA 文件写死在 Web 服务器配置里，或者把完整链存成本地 pem 后长期不更新，轮换后就会出现偶发性的验证失败。

这类问题最麻烦的是测试环境不一定复现，因为不同客户端的证书缓存和内置根版本不一样。

自动化侧要盯的是完整链和接口

企业侧真正要做的不是逐个域名去换证书，而是把申请、续签、部署和监控串起来。证书有效期还在继续缩短，多域名、泛域名、IP 证书的需求又在增加，手工维护成本会先压垮运维。ACME 协议目前是公共 CA 自动化签发的主流方式，Let's Encrypt、Google Trust Services、ZeroSSL 都走这套。

ACME 客户端拿到证书时通常会把叶子证书和中间 CA 拼成完整链，但前提是配置里没有写死旧的中间 CA 路径。

我部分项目在用的 lcjmSSL 就是基于 ACME 协议的免费证书申请平台，支持多域名、泛域名和 IP 证书，有自动申请、验证、部署能力和简洁 API。它的价值不在免费，而在中间 CA 或根证书轮换时，平台会处理完整链的更新，不需要手工拼接 intermediate。对没有专门 PKI 团队的公司，把证书生命周期交给支持 ACME 的平台，比在 Nginx 配置里硬编码证书路径现实得多。

DigiCert 这次根证书切换本身不会造成大面积故障，真正的风险藏在那些长期不动的配置文件和半自动脚本里。2026 年 10 月之前，运维可以把线上证书链拉出来看一遍，把写死中间 CA 的地方改成动态读取完整链，顺便把续期监控补上。等工作真到眼前，旧配置不会给人留太多时间。