摘要

  • DigiCert 收购 Symantec 证书业务，为客户、合同和签发系统提供了迁移路径，但 Google、Mozilla 与 Apple 仍分别决定自家客户端接受哪些旧链，并采用了不同的版本节奏、日期界线与例外。
  • 企业不能把公有 PKI 信任当成供应商自有资产。证书签名正确、尚未到期、并购已经交割，都不保证下一个客户端仍会接受它；连续性取决于依赖方继续运行接受规则，或站点在规则改变前完成替换。

交易交割日不是信任交割日

2017 年，Symantec 可以出售网站安全与 PKI 业务。人员、合同、客户关系和运营系统都可以通过商业安排转移，新所有者也可以建设一套独立运行的签发基础设施。然而，公有根证书的实际效力来自第三方软件把它列为信任锚。卖方无权把这些第三方的下一次判断写进资产交割清单。

Mozilla 对此给出了极清晰的表述：根计划的信任不会因组织之间的交易自动转移。DigiCert 收购业务，并不会取消既定的旧根退出方案。否则，受到根计划处置的 CA 可以通过重组、出售或换名，在基本相同的运营条件下逃避后果。

Google 的公开记录解释了这项边界为何产生。2017 年 1 月的一次公开披露引出了对可疑网站认证证书的调查。Google 表示，部分组织在缺乏充分监督的情况下获得了签发能力，相关问题又属于多年反复出现的模式。Chrome 团队因此不再信任旧基础设施。

这不等于宣告每一张 Symantec 证书都是欺诈或失陷。它是对一整套层级能否继续享有普遍推定的判断。因此，处置方式不是撤销某一张叶证书，而是把新签发路径与旧系统分开，给站点留出迁移时间，并逐步改变客户端所接受的链。

同一张证书上的四只时钟

第一只时钟是签发日期。Chrome 的方案以 2016 年 6 月 1 日划分 Chrome 66 将首先拒绝的旧证书；又以 2017 年 12 月 1 日划定 DigiCert 独立托管签发设施的切换点，旧设施在此后签发的证书不会被 Chrome 接受。到 Chrome 70，旧 PKI 将被更广泛地取消信任，只保留极少数已披露例外。

第二只时钟是软件发布。政策公告不会在当天同时改变全球设备。行为先进入 Canary，再进入 Beta，最后进入 Stable。Google 2018 年 3 月的通知分别列出 Chrome 66 与 Chrome 70 的节点，还允许企业暂时通过策略关闭旧 PKI 的不信任行为，但这条退路在 2019 年 1 月 1 日结束。它只是局部争取时间，并没有恢复公共信任。

Mozilla 运行自己的节奏。Firefox 58 先在控制台提示，Firefox 60 对 2016 年 6 月 1 日以前签发的相关证书显示不受信连接错误，后续版本再取消对旧根的信任，并为少数特定下级 CA 保留例外。由于仍有大量站点未迁移，Mozilla 又把最后一阶段从 Firefox 63 延到 Firefox 64。这里没有零成本选择：立即执行会造成广泛中断，推迟执行则延长了对被质疑层级的暴露。

第三只时钟属于站点。证书即使距离 notAfter 还有数月，也可能在更早的浏览器版本中失效。Mozilla 曾估算，2018 年 3 月初，访问量前一百万的网站中约有 1% 会受 Firefox 60 阶段影响；该版本发布前，比例已经低于 0.15%。对于下一阶段，另一时点的测量仍为 3.5%。这些数字是条件不同的遥测快照，不是全球网页普查，却清楚展示了一项信任决定如何变成大规模盘点、替换与测试工作。

第四只时钟是已安装客户端。Apple 从 2018 年 8 月 1 日开始部分取消信任；对于位于限定签发窗口且已写入受信 CT 日志的证书，仍暂时接受。Apple 把所列 Symantec CA 的全面取消信任日期记为 2020 年 2 月 25 日。Chrome、Firefox 与 Apple 平台从未共享一个全球同步开关。

所以同一服务器、同一张证书，可以被一位用户接受，又被另一位用户拒绝。变化的不是证书字节，而是依赖方本地运行的规则与版本。

日志证明发生过，不证明做得对

RFC 6962 把 Certificate Transparency 设计为只追加的公开日志，以签名时间戳和一致性证明约束日志行为。域名持有人可以发现陌生证书；审计者可以检查日志是否向不同观察者展示矛盾历史；签发者也更难否认自己做过的断言。

RFC 同时明确指出，签名时间戳不能保证证书没有被错误签发。CT 证明一项签发被公开记录，不证明申请者有合法权利、不证明验证程序足够，也不要求浏览器继续信任签发者。

Apple 的过渡规则正体现了这一界线。在一个有限签发窗口内，进入受信日志是继续接受的条件之一，但它没有永久洗白旧根。企业看到意外 CT 记录时，得到的是调查起点：谁申请、如何验证、是否已上线、哪些客户端可用、是否需要撤销。记录存在并不是结论。

有效权力落在运行客户端的一侧

根证书看起来像中央权威，实际效力却取决于大量客户端运行接受规则。Google 能改变 Chrome，Mozilla 能改变 Firefox，Apple 能改变自己的平台，企业能在受管设备中暂时保留例外，站点也能部署另一条链。各方在自己的边界内都有决定性权力，但谁也不能抹去其他方的选择。

Heng Lu 关于“运行代码优先”的论述在这里是公开说明的分析框架，而不是事件事实来源。制度主张只有被参与者运行的系统接受，才产生现实效果；技术依赖也不应因为规模巨大就无限扩张成主权。Symantec 的交易并未改写客户端信任库。新运营者仍须提供一条由依赖方选择接受的链。

这不意味着浏览器权力无需约束。少数客户端供应商的决定能给全球站点施加替换成本。因此，合理的根计划需要公开要求、可审查证据、分阶段实施、有限例外与一致性说明。能在代码里执行一项决定，只证明它有效，不证明它公平。

从到期清单升级为依赖清单

只按到期日排列的证书清单无法预警此类中断。真正有用的连续性档案至少要记录完整服务链、可能构建到的根族、重要客户群使用的根计划与操作系统、发布通道、签发日期阈值、CT 条件、下级 CA 例外，以及替换链在真实客户端上的验证证据。

档案还要区分密钥失陷、错误签发、审计失败、叶证书撤销、根取消信任和浏览器版本部署。这些事件会相互影响，却由不同主体控制，也通过不同机制影响可用性。

CA 并购的尽调同样必须拆分：客户合同、当前签发能力、旧根、新根、下级关系、审计义务、CT 参与以及存量证书替换成本。依附于即将失去信任的旧链的收入，不能和已经迁移到新设施的收入等价估值。

证据边界

官方资料能够证明处置时间线、阶段和信任不自动转移的立场，但不能证明所有旧证书都有问题。Mozilla 百分比只是特定时间与样本的测量。Apple 的日期不能套用到 Chrome 或 Firefox。根计划对其客户端具有真实控制力，却不因此成为整个 Web 的普遍主权者。

来源