OCSP 响应格式：响应状态码、签名验证、扩展信息
接下来我们聊聊 OCSP 响应到底长什么样。很多人升级 SDK 后遇到问题，其实是没看懂响应内容。我个人习惯拿到一个异常响应后，先拆成三块来看：状态码、签名、扩展信息。这三块任何一个出问题，都可能被客户端判定为“无效响应”。
响应状态码——最直接的排查入口
OCSP 响应里第一件事就是告诉你“这证书现在能不能用”。它通过一个整数字段来表示，取值范围 0-3。你想想看，只有 4 种可能，其实排查起来并不复杂。
| 状态码 | 含义 | 典型场景 |
|---|---|---|
| 0（good） | 证书状态正常，未被吊销 | 绝大部分正常业务流 |
| 1（revoked） | 证书已被吊销 | 私钥泄露、证书错发等；客户端应拒绝连接 |
| 2（unknown） | 响应方不知道这个证书的状态 | CA 侧数据不同步、查询 ID 不匹配 |
| 3（malformedRequest / internalError / tryLater / sigRequired / unauthorized） | 无法生成有效响应，附带具体错误原因 | 请求格式错误、CA 服务过载、签名要求未满足 |
我在项目中遇到过几次，升级 SDK 后突然大量报 revoked。查了半天，发现是 SDK 把 OCSP 响应的状态码解析逻辑改了——原来把 undefined 当 good 处理，现在严格按照规范抛异常。说白了，不是证书真有问题，是解析策略变了。
签名验证——防篡改的最后一道防线
拿到响应后，别急着信它。OCSP 响应本身必须携带签名，否则谁都可以伪造一个 "good" 状态塞给你。
签名验证涉及三个要素：
- 签名算法：常见的有 RSA-SHA256、ECDSA-SHA256。SDK 升级后如果改动了支持的算法列表，可能把原本合法的签名判为无效。
- 签名者证书：响应由谁签的？它必须是受信任的 CA 或 CA 授权的响应方。我记得有一次排查，发现 SDK 更新后不再信任中间 CA 的 OCSP 响应签名证书，导致所有响应都被丢弃。
- 签名值：直接用公钥验签。嗯，这一步一般不会出问题，除非传输过程中被修改或响应被截断。
openssl ocsp -respin response.der -CAfile ca.pem -verify_other responder.pem。如果手动能通过，SDK 却不通过，那基本就是 SDK 的验证逻辑有差异。
扩展信息——藏在细节里的魔鬼
OCSP 响应里还有个可选部分叫扩展信息（Extensions）。升级 SDK 后很多异常就藏在这里。常见的扩展字段有：
- Nonce：防重放攻击用的。请求里带了个随机数，响应里必须原样返回。如果不一致，说明响应可能是伪造的或来自另一个会话。
- Next Update：预定的下次更新时间。客户端收到后可以缓存直到这个时间。但如果 SDK 升级后改了缓存策略（比如强制忽略 Next Update），就会造成频繁回源查询，甚至超时。
- Certificate Issuer：当响应中包含签发者信息时，可以用来确认响应确实针对正确的 CA。
- Accepted Revocation Update Time：告诉客户端“最新的吊销信息截止到哪个时间点”。如果客户端要求的时间戳比这个晚，它可能认为响应不完整。
我曾经排查过一个诡异问题：某次 SDK 升级后，iOS 端一切正常，但 Android 端疯狂报 OCSP 验证失败。对比抓包发现，Android 新版 SDK 居然要求响应里必须带 Nonce 扩展，而 CA 返回的响应默认不包含 Nonce。说白了，是 SDK 单方面加严了要求。
- 升级 SDK 前，先确认它对扩展字段的必需性是否有变化。是“必须包含”还是“可选包含”？这个差异极大。
- 建议在测试环境对比新旧 SDK 对同一 OCSP 响应解析出的扩展字段列表。
- 如果遇到 Next Update 被忽略的问题，可以在客户端添加缓存策略的日志，看新 SDK 是否按预期缓存。
整体看下来，OCSP 响应的三个部分就像三个把关人：状态码告诉你结论，签名保证结论没被篡改，扩展信息则提供上下文和缓存 hint。任何一个把关人工作不正常，你的证书状态查询就会出问题。
下面这张图总结了我排查 OCSP 响应时的流程，供你参考。
我个人觉得，排查 OCSP 响应问题时，最难的不是看懂某个字段，而是搞清楚 SDK 在哪个阶段做了哪些“意料之外”的检查。尤其是扩展信息部分，很多开发同学会忽略。我建议你在升级包里直接对比新旧 SDK 解析 OCSP 响应的源码片段，或者至少多看几份错误日志。