CRL 和 OCSP 是依赖方得知证书在过期前已被吊销的两种方式。证书吊销列表（RFC 5280 §5）是一份经过签名、列出已吊销序列号的列表，由客户端下载；在线证书状态协议（RFC 6960）则针对单张证书的查询作答。2024年以来，公共 Web PKI 给出的答案发生了决定性的转变：CRL 成为强制要求，OCSP 变为可选，最大的 CA 也关闭了 OCSP。
概览
| CRL | OCSP | |
|---|---|---|
| 规范 | RFC 5280 §5 | RFC 6960（nonce：RFC 8954） |
| 客户端得到什么 | 某一范围内全部已吊销序列号的签名列表 | 单个序列号的签名状态（正常、已吊销、未知） |
| 大小（2026年10月20日实测） | Let's Encrypt CRL 分片：62,116 字节，含 1,591 个条目 | DigiCert OCSP 响应：471 字节 |
| 时效 | thisUpdate 至 nextUpdate（该分片：9 天） | 响应有效期（该响应：7 天） |
| 隐私 | 服务器只能得知有人获取了 CRL | 响应器会得知客户端正在访问哪个网站 |
| 可用性依赖 | 可以缓存、镜像和预加载 | 除非使用 stapling，否则实时依赖响应器 |
| Web PKI 规则（《基线要求》） | 2024年3月15日起强制要求；至少每 4 天发布一次新的 CRL（如果每张证书都带有 OCSP URL，则为 7 天），并在吊销后 24 小时内发布 | 2024年3月15日起可选 |
| 浏览器使用情况 | 汇总使用：Firefox CRLite、Chrome CRLSets | Firefox 已停止为 DV 证书发起查询（142 版）；Chrome 对大多数证书不发起查询 |
| 由服务器提供 | 不适用 | OCSP Stapling（status_request，RFC 6066） |
两者的工作原理
CRL 写明颁发者，包含 thisUpdate 和 nextUpdate、单调递增的 CRL 编号，以及每张已吊销证书对应的一个条目（序列号、吊销日期和可选的吊销原因），并由 CA 签名。证书通过 CRL 分发点（CRL Distribution Points）扩展指向自己的 CRL；大型 CA 会对 CRL 分片，使每个文件保持在便于处理的大小；公共 CA 会在 CCADB 中披露全部 CRL URL，以便汇总方收集到每一条吊销记录。检查 CRL 的客户端会下载并缓存 CRL；对于较大的列表，增量 CRL（RFC 5280 §5.2.4）可以减少流量。
OCSP 客户端把颁发者名称哈希、颁发者公钥哈希和序列号发送到证书“授权信息访问”（Authority Information Access）扩展中的 URL；响应器返回经过签名的状态，并附带自身的有效期窗口。响应可以缓存到 nextUpdate，服务器还可以通过 stapling 把最新的响应附在 TLS 握手中，这样客户端就无需联系 CA。
上表中的数据均为实时测得：一张 Let's Encrypt 证书（2026年9月签发）只指向 http://ye2.c.lencr.org/96.crl（没有 OCSP URL），该分片大小为 62 KB；一张 DigiCert 证书仍然带有 http://ocsp.digicert.com，其响应为 471 字节。
为什么 OCSP 在 Web 上逐渐退场
实时 OCSP 在浏览器中的失败源于三个特性。隐私：每次查询都会让 CA 知道某个用户正从哪个 IP 地址访问哪个网站。可用性：响应器缓慢或无法访问时，要么阻塞页面加载，要么由于浏览器选择了软失败（soft-fail）而被静默忽略，这意味着能够阻断响应器的攻击者就能让这项检查失效。成本：响应器必须承接互联网上的每一次页面加载。Stapling 解决了隐私和成本问题，但依赖每台服务器都能可靠地刷新响应；而本可以让 stapling 变为强制的 Must-Staple（RFC 7633）只得到了 Firefox 的支持。
CA/Browser Forum 以 SC-063 提案（2024年3月15日生效）作出应对：CRL 成为强制要求，OCSP 变为可选。Let's Encrypt 于2025年5月7日从新证书中移除 OCSP URL 并停止接受 Must-Staple 订单，又于2025年8月6日关闭了响应器。Firefox 在 137 版中为所有桌面用户启用了 CRLite：它是一种紧凑的本地编码，涵盖已写入 CT 日志的证书中的每一条吊销记录，每 12 小时刷新一次，平均每天下载约 300 kB。随后，Firefox 142 停止对域名验证证书发起 OCSP 查询。Chrome 依靠的是 CRLSets（一个经过筛选、侧重高影响吊销的集合），而不是逐个网站查询。
第三种选择：短期证书
有效期只有几天的证书无需检查吊销状态：等到吊销信息传播开来，证书早已过期。《基线要求》允许 CA 在短期证书中省略吊销信息（2026年3月15日起签发的短期证书，有效期最长 7 天）；2026年1月起，Let's Encrypt 还通过其 shortlived ACME 配置文件提供 160 小时的证书。再加上证书有效期的普遍缩短（2029年起缩短至 47 天，SC-081v3 提案），吊销正在成为兜底手段，而不再是主要的控制措施。证书有效期计算器可以按签发日期显示各项上限。
如何选择
- 公共 TLS 服务器：无需特别处理；确保证书来自发布 CRL 的 CA，并且不要启用 Must-Staple。移除在没有 OCSP URL 时会出错的 stapling 配置。
- 验证公共证书的客户端软件：使用平台自带的验证器；在可用的情况下，它会应用浏览器厂商的吊销集合。
- 客户端众多且部分离线的私有 PKI：使用
nextUpdate较短的 CRL，通过高可用的 HTTP 服务提供。 - 拥有高价值证书且客户端在线的私有 PKI：使用 OCSP，在协议支持的地方启用 stapling；如果响应器由你掌控，采用硬失败（hard-fail）策略。
- 工作负载和服务身份：自动签发的短期证书（几小时到几天），完全不需要吊销基础设施。
- 代码签名和文档签名：对于长期有效的签名，吊销依然重要；将 CRL 或 OCSP 与时间戳结合使用，让验证者能够检查签名时的证书状态。
迁移说明
- 梳理对 OCSP 的依赖：服务器的 stapling 配置、没有 OCSP 就硬失败的客户端、检查响应器的监控。
- 让 stapling 成为可选项：证书没有 OCSP URL 时，nginx 和 Apache 不得拒绝启动。
- 私有 CA 应先发布 CRL：在新证书中添加 CRL 分发点，对大型列表分片，按你的吊销 SLA 设置
nextUpdate，并通过 HTTP（而不是 HTTPS，以免形成循环依赖）提供 CRL。 - 缩短证书有效期（在自动化条件允许的地方）；每缩短一步，需要由吊销承担的部分就少一些。
- 端到端测试吊销：吊销一张测试证书，确认客户端在预期时间内拒绝它。CRL 解码器和 OCSP 解码器可以显示客户端将会看到的内容。