OCSP

OCSP 装订让 TLS 服务端在握手过程中发送签名的证书状态响应。对于原本需要在线查询 OCSP 的客户端，它可能省去一次单独请求。收益取决于客户端的吊销策略：并非每个浏览器每次连接都查询 OCSP，也不是每个证书颁发机构仍然提供这种服务。装订只是传递状态证据的一种方式，不能代替完整证书验证，更不能把“握手收到了一段数据”当作信任已经成立。 传递证据并不转移信任责任 服务器从颁发机构或获得授权的应答方取回响应，并为适用握手缓存它。客户端仍须检查响应签名、签名者权限、证书标识、状态和可接受时间范围。服务器把响应附在握手里，不会让它自动可信。OCSP 的 good 状态也不能证明主机名匹配、证书仍在有效期内，或整条证书链已经连接到受信任根。这些验证职责必须分别保留。 线上表示还取决于 TLS 版本。TLS 1.2 使用状态请求扩展与 CertificateStatus 握手消息；TLS 1.3 则把响应放在对应 Certificate 条目的扩展中。把两者统称为 certificate_status 扩展，会混淆实际协议结构。普通网络攻击者不能随意剥离受认证握手消息，同时仍让 Finished 校验成功。讨论吊销检查被绕过时，应明确攻击能力和客户端策略，而不是虚构一种可以无痕删除握手数据的能力。 先核对支持范围，再决定启用 运维者首先需要确认颁发方提供可用响应，并检查服务端及客户端是否支持预期策略。Let’s Encrypt 已在二〇二五年八月六日结束 OCSP 服务，改用证书吊销列表。因此，对于没有 OCSP 支持的证书，缺少装订不自动意味着刷新任务损坏。应查当前颁发方文档，而不是把“所有站点都应该打开装订”当成不需要前提的清单步骤。 对于仍提供 OCSP 的颁发方，应在缓存过期之前留出刷新余量，并覆盖证书轮换。需要检查响应对应哪张证书、新鲜度及边缘实际交付内容，而不只是缓存是否存在。不同服务进程可能持有不同结果；控制面抓取成功也不证明全部已更新。缓存中的 good 响应仍可能在可接受窗口内，而较新的吊销信息已经出现，因此装订不能提供瞬时吊销知识。 坏掉的样子 缺失、过期、无效和已吊销是不同状态。客户端可能拒绝连接、查询其他机制，或应用明确的软失败策略。缺少响应不保证触发直连颁发机构，已经提供但无效的响应也不保证仅仅增加延迟。描述时应说明具体校验器的行为，不要承诺所有握手都会继续，更不能把“没有报错”直接解释为吊销状态已经得到确认。 ...