OCSP 装订与证书透明度

证书吊销列表（CRL）是由 CA 发布的文件，其中列出所有已吊销的证书。CRL 存在多项问题：会随着时间推移而变大，客户端必须完整下载，时效性有限（按计划发布），并且浏览器过去在获取 CRL 失败时通常会软失败（仍接受证书），因此在实际使用中吊销机制并不可靠。

在线证书状态协议（OCSP，RFC 6960）允许客户端实时查询 CA 的 OCSP 响应器，以获取特定证书的吊销状态。OCSP 响应会指出证书处于“good”、“revoked”或“unknown”状态，并由 CA 签名。这比下载完整 CRL 更高效。

标准 OCSP 存在一个严重的隐私缺陷：客户端必须向 CA 的 OCSP 响应器发送正在检查的证书序列号，这会向 CA（或网络观察者）暴露用户正在访问哪些网站以及访问时间。这样一来，在证书颁发机构层面就形成了侵犯用户隐私的监控机制。

OCSP 装订（RFC 6066）通过让服务器预先从 CA 获取 OCSP 响应并将其缓存来解决隐私问题。在 TLS 握手期间，服务器会将此缓存响应“装订”到握手中，直接交付给客户端。客户端无需直接联系 CA 即可获得最新的吊销状态。

Nginx 的 OCSP 装订配置要求在服务器区块中设置：“ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8;”。ssl_certificate_by_lua_block 或 ssl_trusted_certificate 指令会提供用于验证的证书链。Apache 要求在 VirtualHost 中设置“SSLUseStapling on”。两种服务器都会缓存响应，并在响应过期前刷新。

OCSP Must-Staple X.509 扩展（RFC 7633）会告知浏览器，该证书对应的服务器始终会装订 OCSP 响应。如果浏览器连接服务器时没有收到装订的响应，就会拒绝连接。这可以防止持有已吊销证书的攻击者阻断 OCSP 响应，从而迫使浏览器执行软失败。

证书透明度（CT）是一种系统，要求所有公开信任的 CA 在交付证书前，将其签发的每张证书记录到公开可审计、只能追加的日志中。这些日志使域名所有者、研究人员和监控方能够发现针对任何域名误签发或欺诈获得的证书。

当 CA 向 CT 日志提交证书时，日志会返回签名证书时间戳（SCT）。SCT 是一份经过密码学签名的承诺，表示该证书已被记录。SCT 可以嵌入证书本身、通过 TLS 扩展交付，或装订在 OCSP 响应中。Chrome 要求至少有两个 SCT 才能信任证书。

自 2018 年 4 月起，Google Chrome 要求所有公开信任的 TLS 证书都必须具备证书透明度。没有有效 SCT 的证书会被 Chrome 拒绝，并显示证书错误。由于任何证书被 Chrome 拒绝的 CA 都无法作为公共 CA 运行，这项要求实际上促使所有主要 CA 都记录 CT 日志。

CT 日志使任何人都能监控针对其域名签发的证书。crt.sh 和 Facebook 的 CT Monitor 等服务允许域名所有者搜索所有 CT 日志，查找主题或 SAN 字段中包含其域名的证书。未经授权的证书签发（例如由被入侵的 CA 签发，或通过 BGP 劫持完成）可以在数小时内被发现。

CT 日志由多个独立组织运营，包括 Google（Argon、Xenon）、Cloudflare（Nimbus）、DigiCert、Sectigo 等。多个日志运营方可以防止任何单一实体压制已记录的证书。浏览器要求 SCT 来自其批准列表中的日志，从而对受信任的日志进行质量控制。

CRL 体积庞大且容易过时；OCSP 提供实时吊销状态，但会将浏览数据泄露给 CA。OCSP 装订在 TLS 握手期间交付预先获取的吊销状态，从而保护隐私。OCSP Must-Staple 可防止绕过软失败。证书透明度会记录所有签发的证书，并通过 SCT 实现对误签发证书的检测。Chrome 自 2018 年起要求使用 CT。