摘要

  • OCSP stapling 允许服务器在 TLS 握手中附带一份签名证书状态响应。网站负责递送，客户端仍须核对签名、作证权限、证书对应关系与时效。
  • 可复用的证明减少了客户端临时查询第三方的需要，也留下了更新与分发责任。证书中声明必须支持相应功能，可以改变证明缺席时的判断，却同时让证书上线依赖于状态证明是否就绪。

递送材料不等于签署材料

假设客户端正在判断是否接受一个网站的证书。服务器除了交出证书，还送来一份响应，表示相关证书状态为 good。如果这句话只是网站自己说的，检查便成了自我担保。

OCSP stapling 并非如此。附带的响应有自己的数字签名，签署者必须有权对该证书的状态作答。服务器拿着普通 TLS 私钥，并不因此获得签署 OCSP 状态的权限。它可以转交一份可验证的声明，却不能把“已经撤销”改成“没有撤销”，再要求客户端当作同一份有效证明接受。

这里真正被拆开的是三件事：谁作证，谁送达，谁决定证据是否足够。把它们分开以后，证据便能经过一个有利害关系的中间方，而不必把中间方当成证据的权威来源。

先省掉一次往返，再追问工作去了哪里

2003 年 6 月的 RFC 3546 已经规定，客户端可用 status_request 请求证书状态，服务器则可在证书消息之后附送 OCSP 响应。规范给出的背景包括受限网络、证书撤销列表的传输成本以及额外往返。

这不是 2011 年才出现的发明。RFC 6066 在后来的 TLS 框架中继续描述它：状态响应装进独立的 CertificateStatus 消息，随握手送来。客户端若已拿到足以满足检查的响应，就不必为了这次检查再单独访问状态服务。

少一次访问，既可能减少等待，也避免了这次第三方查询带来的额外信息暴露。但这只解释了被省掉的那条连接。它不意味着整个浏览过程匿名，更不意味着签署状态的服务从此不必存在。网站手里的证明仍然需要取得、更新并正确分发。

good 不是一张全面合格证

2013 年的 RFC 6960 把 OCSP 响应的范围说得很窄。good 是对状态查询的肯定回答，不必然证明证书曾经签发，也不必然说明响应签署时位于证书有效期内。它更不能证明网站内容安全或运营者没有被入侵。

客户端仍须检查这是不是针对所查证书的响应，签名是否有效，签署者是否有权作答，以及状态是否足够新。可接受的签署者包括证书签发 CA、客户端明确信任的响应者，或得到相应授权的响应者。“正在向我提供网页的服务器”本身不是这种授权。

因此，附带状态并没有取代证书链和其他身份验收条件。它只是把其中一类证据放到了更方便取得的位置。便利来自传递路径变化，而不是证据范围扩大。

可复用的证明，必然带着时间差

如果每位访问者都必须得到一份刚刚为自己生成的回答，复用空间便很有限。2007 年 9 月的轻量级 OCSP 规范 RFC 5019 将预先生成、分发和缓存纳入可扩展的设计。代价是客户端必须认真判断响应的年龄。

三个时刻不能混读。thisUpdate 表示响应者知道该状态正确的时刻；producedAt 是签署时刻；nextUpdate 说明较新信息将在何时或之前可用。晚一点签名，不等于晚一点重新观察了状态。

轻量级规范要求存在 nextUpdate，并用准确时钟检查新鲜度；基础 OCSP 则允许该字段缺席。不能把前者的要求说成所有 OCSP 响应都无条件遵循的规则。未签名的 HTTP 缓存信息也不能替签名响应延长可接受时间。

这解释了缓存为何既有用又有限。状态服务暂时不可达时，服务器可能仍可提供一份客户端接受的已有响应；但这种余量会消耗。较新的撤销状态已经出现，也不会让先前发出的每份 good 响应自动变样。签名能固定一段陈述的出处和内容，不能让过去的陈述持续追上现在。

没送来，究竟说明什么

早期机制有意保留了兼容性：客户端可以请求，服务器仍可以不提供状态。因此，没有附带响应既可能是没有实现该功能，也可能是持有泄露私钥的一方不愿送出不利材料。

RFC 6066 的安全讨论 没有把这个缺口藏起来。需要 OCSP 验证的客户端应另行访问响应服务，或者放弃握手。收到响应却检查不通过，则是另一种情况，规范要求终止握手。缺席、过期、unknown 与 revoked 不能被合并成同一个状态。

2015 年 10 月的 RFC 7633 给出了改变预期的办法：在证书的 TLS Feature 扩展中声明 status_request。这构成了通常称为 Must-Staple 的机制基础。支持该机制的客户端可以根据证书中的声明判断服务器是否履行承诺，而不只是听服务器解释“我不支持”。

这种承诺也不是所有客户端一致执行的全球开关。规范没有要求每个客户端实现所有功能，还保留了其他途径完成验证等例外。真正新增的是可核对的约束及其运营后果：如果新证书已部署，所需状态响应却尚未可用，一个合法网站也可能无法满足客户端的预期。规范因此要求认真安排证书和状态材料的先后顺序。

传递容器变了，作证关系没有变

2018 年的 RFC 8446 改变了 TLS 1.3 中的装载位置。状态信息放在相应 CertificateEntry 的扩展中，不再使用旧版本那个独立的握手消息。改变位置并没有赋予服务器签署权，也没有免除客户端的时效检查。

OCSP stapling 留下的历史经验不是“多带一份材料就更安全”。它说明，独立可验证的证据能够被有利害关系的一方递送；但省去现场询问的同时，必须有人维护这份证据的年龄、配对与可得性。这里的 RFC 记录能证明制度如何设计，不能证明今天每种客户端和每家 CA 都以同样方式运行。

来源

协议依据为 RFC 3546、RFC 6066、RFC 6960、RFC 5019、RFC 7633 与 RFC 8446。文中对责任和成本迁移的判断是基于规范要求的分析，并非现网部署统计。