你有没有过用同一把钥匙开家门、办公室、车，还有那个高安全级别储物柜的经历？方便是方便，可一旦弄丢，每一把锁都面临风险。在数字安全世界里，多用途证书（multi-use certificates）做的就是同样的事——一旦某张证书被攻破，它所承载的多种功能都会暴露。Chrome 正试图通过对其数字证书信任机制的一次重大重构来修补这个问题。

Google 的 Chrome 根程序（Chrome Root Program）正在经历一次严肃的架构级更新。其核心目标，是收紧对信任链的控制、降低证书角色之间的耦合复杂度，并推动整个 Web 走向一种"用途专精化"的 PKI（公钥基础设施，Public Key Infrastructure）。

这次转变不只是合规层面的调整，它关乎人们如何重新思考互联网上的信任该如何被管理。通过为证书的使用设定更严格的边界与预期，Chrome 正在引领一场"按用途构建"的 PKI 变革——让每张证书只做它该做的事，不多也不少。

在这篇解析文章中，我们将探讨到底变了什么、为何重要、证书颁发机构（CA）如何反应，以及开发者、系统管理员和安全团队当下就需要开始做哪些准备。

Chrome 根程序：信任的基石

Chrome 安全模型的核心是《Chrome 根程序政策》（Chrome Root Program Policy），这是一份严格的框架，规定了 CA 必须满足哪些条件，其根证书才可被纳入 Chrome 的根存储（Root Store）。它涵盖了密钥管理、证书透明度（Certificate Transparency）、事件上报以及可审计合规等多方面的强控制。

在 1.1 版本中，Google 启动了"Moving Forward, Together"计划，推动更现代、更绑定用途的 PKI 体系。它强调持续审计、更严格的证书生命周期控制，以及对未达标 CA 的快速取消信任。信息很明确：信任是 earned（赢得的）、monitored（被监控的）、revocable（可撤销的）。

核心转变一：Chrome 收紧 TLS 信任模型（废除客户端认证）

Chrome 根程序中最具冲击力的一项变化，是弃用公开受信任的 SSL/TLS 证书中的 clientAuth（客户端认证）用途。这一动作源于政策对"专用 TLS 服务器认证 PKI 层级"的强调。简而言之：每张证书应当只服务于单一、明确定义的用途，不再有"全能型"证书。

到底改了什么？

• 中间证书：自 2025 年 6 月 15 日起，公开 CA 不再被允许签发同时包含 serverAuth 与 clientAuth 两类 EKU 的中间证书。这一上游限制强制角色清晰分离，尤其影响 mTLS（双向 TLS）和双用途层级。
• 叶子证书：到 2026 年 6 月 15 日，Chrome 将停止信任新签发的同时包含 serverAuth 与 clientAuth EKU 的叶子证书。这标志着信任链对"单用途证书"的全面承诺。

快速概览

• EKU（Extended Key Usage，扩展密钥用途）：这是一项关键的 X.509 证书扩展，定义了证书"被允许做什么"。例如，id-kp-serverAuth 用于验证 Web 服务器（HTTPS），而 id-kp-clientAuth 用于在安全连接中验证客户端身份。
• 客户端认证：主要用于双向 TLS（mTLS），即客户端与服务器互相出示证书以核验彼此身份。常见于企业内网、IoT 通信以及内部服务到服务的认证场景。

但 Chrome 为什么要做这个改变？

将 clientAuth 与 serverAuth 在公开证书中拆分，源于安全与运维清晰性两方面考量：

• 过度负载的证书会放大风险：把 clientAuth 和 serverAuth 捆绑在一起，无异于发出一把万能钥匙。一旦泄露，服务器校验与客户端认证双双受影响，攻击面直接翻倍。
• 厘清公开与私有的边界：clientAuth 通常用于内部系统、企业 VPN、IoT 网络与 mTLS 部署，这些场景更适合私有 CA。Chrome 的政策鼓励将 serverAuth 留在面向公众的站点，把 clientAuth 推入私有 PKI 领域。
• 更易审计与执行策略：用途绑定的证书简化了合规、监控与事件响应。当角色分离后，CA、浏览器和企业都更容易追踪使用情况、避免误配置。

正如 Google 所言："目标是通过鼓励用途分离来改善整个生态。"在 Chrome 精简证书用途以降低滥用风险的同时，它也在收紧"谁来签发这些证书"的门槛——毕竟，如果签发证书的 CA 本身不可信，一张安全的证书也将失去意义。这就引出了 Chrome 的下一个大动作。

核心转变二：主动取消 CA 信任与 SCTNotAfter 机制

除了弃用 clientAuth，Chrome 根程序对 CA 的合规与问责采取了更激进的立场。这正是"Chrome 根存储即将发生的变更"真正发挥作用的地方，意味着对受信任 CA 的更深层筛选。

近期的取消信任行动：中华电信与 NetLock

2025 年 5 月 30 日，Google 宣布将取消对中华电信（台湾）与 NetLock（匈牙利）新签发 TLS 证书的默认信任。自约 2025 年 8 月 1 日随 Chrome 139 推送起，Chrome 将停止信任这两家 CA 在 2025 年 7 月 31 日 23:59:59 UTC 之后签发的证书。

为何取消信任？Google 的决定并非任意而为，而是基于反复出现的隐患模式，包括：

• 持续的合规失败；
• 未履行修复承诺；
• 在公开安全事件后缺乏可衡量的改进进展。

考虑到公开 CA 所承载的关键信任，Google 认定这两家继续留在 Chrome 根存储中已不再合理。这一举措是保护用户、维护 Web 信任模型完整性的主动防御。

SCTNotAfter 取消信任机制：一种更聪明的做法

不同于以往那种破坏性强的"一刀切"取消信任（想想 Symantec），Google 采用了更精细的方法：SCTNotAfter。它让 Chrome 能够在不让现有站点"一夜之间全部崩溃"的前提下，取消对中华电信、NetLock 等 CA 的信任。

什么是 SCT？签名证书时间戳（Signed Certificate Timestamp，SCT）是一种密码学证明，表明某张证书已被记录进证书透明度（Certificate Transparency，CT）日志——一个公开的、可审计的系统，用于帮助发现 CA 的不当行为。

SCTNotAfter 如何工作：Chrome 设定一个 SCTNotAfter 截止时间（例如 2025 年 8 月 1 日）。被取消信任的 CA 签发的任何证书，必须至少包含一个早于该截止时间的 SCT。在该日期之后签发的证书无论实际签发日为何，都会验证失败。

这意味着，较旧、仍然有效的证书会继续工作直到自然过期，而新证书则被即时拦截，且不会触发大范围的"连接非私密"错误。这是一种干净、前瞻的取消信任模型，以最小的用户干扰执行安全策略。

你需要了解什么，又该怎么做

这些变更——尤其是 clientAuth 的弃用——值得你认真审视自己的 PKI 架构，特别是如果你的组织正将公开证书用于客户端认证。

只是运营一个标准网站？

如果你的站点仅将 SSL/TLS 证书用于 serverAuth（即 HTTPS 的加密与身份用途），只要你使用的是合规公开 CA 签发的证书，基本不受影响。尽管如此，持续关注根存储的变更、了解哪些 CA 的信任状态可能生变，仍然很重要。

在使用双向 TLS（mTLS）或客户端认证？

如果你的系统依赖公开受信任证书来处理客户端场景，建议立即行动。常见情形包括：

• 使用客户端证书进行用户/设备认证的企业 VPN 或内部应用；
• 同一张证书同时用于 serverAuth 与 clientAuth 的 IoT 部署；
• 由公开 CA 支撑的分布式系统内部服务到服务通信。

在这些情况下，你应当开始规划向私有 CA 迁移，或申请专用的 TLS 客户端证书，因为多用途的公开证书将不再被支持。

适配的最佳实践

• 面向公众的网站：继续使用来自受信任公开 CA（如 DigiCert、Sectigo 等）的 serverAuth 证书，确保你的 CA 符合 Chrome 更新后的根程序政策。
• 客户端认证 / mTLS：迁移到私有 CA，或使用专用的 tlsclient 证书。对于内部应用、IoT 或企业 mTLS，私有 PKI 能提供更强控制并契合最佳实践。部分公开 CA 通过 API 为小众需求提供 tlsclient 证书。
• 来自被取消信任 CA 的证书：替换任何由中华电信或 NetLock 签发的证书。2025 年 7 月 31 日之后签发的证书会触发 Chrome 警告，请主动提前替换。

证书颁发机构的动作

主流 CA 已经开始对齐 Chrome 的更新政策：

• DigiCert：默认仅签发 serverAuth；公开证书中 clientAuth 全面淘汰。2025 年 10 月 1 日（默认）→ 2026 年 5 月 1 日（全面）。
• Sectigo：公开证书中 clientAuth 分阶段退出。2025 年 9 月 15 日启动 → 2026 年 5 月 15 日结束。
• 其他 CA（概览）：许多领先 CA 正转向 serverAuth 与 clientAuth 各自的专用层级。可预期公开 TLS 证书将默认采用单用途配置，或通过 API、私有层级签发仅含 clientAuth 的证书。到 2026 年中，多数公开 CA 将完成全面过渡。如果你在 2025 年后向公开 CA 申请新 SSL 证书，clientAuth 很可能被自动剥离，或改由专用 serverAuth 层级签发。

行动清单（TL;DR）

• 审计现有证书：使用 openssl 或证书检查工具，以及 Chrome 开发者工具，识别任何包含 clientAuth 的公开受信任证书。
• 规划 mTLS / 客户端认证迁移：若你依赖公开证书做客户端认证，应设计向私有 CA 或专用 tlsclient 证书过渡的策略。
• 分离 PKI 层级：主动将面向公众的 serverAuth 需求与内部的 clientAuth 需求分开。
• 记录 CA 时间线：在日历中标记你的 CA 提供的关键过渡日期，提前预判变化。
• 更新内部政策：调整采购与签发政策，2025 年后不再申请多用途公开证书。
• 替换被取消信任的证书：若在使用中华电信或 NetLock，务必在 2025 年 8 月 1 日前优先从新的受信任公开 CA 替换。
• 在预发环境测试：在全量上线生产前，于预发环境中模拟证书链变更与可能的取消信任。
• 持续关注 Chrome 根程序：定期查阅《Chrome 根程序政策》与 Google 安全博客，获取受信任 CA 与政策变更的持续更新。

更宏观的趋势与未来展望

clientAuth 的弃用与 Chrome 主动取消 CA 信任的措施，反映了 Web PKI 格局更广泛的演进。值得关注的关键发展：

• 更短的证书生命周期：公开 TLS 证书的有效期正呈下行趋势——从今天最长 13 个月，向 CA/B 论坛规划的 2029 年 47 天周期演进——以缩小密钥泄露窗口、推动自动化续期工作流。
• 更广的证书透明度日志：更严格的 CT 要求正在全行业被采纳，提升证书签发的公开可见性，让误签发更难隐藏。
• 更严的 CA 合规与审计：浏览器现在要求 CA 具备严密的运维安全、事件响应流程与持续合规，对屡次失败者快速取消信任。
• 自动化与用途专精 PKI：重心正从"包揽一切"的多用途证书，转向高度自动化、范围狭窄的 PKI——每张证书拥有单一、明确的角色与生命周期。

结语

所有这些趋势都在强化 Chrome 的使命：构建一个更安全、更透明的互联网，让证书只做它们该做的事。这不只是在淘汰旧做法，更是在锻造一个更安全、透明、可管理的证书生态。对于开发者、系统管理员和 DevSecOps 团队而言，现在是时候：

• 审计你当前的证书清单；
• 规划向用途专精 PKI 或私有 CA 的迁移；
• 实现证书签发与续期的自动化。

到 2026 年，通用型多用途证书将成为历史。今天采用专精化、自动化的 PKI 架构，将为你的基础设施面向未来、维持用户信任做好准备。