# OCSP 与 CRL：证书吊销检查原理与 2026 年现状

> CRL 和 OCSP 如何发布证书吊销信息，Let's Encrypt 为什么在 2025 年关停 OCSP，Chrome CRLSets 与 Firefox CRLite 现在怎样检查吊销。

Source: https://ssl.sh/zh/learn/ocsp-and-crl/
Last updated: 2026-11-10

证书吊销用来告诉客户端：这张证书还没过期，但已经不能再信任。CA 有两种发布方式：CRL 是一份签名的吊销序列号清单，OCSP 是按单张证书实时查询的状态服务。截至 2026 年 11 月，公网 PKI 已经全面转向 CRL：OCSP 对 CA 变成可选，Let's Encrypt 在 2025 年 8 月关掉了响应器，浏览器改用本地缓存的数据判断吊销。

## 为什么需要吊销

证书可能在到期前很久就变得不可信，这就是吊销存在的原因。常见情况有：私钥泄露、域名换了主人、证书签发有误、CA 发现自己的验证流程有漏洞。按照 [Baseline Requirements](https://ssl.sh/zh/glossary/baseline-requirements/)，最严重的情形（例如确认私钥泄露）CA 要在 24 小时内吊销，其余大多数情形是 5 天。

真正的难点在于“让客户端知道”。浏览器要在几十亿张证书里，及时而且不泄露隐私地得知某一张已经作废。CRL 和 OCSP 是两种答案，各有代价。

## CRL 的工作方式

CRL（证书吊销列表）是 CA 签名的一个文件，里面列出被吊销证书的序列号。格式定义在 [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280) 第 5 节，证书通过 **CRL Distribution Points**（CRL 分发点）扩展告诉客户端去哪里下载。

| 字段 | 含义 |
|---|---|
| Issuer | 签发这份清单的 CA |
| This Update / Next Update | 本次生成时间、下一次最晚更新时间 |
| Revoked Certificates | 序列号、吊销时间、可选的吊销原因 |
| CRL Number | 单调递增的序号 |
| Issuing Distribution Point | 标记分片 CRL 及其覆盖范围 |
| 签名 | CA 对以上内容的签名 |

大 CA 早就不发布一个巨大的 CRL 了，而是把吊销记录拆成许多**分片 CRL**（partitioned / sharded CRL）。2026 年 11 月签发的一张 Let's Encrypt 证书指向其中一个分片：

```text
X509v3 CRL Distribution Points:
    Full Name:
      URI:http://ye2.c.lencr.org/51.crl
```

用 OpenSSL 解开这个分片，能看到它的结构（有删节）：

```text
Certificate Revocation List (CRL):
    Version 2 (0x1)
    Signature Algorithm: ecdsa-with-SHA384
    Issuer: C=US, O=Let's Encrypt, CN=YE2
    Last Update: Nov  9 17:52:09 2026 GMT
    Next Update: Nov 18 17:52:08 2026 GMT
    CRL extensions:
        X509v3 CRL Number:
            1794246729324766624
        X509v3 Issuing Distribution Point: critical
            Full Name:
              URI:http://ye2.c.lencr.org/51.crl
            Only User Certificates
Revoked Certificates:
    Serial Number: 05E7C117F64B64BC83F3691B78C8F454F1B2
        Revocation Date: Sep 24 17:49:02 2026 GMT
```

这个分片约 100 KB，有几千条记录。CRL 自带签名、可以缓存、能放在任何 CDN 上，但想完整覆盖就得下载很多份，所以浏览器不会在访问网站时临时去拉 CRL。

## OCSP 的工作方式

OCSP（[RFC 6960](https://www.rfc-editor.org/rfc/rfc6960)）把“下载清单”换成了“一问一答”。客户端向 CA 的响应器发一个请求，用签发者名称和公钥的哈希加上序列号来标识一张证书，响应器返回签名过的状态。

```text
浏览器                              OCSP 响应器（CA）
   |  与 example.com 握手               |
   |  证书 AIA 里有 OCSP 地址           |
   |---- OCSP 请求（序列号 0x05E7…）---->|
   |<--- 签名响应：good / revoked / unknown，
   |     thisUpdate、nextUpdate --------|
   |  根据结果继续或中断连接            |
```

| 状态 | 含义 |
|---|---|
| `good` | 响应器认识这张证书，且未吊销 |
| `revoked` | 已吊销，附吊销时间和可选原因 |
| `unknown` | 响应器不认识这张证书 |

响应由 CA 本身或带 OCSP Signing EKU 的委托响应器证书签名。公网 CA 通常预先生成响应、通过明文 HTTP 由 CDN 分发，所以 RFC 里可选的 nonce 很少被使用。

## OCSP 为什么被放弃

OCSP 在隐私、可靠性和性能上都有结构性问题，业界最终认定修不好。

- **隐私**：每次查询都等于告诉 CA“这个 IP 正要访问哪个网站”，而且请求走明文 HTTP，链路上的任何人都看得到。Let's Encrypt 把这一点列为停用 OCSP 的首要原因。
- **软失败**：响应器连不上时，浏览器一向选择放行，否则 CA 的每次故障都会变成网站故障。能劫持流量的攻击者通常也能顺手拦掉 OCSP 请求，所以软失败的检查恰恰在最需要时失效。
- **延迟**：Mozilla 统计，OCSP 请求让 TLS 握手的中位数多阻塞约 100 毫秒。在国内访问境外 CA 的 OCSP 响应器，延迟和超时往往更明显，这也是过去国内运维普遍开启 Stapling 的原因。
- **成本**：Let's Encrypt 高峰期每月要应答约 3400 亿次 OCSP 请求。

## OCSP Stapling 与 Must-Staple

OCSP Stapling 把查询从浏览器挪到了服务器。客户端在握手中带上 [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066) 第 8 节定义的 `status_request` 扩展，服务器把自己事先取回的 OCSP 响应“钉”在握手里一起发出。TLS 1.2 里它是单独的 CertificateStatus 消息；TLS 1.3 里它放在 Certificate 消息中叶子证书条目的扩展里。

Stapling 解决了隐私和延迟，却解决不了软失败：服务器完全可以不钉。**Must-Staple**（RFC 7633 的 TLS Feature 扩展，OID 1.3.6.1.5.5.7.1.24）本想补上这个缺口，要求客户端在收不到钉附响应时拒绝证书。但实际情况是 Firefox 执行、Chrome 不执行，服务器在响应器故障时处理得很糟，带这个扩展的证书极少。Let's Encrypt 在 2025 年已不再接受 Must-Staple 申请。

```nginx
# 只有证书里仍有 OCSP 地址时才有意义
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 223.5.5.5 119.29.29.29 valid=300s;
```

## SC-063：CRL 必须有，OCSP 可选

[CA/Browser Forum](https://ssl.sh/zh/glossary/ca-browser-forum/) 在 2023 年通过的 SC-063 投票，把两种机制的地位颠倒了过来：签发公开信任 TLS 证书的 CA 必须发布 CRL，OCSP 则成为可选项。

投票同时规定了 CRL 的更新频率：吊销一张证书后 24 小时内必须发布新 CRL；平时，如果证书里带 OCSP 地址，至少每 7 天更新一次，否则至少每 4 天一次。分片 CRL 明确允许，只要合起来能覆盖全部吊销证书。

SC-063 还定义了**短期证书**：有效期不超过 10 天的证书（2026 年 3 月 15 日起签发的收紧到 7 天）可以不带 CRL 或 OCSP 地址，也不要求吊销，靠到期自然失效。Let's Encrypt 的 `shortlived` 配置签发 160 小时的证书，正好落在这个范围内。

## Let's Encrypt 在 2025 年停掉 OCSP

全球签发量最大的 Let's Encrypt 在 2025 年 8 月完成了向“只用 CRL”的切换。它 2022 年起就支持 CRL，2024 年 12 月 5 日公布了时间表：

| 日期 | 变化 |
|---|---|
| 2025-01-30 | 新的 Must-Staple 申请失败（以前用过 Must-Staple 的账户除外） |
| 2025-05-07 | 证书已带 CRL 地址；去掉 OCSP 地址；所有 Must-Staple 申请失败 |
| 2025-08-06 | 关闭 OCSP 响应器 |

到关停那天，所有带 OCSP 地址的证书都已过期，因此没有在用证书受影响。Let's Encrypt 特别提醒：浏览器和网站不受影响，但一些**非浏览器软件**，比如配置成必须查 OCSP 的 VPN 客户端或企业中间件，可能需要调整。国内不少政企内网设备、老版本 Java 应用开启了严格吊销检查，换成 Let's Encrypt 证书前值得先测一遍。

更多相关变化见 [Let's Encrypt 时间线](https://ssl.sh/zh/timeline/lets-encrypt/)。

## 浏览器现在怎么查吊销

现代浏览器提前把吊销数据推送到本地，而不是在握手时去问 CA。两种主流方案的覆盖范围差别很大：

| 客户端 | 机制 | 覆盖范围 |
|---|---|---|
| Chrome / Edge | CRLSets：从 CA 的 CRL 中挑选，经组件更新下发 | 紧急和重点吊销；按 Mozilla 的对比约占全部吊销的 1% |
| Firefox 桌面版 | CRLite：把 CT 日志中所有被吊销证书压缩编码，每 12 小时更新 | CT 日志中证书的全部吊销 |
| Firefox 对 DV 证书 | 自 Firefox 142 起停用 OCSP | 由 CRLite 覆盖 |

Chromium 官方文档写明 Chrome 一般不做在线 OCSP/CRL 检查，企业策略可以重新打开在线 OCSP。Mozilla 从 Firefox 137 起为所有桌面用户启用 CRLite，平均每天下载约 300 KB 吊销数据。CRLite 依赖 [证书透明度](https://ssl.sh/zh/learn/certificate-transparency/)：只有能在 CT 日志里找到的证书才会被收录。

浏览器之外的 TLS 实现各有各的规则。Windows CryptoAPI、Java 以及大量嵌入式客户端都有自己的吊销设置，有些企业产品可以配置成硬失败。如果你在维护这类软件，请用一张不带 OCSP 地址的证书测试一下。

## 运维需要做什么

大多数网站什么都不用改，但有几处配置值得检查。先确认证书里到底有哪些吊销指针：

```bash
openssl x509 -in cert.pem -noout -ocsp_uri
openssl x509 -in cert.pem -noout -ext crlDistributionPoints,authorityInfoAccess
```

- **Let's Encrypt 证书的 Stapling**：`-ocsp_uri` 没有输出，就说明 `ssl_stapling` 无事可做。宝塔等面板的默认模板常常打开它，留着无害，去掉可以少一条日志警告。
- **Must-Staple**：从 ACME 客户端配置里删掉 `--must-staple` 之类的选项，否则 Let's Encrypt 会拒绝订单。
- **内部客户端**：对 OCSP 有硬性要求的应用（开启 OCSP 的 Java、严格检查吊销的 VPN 网关）要能接受只有 CRL 的证书。
- **私有 PKI**：自建 CA 仍然可以运行 OCSP，但无论如何都应发布 CRL，参见 [私有 CA 命令手册](https://ssl.sh/zh/cookbook/private-ca/)。
- **私钥泄露**：先通过 CA 或 ACME 客户端吊销，再立即换证。不要只依赖吊销，部分客户端可能要好几天才会察觉。

检查线上服务器可以用 `openssl s_client -status`，看输出里有没有 OCSP response。浏览器里的吊销报错见 [NET::ERR_CERT_REVOKED](https://ssl.sh/zh/errors/net-err-cert-revoked/)。

## 吊销的未来

吊销问题的长期答案是缩短证书寿命。根据 [SC-081v3 投票](https://ssl.sh/zh/ballots/sc-081/)，公开信任 TLS 证书的最长有效期从 2026 年 3 月 15 日起是 200 天，2029 年 3 月 15 日起降到 47 天，详见 [47 天证书](https://ssl.sh/zh/learn/47-day-certificates/)。47 天证书的私钥一旦泄露，攻击者能利用的时间是几周而不是一年；6 天证书则根本不需要吊销。

CRL 仍是权威来源，浏览器把它们压缩成 CRLSets 和 CRLite，OCSP 主要留在私有 PKI 和选择继续提供它的 CA 那里。想亲手查看这些数据，可以照着 [OCSP 与 CRL 命令手册](https://ssl.sh/zh/cookbook/ocsp-crl/) 一步步来。