3、OCSP机制详解：在线证书状态协议
CRL 有个硬伤——它是个“大名单”。你想想看，每次验证证书都得下载整个列表，少则几百 KB，多则几 MB。在移动端或者高并发场景下，这简直要命。
OCSP 就是来解决这个问题的。它不给你整份名单，而是让你直接问 CA：“这张证书现在有效吗？”CA 回答“有效”或“已吊销”，完事。
我个人习惯是，只要条件允许，优先用 OCSP。但这里面的坑也不少，咱们一个一个说。
3.1 什么是 OCSP
OCSP，全称 Online Certificate Status Protocol，定义在 RFC 6960。说白了，它是一个“请求-响应”式的轻量级协议。
客户端拿着证书，向 OCSP 响应器（Responder）发起查询。响应器返回这张证书当前的状态。整个过程不需要下载任何列表，一次 HTTP 请求就够了。
我记得第一次在项目中部署 OCSP 时，被一个细节坑过——OCSP 响应本身也是要签名的。如果响应器的证书不被客户端信任，那响应就是废纸一张。嗯，这个后面会细说。
3.2 OCSP 请求与响应流程
流程其实不复杂，我画了一张图帮你理清脉络：
流程就这么三步。但实际落地时，有几个细节你一定要注意：
- 请求内容：客户端需要提供证书的颁发者信息（Issuer Name Hash）和证书序列号。不需要传整张证书，省流量。
- 响应签名：OCSP 响应必须由 CA 或受信任的响应器签名。如果响应没签名或签名无效，客户端必须视为“未知”。
- 缓存控制：响应里的
nextUpdate字段告诉客户端“这个结果在什么时间之前有效”。我见过不少系统忽略这个字段，每次都重新查询，白白浪费性能。
3.3 OCSP Stapling 技术
OCSP 有个明显的短板——隐私问题。你每次查询 OCSP 响应器，CA 就知道你在访问哪个网站。说白了，CA 能拿到你的浏览记录。
另外，OCSP 查询本身也有延迟。如果响应器挂了，客户端可能超时，甚至拒绝连接。
OCSP Stapling 就是来解决这两个问题的。它让服务器自己“代劳”查询，然后把结果“钉”在 TLS 握手里发给客户端。
流程是这样的：
- Web 服务器定期（比如每小时）向 OCSP 响应器查询自己的证书状态。
- 服务器把 OCSP 响应缓存起来。
- 客户端发起 TLS 握手时，服务器直接把缓存的 OCSP 响应塞进 Certificate 消息里。
- 客户端验证这个响应，不需要再自己去查 OCSP。
我曾经在一个金融项目中遇到过这种情况：客户端数量巨大，OCSP 响应器被查得扛不住了。换成 Stapling 之后，响应器负载直接降了 90%。
核心区别：
- 普通 OCSP：客户端查 → 隐私泄露 + 延迟
- OCSP Stapling：服务器代查 → 隐私保护 + 性能提升
3.4 OCSP 的优缺点
没有完美的协议。OCSP 有它的长处，也有它的短板。我整理了一张表，方便你对比：
| 维度 | 优点 | 缺点 |
|---|---|---|
| 实时性 | 单张证书查询，响应快，秒级出结果 | 依赖网络，响应器宕机就查不了 |
| 流量 | 每次只传几十字节，比 CRL 省太多 | 高并发场景下，响应器压力大 |
| 隐私 | Stapling 模式下隐私保护很好 | 普通 OCSP 会暴露用户访问记录 |
| 部署 | 协议简单，客户端支持广泛 | 需要额外维护 OCSP 响应器基础设施 |
| 缓存 | 支持 nextUpdate 缓存，减少重复查询 | 缓存过期后若响应器不可用，会降级 |
thisUpdate 和 nextUpdate 一定要认真校验。如果客户端不检查时间戳，缓存可能成为安全漏洞。
说到底，OCSP 和 CRL 不是二选一的关系。我建议你根据场景来：
- 内网环境：OCSP Stapling 是首选，性能好，隐私无忧。
- 公网环境：OCSP + CRL 双保险。客户端先查 OCSP，查不到再回退到 CRL。
- 高安全场景：强制 OCSP，禁止软失败。宁可断网也不信任已吊销证书。
好了，OCSP 的核心内容就这些。记住一点：OCSP 不是银弹，但它和 CRL 配合使用，基本能覆盖 99% 的证书吊销验证场景。