摘要

  • 根证书计划的移除、撤信截止日或浏览器版本，只改变了预期政策；它不能证明每个操作系统、应用、容器或嵌入式验证器已经执行该政策。
  • 应把这项工作当作依赖方迁移：按信任来源和客户端群组测试拒绝结果，而不是只统计安装更新的设备数量。

在一个受控的假设验证场景中，一组最新 Chrome 客户端拒绝某条 TLS 证书链，而企业管理的 Windows 客户端和旧容器镜像里的服务会接受它。三次假设测试使用的是同一张证书。

这不是证书语法的边角问题，而是三套不同信任判断的清晰切面。

2024 年，Chrome 宣布针对若干 Entrust 根实施定向撤信。规则取决于证书最早的签名证书时间戳：在公布截止时间之后的证书，从 Chrome 131 起默认不再受信；截止时间之前的证书则受到不同处理。因此，这不是删除一个文件、让所有客户端在同一时刻得到同样结论，而是一条带有生效日期、浏览器版本和本地显式信任例外的接受规则。

Chrome 的架构让终端迁移问题更加明显。在 Windows、macOS、ChromeOS、Linux 和 Android 上，Chrome 已逐步转向自己的根信任库和内置验证器；iOS 上的 Chrome 仍受 Apple 平台政策约束。企业政策也曾临时允许在 Chrome 根信任库和平台验证器之间选择，而 Chrome 还可以纳入操作系统明确配置为可信的本地根。仅知道浏览器名称，无法确定它实际使用的完整信任来源。

Microsoft 的文档展示了第二类差异。其受信任根证书计划区分 Removal、EKU Removal、Disallow、Disable 与 NotBefore。把根从受信任证书列表移除，会让相关证书链默认不受信，但在某些存储区仍可能通过人工安装恢复信任。Disallow 更强：证书被加入禁止列表，不能靠人工安装简单恢复。Disable 和 NotBefore 又有各自的时间与用途语义。

这些状态还要经过更新渠道传播。联网的 Windows 客户端可以自动接收受信与禁止证书列表；隔离网络则可把同一材料重定向至内部文件或网站服务器。Microsoft 提供分别核验 AuthRoot、Disallowed 以及最近同步时间的方法。服务器上存在一份策略，并不能证明客户端已经接收并应用了它。

Apple 发布当前共享根信任库，同时保留旧版本清单。已安装的信任库版本因此可以成为运行证据；它也提醒运营者，旧设备的实际状态不能由网页上的最新清单代替。Mozilla 同样区分关闭信任用途与彻底移除证书，可以把两种动作安排在未来日期，并允许基于其代码的软件发行方维持不同根集合。

先定义动作，再衡量完成度

“移除这个根”不足以作为事件指令。目标可能是拒绝全部证书链、只拒绝截止日后签发的证书、移除某一种用途、只在特定根证书计划内撤信，或为内部服务保留例外。不同动作需要不同的预期测试结果。

迁移的分母不是已纳管设备数，而是验证器群组：浏览器及版本、操作系统信任库、应用运行时、运行时信任包、容器基础镜像、设备固件、嵌入式客户端与受管例外。每组都应保存根指纹、实际证书链，以及预期结果究竟是接受还是拒绝。安全撤信之后仍能连接的旧客户端属于失败，即使普通可用性监控仍显示绿色。

公开文件能够证明根证书计划的政策与分发机制，却不能揭示任何运营者的客户端清单、私有根、容器刷新周期、固件节奏或真实验证结果。本文的运营结论属于基于这些事实的推论：信任变更必须与实际保护业务流程的依赖方逐一核对。本文不指称任何客户、根运营者或平台造成了具体故障。

来源