OCSP 与 CRL：证书吊销机制的原理与协议分析

协议详解 · 2026-06-01

概述

在 PKI（公钥基础设施）体系中，证书的有效性验证不仅需要确认其签名正确、未过期，还需要确认它尚未被吊销。证书吊销是 PKI 安全模型中常被低估但至关重要的一环——即使一个证书的签名有效、主体正确，如果它已被吊销，就不应被信任。

历史上最著名的证书吊销失败案例是 2011 年 DigiNotar 事件：攻击者入侵了荷兰 CA DigiNotar，伪造了 google.com 的证书。虽然证书本身在技术上完全合法（签名有效），但浏览器厂商最终不得不将 DigiNotar 的根证书从信任库中移除——因为该 CA 的吊销机制未能及时阻止攻击。

本文深入分析两大核心吊销机制：CRL（Certificate Revocation List，证书吊销列表）和 OCSP（Online Certificate Status Protocol，在线证书状态协议）。

CRL：证书吊销列表

基本思想

CRL 是最传统的证书吊销机制：CA 定期发布一个包含所有已吊销证书序列号的签名列表。依赖方在验证证书时，下载该列表并检查目标证书是否在列。

CRL 的数据结构（X.509 v2 CRL）

根据 RFC 5280 和 GM/T 0015-2023，CRL 的结构如下：

CODE

CertificateList ::= SEQUENCE {
    tbsCertList              TBSCertList,
    signatureAlgorithm       AlgorithmIdentifier,
    signatureValue           BIT STRING
}

TBSCertList ::= SEQUENCE {
    version                  Version OPTIONAL,          -- v2 时为必填
    signature                AlgorithmIdentifier,
    issuer                   Name,
    thisUpdate               Time,
    nextUpdate               Time,
    revokedCertificates      SEQUENCE OF SEQUENCE {
        userCertificate         CertificateSerialNumber,
        revocationDate          Time,
        crlEntryExtensions      Extensions OPTIONAL
    } OPTIONAL,
    crlExtensions           [0] EXPLICIT Extensions OPTIONAL
}

CRL 的关键字段

字段	含义	重要性
`issuer`	签发该 CRL 的 CA	确定信任源
`thisUpdate`	CRL 发布时间	判断时效性
`nextUpdate`	下次更新时间	关键：过期后 CRL 无效
`revokedCertificates`	吊销条目列表	包含序列号和吊销时间
`crlExtensions`	CRL 扩展	包括 CRL Number、Delta CRL 指示器等

CRL 的发布与验证流程

CODE

CA                                    依赖方（浏览器/客户端）
 |                                           |
 |  1. 生成并签名 CRL                          |
 |     (包含所有已吊销证书序列号)               |
 |                                           |
 |---------- CRL 发布到 CDP --------------->|
 |  (CRL Distribution Point)                 |
 |                                           |
 |  2. 验证证书链                             |
 |  3. 从 CDP 下载 CRL                        |
 |  4. 验证 CRL 签名                          |
 |  5. 检查 thisUpdate/nextUpdate             |
 |  6. 在 CRL 中查找目标证书序列号             |
 |  7. 若找到 → 证书已吊销，拒绝              |
 |     若未找到 → 证书有效（未被吊销）         |

CRL 的扩展机制

1. CRL Distribution Points (CDP)

证书中可嵌入 CRL 的下载位置（LDAP、HTTP、FTP）：

CODE

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
    distributionPoint       [0] DistributionPointName OPTIONAL,
    reasons                 [1] ReasonFlags OPTIONAL,
    cRLIssuer               [2] GeneralNames OPTIONAL
}

2. Delta CRL（增量 CRL）

只包含自上次完整 CRL 以来的新增吊销条目，通过 CRL Number 区分：

CODE

DeltaCRLIndicator ::= { crlNumber }  -- CRL 扩展

3. Authority Information Access (AIA) 中的 OCSP 位置

现代证书通常同时包含 CDP 和 OCSP 位置，客户端可根据场景选择验证方式。

CRL 的局限性

问题	描述	影响
时效性差	CRL 定期发布（通常 24h 以上）	证书吊销后到下次 CRL 更新前存在安全窗口
体积膨胀	大型 CA 的 CRL 可达数百 MB	下载和解析成本高
隐私问题	客户端下载 CRL 会暴露验证行为	相对较轻（批量下载）
缓存问题	客户端可能缓存过期 CRL	需要强制的 nextUpdate 检查

OCSP：在线证书状态协议

基本思想

OCSP（RFC 6960）提供实时的证书状态查询：客户端向 OCSP Responder 发送证书序列号，接收"good"、"revoked"或"unknown"的实时响应。

OCSP 请求格式

CODE

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,
    requestExtensions   [2] EXPLICIT Extensions OPTIONAL
}

Request ::= SEQUENCE {
    reqCert             CertID,
    singleRequestExtensions [1] EXPLICIT Extensions OPTIONAL
}

CertID ::= SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING,
    issuerKeyHash       OCTET STRING,
    serialNumber        CertificateSerialNumber
}

OCSP 响应格式

CODE

OCSPResponse ::= SEQUENCE {
    responseStatus      OCSPResponseStatus,
    responseBytes       [0] EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus ::= ENUMERATED {
    successful          (0),
    malformedRequest    (1),
    internalError       (2),
    tryLater            (3),
    sigRequired         (5),
    unauthorized        (6)
}

ResponseBytes ::= SEQUENCE {
    responseType    OBJECT IDENTIFIER,
    response        OCTET STRING  -- 实际为 BasicOCSPResponse
}

OCSP 响应状态

状态	含义	客户端行为
`good`	证书有效	继续验证流程
`revoked`	证书已吊销	立即终止连接
`unknown`	Responder 不知道该证书	根据策略决定（soft-fail 或 hard-fail）

OCSP 的关键扩展

1. OCSP Multi-Stapling（RFC 6960, RFC 6066）

TLS 握手期间，服务器将 OCSP 响应"装订"在证书链中发送给客户端，避免客户端额外查询：

CODE

Client                                    Server   OCSP Responder
  |                                          |           |
  |--- ClientHello ----------------------->|           |
  |                                          |--- OCSP Request -->|
  |                                          |<-- OCSP Response --|
  |<-- Certificate + OCSP Staple --------|           |
  |                                          |           |
  | (无需额外 OCSP 查询)                     |           |

2. OCSP Must-Staple（RFC 7633）

证书扩展 TLS Feature: status_request 强制要求客户端必须收到有效的 OCSP Staple，否则拒绝连接。这解决了 OCSP 的 soft-fail 问题。

3. OCSP Nonce（RFC 6960）

请求中包含随机数，防止重放攻击。但大多数 Responder 不支持此扩展（缓存响应会忽略 nonce）。

CRL vs OCSP 对比

维度	CRL	OCSP
实时性	差（定期发布，通常 24h+）	好（实时查询）
网络开销	大（下载完整列表）	小（单条查询）
隐私保护	好（批量下载不暴露具体查询）	差（Responder 知道你在验证哪个证书）
可用性	好（可缓存）	差（Responder 宕机则服务中断）
部署复杂度	低（HTTP/FTP 分发）	中（需要 Responder 基础设施）
签名验证	一次验证整个 CRL	每次查询验证响应签名
离线验证	✅ 支持（缓存后离线使用）	❌ 不支持（需要在线查询）

OCSP Stapling：最佳实践

OCSP Stapling（TLS Certificate Status Request Extension，RFC 6066）结合了 CRL 和 OCSP 的优点：

工作原理

CODE

1. 服务器定期向 OCSP Responder 查询自己证书的状态
2. 服务器缓存 OCSP 响应（通常数小时）
3. TLS 握手时，服务器将缓存的 OCSP 响应附加在证书链中
4. 客户端验证 OCSP 响应的签名和时间戳
5. 客户端无需自行查询 OCSP Responder

优势

性能：客户端无需额外网络请求
隐私：OCSP Responder 不知道客户端在访问哪个网站
可靠性：即使 OCSP Responder 宕机，服务器仍可使用缓存的响应
安全性：响应由 CA 签名，客户端可验证

部署注意事项

事项	建议
响应缓存时间	不超过 `nextUpdate` 时间
刷新策略	在 `nextUpdate` 前 24h 刷新
多证书链	每个证书都需要独立的 OCSP 响应
回退机制	OCSP 不可用时回退到 CRL

国密体系中的证书吊销

GM/T 0015-2023 数字证书格式

GM/T 0015-2023《数字证书格式》定义了国密体系中的证书格式，与 X.509 v3 兼容但增加了国密特有的 OID 和扩展：

使用 SM2 算法签名的证书
证书序列号字段用于吊销检查
支持 CRL Distribution Points 扩展
支持 Authority Information Access 扩展（OCSP 位置）

国密 OCSP 实现

国密体系中的 OCSP 实现需要：

使用 SM3 作为哈希算法（替代 SHA-1/SHA-256）
使用 SM2 签名算法（替代 RSA/ECDSA）
响应格式遵循 RFC 6960，但算法标识符使用国密 OID

已知攻击与防御

1. CRL 投毒攻击

攻击方式：攻击者篡改 CRL 内容，添加合法证书的序列号（导致服务拒绝）或删除已吊销证书的条目。

防御：CRL 由 CA 签名，客户端必须验证签名。使用 HTTPS 分发 CRL 防止中间人篡改。

2. OCSP 重放攻击

攻击方式：攻击者截获旧的 OCSP 响应（good 状态），在证书已吊销后重放该响应。

防御：检查 OCSP 响应中的 producedAt、thisUpdate 和 nextUpdate 时间戳。OCSP Must-Staple 扩展要求响应必须新鲜。

3. OCSP Must-Staple 绕过

攻击方式：中间人移除 TLS 握手中的 status_request 扩展。

防御：客户端实现 Must-Staple 时，如果证书包含 status_request 扩展但未收到 OCSP Staple，应拒绝连接（hard-fail）。

4. Soft-Fail 漏洞

攻击方式：当 OCSP Responder 不可用时，大多数客户端采用 soft-fail 策略（假设证书有效），这允许攻击者通过阻断 OCSP 查询来绕过吊销检查。

防御：使用 OCSP Must-Staple 扩展，或部署本地 CRL 缓存作为回退。

OCSP 与 CRL：证书吊销机制的原理与协议分析

概述

CRL：证书吊销列表

基本思想

CRL 的数据结构（X.509 v2 CRL）

CRL 的关键字段

CRL 的发布与验证流程

CRL 的扩展机制

CRL 的局限性

OCSP：在线证书状态协议

基本思想

OCSP 请求格式

OCSP 响应格式

OCSP 响应状态

OCSP 的关键扩展

CRL vs OCSP 对比

OCSP Stapling：最佳实践

工作原理

优势

部署注意事项

国密体系中的证书吊销

GM/T 0015-2023 数字证书格式

国密 OCSP 实现

已知攻击与防御

1. CRL 投毒攻击

2. OCSP 重放攻击

3. OCSP Must-Staple 绕过

4. Soft-Fail 漏洞

参考来源

相关实践