# SCT（签名证书时间戳）是什么？定义、例子与常见误区

> SCT 是 CT 日志签发的承诺凭证，表示它会把某张证书收录进公开日志，浏览器以此确认证书已提交记录。

Source: https://ssl.sh/zh/glossary/sct/
Last updated: 2026-11-10

SCT（Signed Certificate Timestamp，签名证书时间戳）是 CA 向 [CT 日志](https://ssl.sh/zh/glossary/ct-log/)提交证书或[预证书](https://ssl.sh/zh/glossary/precertificate/)后，日志返回的一小段数据，包含日志 ID、时间戳和日志的签名，承诺在最大合并延迟内把这条记录并入日志。客户端用自身 CT 策略列表里的日志公钥验证签名。SCT 有三种送达方式：嵌入证书（最常见）、在 [TLS 握手](https://ssl.sh/zh/glossary/tls-handshake/)时通过 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 无法倒签日期。

## 例子
```bash
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 就说明证书合法。** 日志并不检查签发是否合规，只负责记录。

## 相关术语

- [证书透明度](https://ssl.sh/zh/glossary/certificate-transparency/): 证书透明度（CT）是一套公开、只可追加的日志系统，记录所有公开信任的 TLS 证书，让任何人都能审计 CA 签发了什么。
- [CT 日志](https://ssl.sh/zh/glossary/ct-log/): CT 日志是由独立运营方维护、可公开审计且只可追加的服务器，用 Merkle 树记录证书，并签发承诺收录的时间戳。
- [预证书](https://ssl.sh/zh/glossary/precertificate/): 预证书是 CA 在正式签发前提交到 CT 日志的证书副本，带有“毒化”扩展而无法使用，用来换取 SCT。
- [TLS 握手](https://ssl.sh/zh/glossary/tls-handshake/): TLS 握手是 TLS 连接开始时的一组消息交换，客户端与服务器在其中协商协议版本和密码套件、验证服务器身份并派生会话密钥。
- [OCSP Stapling](https://ssl.sh/zh/glossary/ocsp-stapling/): OCSP Stapling 是 TLS 服务器把 CA 签名、带有效期的 OCSP 响应随握手一起发给客户端的机制，浏览器因此不必再自己去问 CA。
- [取消信任](https://ssl.sh/zh/glossary/distrust/): 取消信任是根证书计划作出的决定：不再信任某家 CA 的证书，可能是全部证书，也可能只针对截止日期之后签发的证书。
