Chrome 开始淘汰非 TLS 专用的 CA 证书层级

2026 年 6 月 15 日，谷歌的 Chrome 根证书计划开始淘汰“一套层级多种用途”的 CA 证书体系。按照政策第 1.8 版，从这一天起新向 CCADB 披露的子 CA 只能用于 TLS 服务器认证；从 2027 年 3 月 15 日起，链到 Chrome 信任根的每张 TLS 证书也只能包含 serverAuth。实际效果是：公开 TLS 证书正在变成“只能给服务器用”的证书。

发生了什么

Chrome 现在要求进入其根证书计划的根证书专用于 TLS 服务器认证，避免其他用途的兼容性需求拖慢 Web PKI 的演进。过去，一张根证书及其中间证书可以同时签发多种用途的证书：TLS 服务器、TLS 客户端、电子邮件等。具体日期：

• 2026-06-15：开始淘汰。此后向 CCADB 披露的子 CA，其扩展密钥用途只能包含 serverAuth。
• 2027-03-15（尚未生效）：此日及以后签发的用户证书必须包含只有 serverAuth 的 EKU 扩展，不能再有 clientAuth。

政策 1.8 版还规定了其他日期：2026-06-15 起，所有 TLS 预证书必须在证书签发前写入至少一个 Chrome 认可的 CT 日志；2027-03-15 起（尚未生效），子 CA 必须接入自动化方案；2027-09-15 起（尚未生效），Chrome 根证书库对每个 CA 所有者最多收录两个根证书。需要澄清的是：Chrome 并没有从 2026-06-15 起不信任含 clientAuth 的叶子证书，针对叶子证书的规定适用于 2027-03-15 起签发的证书。

同一份政策还限制根证书的“年龄”：密钥材料超过 15 年的根证书将被移出 Chrome 的信任范围。密钥生成于 2006–2007 年的根证书约在 2026 年 4 月 15 日移除，2008–2009 年的约在 2027 年 4 月 15 日移除（尚未到来）。

影响谁

只把证书用于 HTTPS 网站的用户，按正常流程续期即可，无需额外操作。受影响的是下面三类：

• 证书颁发机构：需要建立专用的新层级。Let's Encrypt 的 Generation Y 中间证书已经不含 clientAuth，并且在 2026 年 2 月去掉了默认证书里的 clientAuth。
• 用公开 TLS 证书做客户端认证的单位：比如用公开证书在双向 TLS 中认证合作方 API、服务器之间互相认证。公开 CA 不再签发 clientAuth 之后，这类系统必须改用私有 CA。在阿里云、腾讯云等平台购买的证书同样来自公开 CA，也会跟着变化。
• 使用很老根证书签发的证书的网站：根证书被移除后，只能链到它的证书在 Chrome 中将验证失败。通常 CA 会提前把客户迁移到新根或交叉签名路径。

360、QQ 浏览器等基于 Chromium 的国内浏览器是否采用同一套根证书库，取决于各厂商自己的实现，不能简单等同于 Chrome。

需要做什么

凡是依赖公开证书 clientAuth 的系统，都要迁到私有 CA。先检查部署的证书和作为客户端出示的证书的 EKU：

openssl x509 -in cert.pem -noout -ext extendedKeyUsage

如果有系统依赖公开证书里的 TLS Web Client Authentication，要在 CA 停止签发之前规划好迁移到私有 CA，否则会遇到 clientAuth EKU 被移除中列出的各种报错。

查看服务器证书链最终指向哪张根证书：

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *i:' | tail -n 1

私有 CA 的搭建方法见 mTLS 指南，证书解析工具可以查看 EKU 和签发者信息，各浏览器的根证书移除和不信任决定汇总在根证书计划时间线中。