OCSP 概述与工作原理

聊 OCSP 之前，咱们先搞清楚它在 PKI 体系里到底扮演什么角色。说实话，我刚入行时也觉得证书吊销这事儿离自己很远，直到有一次线上服务突然报错——用户证书被吊销了，但系统还在傻傻地信任它。嗯，那场面挺尴尬的。

OCSP，全称是 Online Certificate Status Protocol，在线证书状态协议。它解决了什么问题？

你想想看，CA 签发证书后，有时候会因为私钥泄露、域名变更、员工离职等原因，需要提前吊销这张证书。这时候，客户端怎么知道这张证书还“活着”？传统方案是用 CRL（证书吊销列表），但 CRL 有个硬伤——列表越来越大，下载耗时越来越长。

OCSP 的思路很简单：不下载整个黑名单，只问一句“这张证书现在有效吗？” 服务器返回“有效”、“已吊销”或“未知”。说白了，就是个轻量级的实时查询接口。

OCSP 在 PKI 环节中的位置

一张 PKI 信任链通常长这样：

1. 根 CA — 自签名，最顶层信任锚
2. 中间 CA — 由根 CA 签发，负责签发终端证书
3. 终端证书 — 给最终用户或服务器用的证书
4. OCSP 响应器 — 由 CA 或第三方部署，提供证书状态查询

这里有个很容易被忽略的点：OCSP 响应器本身也需要一张证书来签名它的响应。如果你配置不对，客户端验证 OCSP 响应时会陷入死循环——查证书状态前先要验证响应器的证书是否有效，那响应器的证书又该问谁？

请求与响应流程

OCSP 的核心流程其实就四步，我画了张图帮你快速建立整体感：

验证流程拆解

客户端收到 OCSP 响应后，不会直接信任——它要做几件事：

1. 验证响应签名 — 用 OCSP 响应器证书的公钥验签，保证响应没被篡改
2. 检查响应器证书 — 确认响应器证书是否在有效期内、是否被吊销
3. 核对 nonce — 如果请求里带了 nonce，响应必须原样返回，防止重放攻击
4. 提取证书状态 — 从响应体中取出目标证书的 serialNumber 对应状态

为什么会这样？Nonce 机制本质上是防重放，但它强制要求“请求-响应”一一对应，彻底阻断了缓存复用。如果每天有上千万次证书查询，你想想看——每秒钟几千次的签名运算，服务器扛得住吗？

响应格式与状态码

OCSP 响应用 ASN.1 编码，你不需要手写解析器，但理解结构对调优有帮助：

字段	含义	对性能的影响
responseStatus	协议层状态（success/malformedRequest/internalError/等）	基本无影响
producedAt	响应生成时间戳	影响缓存策略
thisUpdate	本次状态更新时刻	高频更新会提升 DB 负载
nextUpdate	下次状态更新的建议时刻	极度影响客户端缓存行为
certStatus	good / revoked / unknown	good 响应可以大量缓存

注意看 nextUpdate 这个字段。我习惯把它叫做“缓存命门”。你在生产环境里如果把 nextUpdate 设得太大，客户端缓存了过期的状态，证书被吊销了还继续信任；设得太小，客户端疯狂刷新，OCSP 响应器压力暴增。

响应生成流程（调优视角）

从 OCSP 响应器的角度看，响应的生成大致分四步：

• 接收与解析请求 — 从 HTTP POST 或 GET 中提取 DER 编码的请求体
• 数据库查询 — 根据证书序列号查询吊销状态
• 构建响应 — 填充 certStatus、thisUpdate、nextUpdate 等字段
• 签名输出 — 使用响应器证书私钥签名，返回 DER 编码响应

其中，签名是最耗时的环节。我记得在一个项目中做过测试，RSA 2048 签名大约消耗 1-2 毫秒。单次看不多，但遇到 DDoS 式的证书查询风暴，这就是瓶颈。

怎么破？常见的思路有两种：

1. 预签名缓存 — 提前生成常见证书的响应并签名，存到内存里，查询时直接返回
2. 批量签名 — 把一段时间内的多个查询攒起来，一次性批量签名后分发

关于 Unknown 状态的特别说明

客户端收到 unknown 时会怎么处理？这个得看你用的 TLS 库配置。

• soft-fail：遇到 unknown，直接当证书有效——这种做法很危险，攻击者可以伪造响应
• hard-fail：遇到 unknown，直接拒绝连接——安全但容易误伤

我经历过的真实案例：某金融客户统一配置了 hard-fail，结果内部 CA 的一台 OCSP 响应器挂了，整个支付系统瘫痪了半小时。后来我们给 OCSP 响应器前加了一层 Nginx 缓存，并做了多节点冗余。