摘要

  • SCT 是日志将在最大合并延迟内纳入证书条目的签名承诺，不替代证书链验证，也不自动满足浏览器政策。
  • 上线依据应是目标客户端的外部验收证据，并同时保存客户端版本、有效日志清单和 CT 是否正在执行。

签发流水线显示绿色：新证书带有三个 SCT，签名都能验证，边缘节点也完成了部署。然而，一组浏览器仍然拒绝 TLS 连接。这不是技术事实互相矛盾，而是运营团队把“日志已收件”和“依赖方已接受”当成了同一个状态。

RFC 9162 对 SCT 的定义很窄，也很重要。日志接受提交后，会签名承诺在 Maximum Merge Delay 内把条目写入追加式 Merkle 树。之后，审计方可以验证纳入证明和树的一致性。RFC 同时明确：SCT 验证不能代替服务器证书及其证书链的正常验证。

Chrome 的判定还会检查 SCT 的交付方式、不同日志数量、不同运营方数量，以及日志在 SCT 生成时和证书校验时分别处于什么状态。对于有效期不超过 180 天、SCT 内嵌的证书，现行政策要求至少来自两个不同日志、两个不同运营方，并且校验时至少有一个日志仍处于可计入状态。通过 TLS 交付 SCT 时，适用的是另一组条件。

因此，“三个有效 SCT”只是原始计数。它可能没有显示三个 SCT 是否集中于一个运营方，是否来自已经不再计入的日志，或者交付路径是否满足对应规则。

客户端看到的日志清单也是控制面

Chrome 每天发布新的 CT 日志清单。清单记录日志、运营方和生命周期状态。客户端验证证书时使用的并非一个永远不变的名单，而是当时持有的政策状态。

这里还有一个容易误读的 70 天时钟。如果 Chrome 客户端长期拿不到足够新的、能够识别的日志清单，CT 执行会被关闭。旧客户端探测成功，可能代表它没有执行 CT，而不是证书更符合要求。每次探测都应留下客户端版本、日志清单时间戳和 CT 执行状态。

Chrome 也明确提醒：其日志清单服务于 Chrome 生态的提交、监测和审计，不应被其他用户代理直接拿来充当通用执行权威。Apple 的政策进一步说明了差异。Apple 区分“当前获批”和“曾经获批”的日志，对 SCT 组合和同一运营方可计入数量有自己的要求。技术机制相同，不代表所有浏览器共享一个结论公式。

时间分片让日志资格带上有效期

Chrome 要求新的 CT 日志采用时间分片。每个分片只接受 notAfter 落在指定区间的证书，日志运营方需要提供连续覆盖。签发方选择日志时，必须同时考虑证书到期日、日志运营方和生命周期状态。

Chrome 面向网站运营者的说明还指出，现有证书中的 CT 信息可能在证书到期之前失去有效性。届时可能需要通过 TLS 提供新的 SCT，或者直接更换证书。只监控证书到期日，看不到这个更早的接受风险。

证据边界必须清楚。已核实的事实，是 RFC、Chrome 和 Apple 公布的协议与政策。本文提出“把签发回执与真实客户端对账”，属于运营推论。公开资料无法证明某家机构的浏览器构成、终止点清单、例外规则、仿真器准确度或事故记录，也没有证明任何证书机构、日志或浏览器当前发生故障。这些都是需要本地证据回答的未知项。

一个可用的依赖方验收台账，应连接证书指纹、域名和终止点、SCT 交付方式、日志 ID 与时间戳、Chrome 和 Apple 的有效政策/清单证据、已测试的客户端版本、外部握手结果、例外、负责人和可用更换时间。日志回执属于签发链；用户能否按预期连接，仍属于服务负责人的证明责任。

来源