证书吊销机制深度解析：CRL、OCSP 与 OCSP Stapling 的工程实践

PKI 体系 · 2026-06-05 · 7 阅读

前言

2025 年 8 月 6 日，全球最大的证书颁发机构 Let's Encrypt 正式终止了 OCSP（在线证书状态协议）服务，转而全面使用 CRL（证书吊销列表）。这一决定在 PKI 行业引发广泛讨论——OCSP 作为 CRL 的现代替代品已经发展了二十多年，为何又被放弃？

这个问题的答案并不简单，它涉及隐私、性能、安全性和部署复杂度之间的深层权衡。理解证书吊销机制，不仅是 PKI 体系的基础知识，更是构建可信网络基础设施的关键环节。

本文将从三大证书吊销机制的工作原理出发，结合 RFC 标准、实际部署数据和国密 PKI 体系的特殊性，帮助读者建立完整的认知框架。

为什么需要证书吊销

数字证书是 PKI 体系的信任基石。一个证书在有效期内可能因为以下原因需要被提前吊销：

吊销原因	典型场景
私钥泄露	服务器被入侵，私钥文件被窃取
CA 误签发	CA 发现证书申请信息不真实
域名变更	原证书持有者不再拥有该域名
业务终止	服务器下线，证书不再需要
批量吊销事件	CA 自身系统被攻破（如 2011 年 DigiNotar 事件）

根据 RFC 5280 第 5.3.1 节，吊销原因码（Reason Code）定义了 11 种标准值，包括 keyCompromise（1）、cACompromise（2）、affiliationChanged（3）等。

如果没有吊销机制，一个私钥已泄露的证书在到期前仍然会被浏览器信任，攻击者可以利用它进行中间人攻击。

机制一：CRL（证书吊销列表）

工作原理

CRL 是最古老的证书吊销机制，定义在 X.509 标准和 RFC 5280 中。本质上，CRL 是一个由 CA 定期发布的文件，包含所有已被吊销但尚未过期的证书序列号。

CODE

┌─────────────┐         ┌──────────────┐         ┌─────────────┐
│   CA 签发证书  │         │  CA 发布 CRL   │         │  客户端验证    │
│              │         │              │         │              │
│  证书包含:    │         │  CRL 包含:    │         │  1. 下载 CRL  │
│  CDP URL ──────→ 查询 ──→  吊销证书列表  │ ←────── │  2. 搜索序列号│
│  (CRL分发点)  │         │  签名 + 有效期  │         │  3. 判断状态  │
└─────────────┘         └──────────────┘         └─────────────┘

CRL 分发点（CDP, CRL Distribution Point） 是证书中的一个字段，指定了 CRL 文件的获取 URL。浏览器在验证证书时会从该地址下载 CRL。

CRL 的结构

一个标准的 X.509 CRL 包含以下字段：

CODE

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

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

CRL 的局限性

体积膨胀问题：大型 CA 的 CRL 文件可能达到数十 MB。Let's Encrypt 在 2025 年的数据显示，其 CRL 文件已经超过 100 MB。每次 TLS 连接都下载完整 CRL 不现实。

时间窗口风险：CRL 是定期发布的（通常几小时到一天），在两次发布之间存在"吊销窗口期"。如果证书在 CRL 发布后立即被吊销，最长可能需要等一天才能被检测到。

缓存与一致性：浏览器和操作系统通常缓存 CRL 约 7 天。缓存期间，即使证书已被吊销，客户端可能仍然信任它。

增量 CRL（Delta CRL）：RFC 5280 支持增量 CRL，只包含自上次完整 CRL 以来的变更。但并非所有客户端都支持。

机制二：OCSP（在线证书状态协议）

工作原理

OCSP 定义在 RFC 6960 中，旨在解决 CRL 的可扩展性问题。客户端不再下载完整列表，而是向 OCSP 响应器（OCSP Responder）发送针对单个证书的查询请求。

CODE

┌──────────────┐                              ┌──────────────────┐
│   客户端      │  OCSP Request               │   OCSP 响应器     │
│              │  (证书序列号 + 颁发者信息)      │                  │
│              │ ─────────────────────────→   │                  │
│              │                              │  查询证书状态      │
│              │  OCSP Response              │  签名响应          │
│              │  (good / revoked / unknown)  │                  │
│              │ ←─────────────────────────   │                  │
└──────────────┘                              └──────────────────┘

OCSP 请求格式

OCSP 请求使用 ASN.1 编码，通过 HTTP POST 或 GET 发送：

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     [0]     EXPLICIT Extensions OPTIONAL  }

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

OCSP 的三大问题

1. 隐私风险

这是 Let's Encrypt 关停 OCSP 的核心原因。当浏览器向 OCSP 响应器发送查询时，CA 可以获知：

用户访问了哪个网站（通过证书序列号）
用户的 IP 地址
访问时间

这构成了一个大规模的用户浏览行为监控网络。Let's Encrypt 在其官方博客中明确指出："OCSP 代表了对互联网隐私的重大风险"。

2. 性能开销

每次 TLS 连接都需要额外的 HTTP 请求到 OCSP 响应器。在高并发场景下，这会显著增加连接延迟。

3. 软失败（Soft-fail）问题

当 OCSP 响应器不可达时（网络故障、DDoS 攻击等），大多数浏览器选择"软失败"——即忽略错误继续建立连接。这意味着即使证书已被吊销，如果攻击者能阻断 OCSP 查询，浏览器仍会信任已吊销的证书。

机制三：OCSP Stapling（OCSP 装订）

工作原理

OCSP Stapling（也称为 TLS 证书状态请求扩展）定义在 RFC 6066 中，解决了 OCSP 的隐私和性能问题。

核心思路：由 Web 服务器代替客户端去查询 OCSP 响应器，并将带有 CA 签名的 OCSP 响应"装订"在 TLS 握手过程中发送给客户端。

CODE

┌──────────────┐                              ┌──────────────────┐
│   客户端      │                              │   OCSP 响应器     │
│              │                              │                  │
│              │  TLS Handshake               │                  │
│              │  (ClientHello)               │                  │
│              │ ──────────────────────→      │                  │
│              │                              │                  │
│              │  ServerHello + Certificate   │                  │
│              │  + OCSP Response (Stapled)   │  ←── 服务器定期  │
│              │ ←──────────────────────      │     查询并缓存   │
│              │                              │                  │
│  验证 OCSP 签名的有效性                       │                  │
│  无需额外网络请求                             │                  │
└──────────────┘                              └──────────────────┘

OCSP Stapling 的优势

维度	传统 OCSP	OCSP Stapling
隐私	CA 知道用户访问了哪些网站	CA 只知道服务器访问了 OCSP
性能	客户端额外一次 HTTP 请求	零额外请求，响应随证书一起发送
可靠性	依赖客户端网络可达 OCSP	依赖服务器网络，更可控
安全性	软失败可被攻击者利用	服务器可强制要求装订

Must-Staple 扩展

RFC 7633 定义了 TLS 功能扩展（Must-Staple），允许证书在扩展字段中声明"此证书必须附带有效的 OCSP Stapling 响应"。如果客户端收到 Must-Staple 证书但没有看到装订的 OCSP 响应，连接将被拒绝。这解决了传统 OCSP 的软失败问题。

Let's Encrypt 的决策分析

Let's Encrypt 在 2024 年 7 月宣布计划关停 OCSP，2025 年 8 月正式执行。其决策依据：

隐私优先：作为非营利 CA，Let's Encrypt 认为不应运营一个可以监控全球用户浏览行为的系统
规模现实：每天数十亿次 OCSP 查询的运营成本巨大
行业趋势：主流浏览器厂商（Chrome、Firefox）已支持 CRL 缓存优化方案
替代方案：通过 OneCRL（Mozilla）和 CRLSet（Google）等机制，浏览器厂商直接分发吊销列表

但需要注意的是，Let's Encrypt 并未完全放弃吊销机制，而是转向了 CRL。他们采用了分层的 CRL 发布策略，结合浏览器厂商的本地吊销列表，实现了比传统 OCSP 更好的效果。

国密 PKI 体系中的证书吊销实践

国密 PKI 的特殊考虑

双证书体系：国密 TLS 部署通常需要 SM2 签名证书和 SM2 加密证书两张证书，吊销时需要同时处理两张证书的状态
CRL 签名算法：国密 CRL 使用 SM2 签名 + SM3 哈希，与 RSA/ECDSA CRL 在验证逻辑上有所不同
OCSP 响应器兼容性：国密 OCSP 响应器需要支持 SM2 签名验证，目前主流浏览器不原生支持，通常需要中间件或插件

部署建议

对于国密 PKI 系统的证书吊销，建议采用以下策略：

短期：部署 CRL 分发点，确保 CDP 字段正确配置
中期：实现 OCSP 响应器，支持 SM2 签名
长期：在支持国密协议的浏览器中实现 OCSP Stapling

工程实践：Nginx 配置 OCSP Stapling

以下是在 Nginx 中配置 OCSP Stapling 的完整配置：

NGINX

server {
    listen 443 ssl;
    server_name example.com;

    # 证书配置
    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    # OCSP Stapling 配置
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;  # CA 证书链
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # 其他 TLS 配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;
}

验证 OCSP Stapling 是否生效：

BASH

# 方法一：openssl s_client
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 5 "OCSP Response Status"

# 方法二：在线检测
# 使用 SSL Labs (https://www.ssllabs.com/ssltest/) 检测 OCSP Stapling 状态

常见踩坑：

ssl_trusted_certificate 配置错误：必须包含完整的 CA 证书链，否则无法验证 OCSP 响应的签名
DNS 解析器不可达：OCSP Stapling 需要服务器能解析 OCSP 响应器的域名，确保 resolver 配置正确
证书链不完整：ssl_certificate 必须包含服务器证书 + 中间 CA 证书（fullchain），否则客户端无法验证

性能对比数据

以下是三种吊销检查机制的性能对比（基于实际部署数据）：

指标	CRL	OCSP	OCSP Stapling
额外网络请求	首次下载 CRL	每次连接 1 次	0 次
首次连接延迟增加	50-200ms（下载 CRL）	20-100ms	0ms
后续连接延迟	0ms（缓存命中）	20-100ms	0ms
带宽消耗	高（完整 CRL 文件）	低（单次查询）	极低（响应随证书发送）
隐私保护	好（本地检查）	差（CA 可见）	好（服务器代理）
吊销实时性	低（小时级）	高（实时）	高（取决于服务器刷新频率）
部署复杂度	低	中	中

总结

证书吊销是 PKI 体系中不可或缺的安全机制。三种方案各有优劣：

CRL：简单可靠，适合吊销量不大的场景，但存在体积膨胀和时间窗口问题
OCSP：实时性好，但存在隐私风险和软失败问题
OCSP Stapling：综合性能最优，是当前推荐的方案，但需要服务器端支持

Let's Encrypt 关停 OCSP 标志着行业趋势的变化——隐私保护正在成为 PKI 设计的重要考量。对于国密 PKI 体系，建议在部署时优先考虑 OCSP Stapling，同时确保 CRL 作为兜底机制可用。

在实际工程中，最佳实践是同时部署 CRL 和 OCSP Stapling，让客户端根据自身能力选择最优的验证方式。

参考来源

← 返回文章列表

证书吊销机制深度解析：CRL、OCSP 与 OCSP Stapling 的工程实践

前言

为什么需要证书吊销

机制一：CRL（证书吊销列表）

工作原理

CRL 的结构

CRL 的局限性

机制二：OCSP（在线证书状态协议）

工作原理

OCSP 请求格式

OCSP 的三大问题

机制三：OCSP Stapling（OCSP 装订）

工作原理

OCSP Stapling 的优势

Must-Staple 扩展

Let's Encrypt 的决策分析

国密 PKI 体系中的证书吊销实践

相关标准

国密 PKI 的特殊考虑

部署建议

工程实践：Nginx 配置 OCSP Stapling

性能对比数据

总结

参考来源