1. OCSP 基础：协议原理、工作流程、与 CRL 对比
说起 OCSP，很多刚接触证书验证的同学会觉得它挺神秘。其实说白了，它就是用来回答「这张证书现在还有效吗？」这个问题的一套在线查询协议。我最早在项目中遇到它，是因为一次 SDK 升级后，后台证书验证突然全崩了…… 自那以后，我花了不少时间把 OCSP 从头捋了一遍。
一句话总结：OCSP（Online Certificate Status Protocol）让你不用下载庞大的证书吊销列表（CRL），就能实时查询某张证书是否已被吊销。
1.1 协议原理 – 它到底在查什么？
OCSP 的核心是请求 / 响应模型。客户端拿着要验证的证书信息，向 OCSP 响应器（Responder）发出查询。响应器查阅自己的数据源（通常是 CA 的吊销记录），然后返回一个签名结果。
- 请求里有什么？ – 目标证书的颁发者信息（Issuer Name Hash）、序列号（Serial Number），以及可选的扩展字段。
- 响应里有什么？ – 状态码：
good（有效）、revoked（已吊销）、unknown（查不到）。如果已吊销，还会附带吊销时间和原因。 - 安全性怎么保证？ – 响应数据必须由 CA 或受信任的响应器签名，防止中间人篡改结果。嗯，这一点特别重要，我见过有人直接信任 HTTP 明文 OCSP，结果被攻击者伪造了“good”响应。
我的习惯：在做证书验证逻辑时，我一定会在代码里校验 OCSP 响应的签名，并且设置合理的超时时间（一般 3~5 秒）。超时太长，用户等不起；太短又容易误判为 revoked。
1.2 工作流程 – 一步一步来
我习惯把 OCSP 的交互拆成四个动作，你想想看，其实特别像打电话查某个人的信誉记录：
- 客户端发起查询 – 应用程序（比如浏览器、TLS 库）在验证服务器证书时，发现证书中带了
Authority Information Access扩展，里面标明了 OCSP 响应器的 URL。 - 构造请求 – 客户端用 ASN.1 DER 编码生成 OCSP 请求，包含目标证书的唯一标识。
- 发送并等待响应 – 通过 HTTP POST 或 GET 将请求发给 OCSP 响应器。响应器收到后，从本地数据库或向上级 CA 查询。
- 验证并应用结果 – 客户端拿到响应后，先验证签名，再按状态决定是否继续 TLS 握手。
| 角色 | 关键数据 | 说明 |
|---|---|---|
| 请求方 | IssuerNameHash, IssuerKeyHash, SerialNumber | 用于定位具体证书 |
| 响应方 | CertStatus (good/revoked/unknown), thisUpdate, nextUpdate, signature | 状态 + 时间戳 + 签名 |
| 扩展选项 | Nonce, AcceptableResponses … | 防重放，指定响应格式 |
我曾经在调试一个 SDK 时，发现 OCSP 请求总超时。后来抓包一看，响应器的 URL 写的是 http:// 而非 https://，但我们的库强制要求 HTTPS——结果请求全部被拦截。这种配置不一致的坑，值得注意。
1.3 与 CRL 对比 – 为什么有了 CRL 还需要 OCSP？
CRL（证书吊销列表）是 CA 定期发布的一份“黑名单”文件，里面列出了所有被吊销的证书序列号。OCSP 则是一条一条实时查。两者各有优劣，我整理了一个对比表格：
| 对比维度 | CRL | OCSP |
|---|---|---|
| 数据获取方式 | 客户端定期下载整份列表 | 每次查询只取单张证书状态 |
| 实时性 | 滞后：更新周期可能数小时甚至数天 | 近乎实时（取决于响应器数据源延迟） |
| 网络开销 | 大：列表可能几 MB 甚至几十 MB | 小：每次请求响应不过几百字节 |
| 隐私性 | 好：客户端不需要暴露自己查了哪张证书 | 差：OCSP 响应器能知道谁在查哪张证书 |
| 可靠性 | 高：离线可用（事先下载好） | 依赖响应器在线可用 |
| 复杂度 | 实现简单，解析 CRL 即可 | 需要处理签名验证、超时、重试 |
你可能会问：“既然 CRL 免费、离线可用，为什么还用 OCSP？” 我自己的项目中碰到过一个真实案例：某大型企业有上千台终端，每次访问都需要验证证书。如果每台每半小时去拉一次 CRL，带宽和 CPU 都会被拖垮。换成 OCSP 后，流量下降了 80%，而且吊销即时生效。
当然，OCSP 也有它的短板——隐私问题。好在后来有了 OCSP Stapling，把查询权交给服务器，客户端不用直接联系响应器（这个话题我们后面章节会详细讲）。
重要提醒：千万不要在 OCSP 失效时直接放行证书！我曾经在一个项目中看到这样的代码：如果 OCSP 超时或出错，就默认证书有效。结果黑客冒用了一个被吊销的证书，直接拿到内部系统权限。正确做法是：OCSP 不可用时，应回退到 CRL 检查，或者硬性失败。
1.4 知识框架图：OCSP 工作流程与对比脉络
下面这张图帮你把 OCSP 的请求 / 响应路径，以及它和 CRL 的关键区别可视化出来。你可以从左到右看，先理解交互步骤，再对比两种方案的位置。
1.5 我的避坑建议
- 超时处理别偷懒 – 我曾经只设了 2 秒超时，结果在弱网环境下一堆合法证书被误判为 revoked。后来改成：首超时 3 秒，重试一次共 6 秒，如果还失败则 fallback 到 CRL。
- 小心 OCSP 响应缓存 – 响应里的
nextUpdate字段告诉你可以缓存多久。千万别无视这个字段一直重复查，会加重响应器压力。我一般会尊重它，同时设一个最大缓存上限（比如 4 小时）。 - 非对称超时策略 – 对于 high-stakes 交易（比如支付），我建议使用更严格的 OCSP 检查，甚至不允许 fallback；而对于普通页面访问，可以宽松一些。
好了，这一章我们先把 OCSP 的底子打牢了。理解了它的请求/响应模型和与 CRL 的取舍，后面聊 OCSP Stapling、Must-Staple 以及 SDK 升级后的异常现象时，你就能快速定位问题根因了。