SCT （签名证书时间戳）

SCT（Signed Certificate Timestamp，签名证书时间戳）是 CA 向 CT 日志提交证书或预证书后，日志返回的一小段数据，包含日志 ID、时间戳和日志的签名，承诺在最大合并延迟内把这条记录并入日志。客户端用自身 CT 策略列表里的日志公钥验证签名。SCT 有三种送达方式：嵌入证书（最常见）、在 TLS 握手时通过 TLS 扩展下发，或者放在 Stapling 的 OCSP 响应里。

为什么重要

Chrome 和 Apple 会拒绝缺少足够有效 SCT 的公开信任证书：Chrome 要求 2018-04-30 之后签发的证书记入 CT，Apple 要求 2018-10-15 之后签发的证书记入。它们的策略要求 SCT 来自多个不同的日志运营方，具体数量取决于证书有效期。SCT 时间戳还被用于取消信任的判定：Chrome 131 及以后版本不再信任最早 SCT 晚于 2024-11-11 的 Entrust TLS 证书。时间是日志而不是 CA 签的，CA 无法倒签日期。

例子

openssl x509 -in cert.pem -noout -text | grep -A12 "CT Precertificate SCTs"

每一条都会列出 Version、Log ID、Timestamp 和 Signature。公共 CA 签发的证书一般带有两到三条来自不同日志的 SCT。用国内云平台购买的证书也一样，SCT 由背后的 CA 负责嵌入。

常见误区

• SCT 证明证书已经在日志里了。 它只是带签名的承诺，之后要靠日志的包含证明来确认。
• 网站运维需要自己配置 SCT。 嵌入式 SCT 全由 CA 处理，只有通过 TLS 扩展下发的方式才需要服务器支持。
• 有 SCT 就说明证书合法。 日志并不检查签发是否合规，只负责记录。