摘要

  • OCSP 装订把经过签名的证书状态证据放进 TLS 握手，减少客户端另行访问响应方带来的隐私、延迟和可用性成本。
  • good 状态的含义受到明确限制，thisUpdate、nextUpdate 与 producedAt 则共同描述一项有时间边界的声明。
  • 签名有效且时间上仍可接受，并不能说明每个边缘节点何时取得该响应，也不能证明更晚的吊销信息已在所有边缘完成替换。
  • 运营方需要一份吊销新鲜度收据，把证书、响应方和状态时间连接到获取事件、边缘部署批次及客户端作出判断的时点。

设想一个不对应任何已报道事件或具体供应商的情形。证书颁发机构生成一份状态为 good 的签名 OCSP 响应，一个边缘节点将其取回并缓存。此后证书被吊销，第二个边缘拿到了更新响应，第一个边缘却仍在其原有时间窗口内继续提供旧响应。客户端可以完全按照本地策略验证这份旧装订响应，但它得到的证据仍少于运营方所说的“吊销已经在所有地方生效”。

边界首先写在协议本身。RFC 6960 把 OCSP 定义为一种无需获取完整证书吊销列表即可判断证书状态的协议。明确状态响应带有数字签名，标识响应方，并包含针对特定证书的状态。这比未认证的可用性信号强得多，但它仍然只是关于特定对象、签发语境与时间范围的声明。

good 尤其容易被过度解读。它至少表示：在请求所指的序列号与证书有效期条件下，当前没有相应证书被记录为已吊销。RFC 随即限制了这一结论——good 并不一定证明证书曾经真正签发，也不一定证明响应生成时刻处于证书有效期内。扩展可以承载更多信息，但基础状态本身不会同时证明证书、服务器、账户与服务当前控制权全部成立。

三个时间字段让这条边界变得可观察。thisUpdate 是响应方最后确认所述状态正确的时点；nextUpdate 是更新信息最迟应当可用的时点；producedAt 是响应方签署该响应的时点。三者不能互换。刚签署的响应可以描述更早时刻已知的状态，而尚未到期的 nextUpdate 也不能证明后来发生的运营事件已经传播到每一个缓存和边缘节点。

依赖方在接受签名响应前必须完成一组检查：响应需要对应所查询的证书，签名必须有效，签名者必须是当前获授权的响应方，thisUpdate 必须足够新，而在存在 nextUpdate 时，它必须晚于当前时刻。这些检查能够证明状态对象真实并符合客户端的新鲜度策略，却不会自动生成该对象抵达当前服务器之前所经过的部署记录。

RFC 6066 描述了 TLS status_request 扩展。服务器可以借此把 OCSP 响应与证书一同发送，客户端不再需要在握手期间直接联系响应方。客户端收到该响应后必须检查；若不满意，就要终止握手。因此，装订改善的是状态证据的交付方式，而不是扩大证据原本能够证明的范围。

在分布式服务里，这一区别直接变成运营问题。同一证书可能部署在多个入口、终止集群或交付区域。不同节点可能通过不同路径获取、缓存和轮换状态对象。OCSP 响应记录的是响应方的知识与时间，不会列出完整边缘批次、配置版本、最近一次拉取结果或替换确认。“装订响应通过验证”与“最新吊销状态已经在所有节点执行”回答的是两个问题。

RFC 7633 提供了另一层约束。证书可以声明必须支持某项 TLS 功能，包括 status_request。兼容客户端因此可以拒绝没有提供预期状态证据的服务器配置。这解决了一项重要歧义：没有这类声明时，装订响应缺失本身无法证明合法服务器是不支持它，还是有意没有提供它。不过，在规范界定的情形下，验证仍可借助其他来源完成。Must-Staple 约束的是证据必须出现，不能让旧响应自动变新，也不能阻止所有误签发，更不能证明证书背后的应用仍由正确主体控制。

常见运营错误，是把四种状态压缩成同一个绿色指示灯。证书链可以通过验证，OCSP 签名可以通过验证，响应也可以符合客户端时间策略；即便如此，某个边缘节点仍可能落后于已可用的最新状态，或者根本不在运营方以为已经更新的部署批次中。只记录“已装订”的仪表盘无法分辨这些情况。

有用的吊销新鲜度收据应当保留整条证据链。它需要标明证书序列号与完整证书链、响应方身份、返回状态、thisUpdate、nextUpdate、producedAt、响应获取时刻、安装它的边缘或部署批次、验证策略以及依赖方作出决定的时刻。它还应记录替换失败，并把传输认证与应用当前授权明确分开。

这并不意味着 OCSP 装订很弱。相反，只有边界清楚，它才真正可用。装订可以减少客户端隐私泄露、握手延迟和对实时第三方查询的依赖；Must-Staple 可以让缺少证据变成可执行的失败条件；签名与时间检查可以认证一项有界的证书状态声明。问题只在于把这些优点升级成证据从未包含的全面保证。

因此，决定不是抽象地“信任还是不信任 OCSP”，而是明确装订响应允许满足哪一种运营主张。对握手验证而言，真实且足够新的响应可以具有决定性。若要保证吊销已经抵达所有活跃边缘，运营方还需要部署层证据。若要授权应用行为，服务仍需独立作出当前身份与策略决定，而不能借用证书状态对象的权威。

来源

RFC 6960 — 在线证书状态协议；RFC 6066 — TLS 扩展定义；RFC 7633 — TLS Feature 扩展。