第2章 证书状态检查方式：CRL的局限性与OCSP的工作原理

证书吊销检查，说白了就是确保你连接的服务器证书没有被CA提前拉黑。我用过的生产系统里，至少有一半的线上事故都跟证书检查策略配错有关。这章咱们把CRL和OCSP掰开揉碎了聊。

2.1 CRL——传统证书吊销列表

CRL全称Certificate Revocation List，就是CA定期发布的一份“黑名单”。服务器在TLS握手时并不主动提供这份列表，而是由客户端自己下载并比对。

流程不复杂：

1. 客户端拿到服务器证书后，从证书里取出CRL分发点URL
2. 客户端去下载对应CA的CRL文件
3. 解析CRL，检查证书序列号是否在列表中
4. 如果没有——证书有效；如果在了——拒绝连接

听起来合理，对吧？但我在两年前的一起线上故障里，吃足了CRL的苦头。

2.1.1 CRL的致命短板

CRL的问题可以归纳成几点：

• 体积爆炸——大型CA的CRL动辄几十MB，移动端、IoT设备根本扛不住
• 滞后严重——CA通常几小时甚至一天才更新一次CRL。如果证书被吊销，这窗口期内攻击者能继续滥用
• 下载开销——每次TLS握手都要额外HTTP下载，延迟增加100-500ms是常事
• 单点故障——CRL分发点一旦挂了，客户端只能放弃校验或被攻击

你想想看，一个追求毫秒级响应的TLS握手，中间还要去拉几十MB的文件，这设计从一开始就没考虑性能。

2.2 OCSP——在线证书状态协议

OCSP（Online Certificate Status Protocol）就是为了解决CRL的臃肿和滞后问题而生的。它的思路很简单：客户端只问“这个证书是好的还是坏的？”，CA只回答“好”或“坏”。

核心流程：

1. 客户端从服务器证书中提取OCSP响应器URL
2. 构造一个OCSP请求，包含证书序列号和颁发者信息
3. 发送HTTP POST或GET到OCSP响应器
4. 响应器返回签名后的响应：good / revoked / unknown
5. 客户端验证响应的签名和时效

2.2.1 OCSP的请求/响应格式

下面是个简化版的OCSP请求结构（ASN.1 DER编码）：

OCSPRequest ::= SEQUENCE {
    tbsRequest      TBSRequest,
    optionalSignature [0] EXPLICIT Signature OPTIONAL
}
TBSRequest ::= SEQUENCE {
    version          [0] EXPLICIT Version DEFAULT v1,
    requestorName    [1] EXPLICIT GeneralName OPTIONAL,
    requestList      SEQUENCE OF Request
}
Request ::= SEQUENCE {
    reqCert          CertID,
    singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL
}
CertID ::= SEQUENCE {
    hashAlgorithm    AlgorithmIdentifier,
    issuerNameHash   OCTET STRING,
    issuerKeyHash    OCTET STRING,
    serialNumber     CertificateSerialNumber
}

响应类似：

OCSPResponse ::= SEQUENCE {
    responseStatus      OCSPResponseStatus,
    responseBytes       [0] EXPLICIT ResponseBytes OPTIONAL
}
ResponseBytes ::= SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING  -- 实际是BasicOCSPResponse
}
BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData      ResponseData,
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

嗯，这些二进制编码看着头疼。但你要记住的是：客户端会验证OCSP响应的签名，确保不是中间人伪造的。

2.2.2 OCSP的隐私与性能问题

我个人习惯把OCSP的缺点也列出来，否则你会觉得它是银弹。

• 隐私泄露——每次查询都把证书序列号和来访IP发给CA，CA能知道哪个客户端访问了哪个网站
• 开销仍然存在——每次TLS握手都多一次HTTP往返，延迟从0.5ms变成30-80ms
• 响应器可访问性——如果OCSP响应器挂了，客户端该怎么处理？软失败（放行）还是硬失败（拒绝）？我见过的生产事故中，不少人选了软失败导致被攻击
• 签名验证开销——OCSP响应需要验证CA签名，CPU消耗比简单查CRL高

2.3 CRL vs OCSP 对比

下面这张表是我在实际优化项目中总结的：

说白了，CRL适合那种你能接受滞后、且网络带宽富裕的内部场景。互联网生产环境，我几乎不会选纯CRL方案。

2.4 核心知识图谱

下面这张图概括了本章的核心逻辑：从证书状态检查的两种方式，到各自的流程和瓶颈，最终指向下一章要讲的优化方案——OCSP Stapling。

2.5 选型建议

我个人看法是这样的：

• 如果跑在内网且证书数量少，CRL或许还能凑合。但移动端、IoT一律别用
• 互联网服务务必上OCSP，但别裸用——下一章会讲OCSP Stapling如何把额外往返去掉
• 如果隐私是红线，可以考虑DoH或OCSP Must-Staple扩展