2026年8月24日
数字证书吊销列表（CRL）检查要回答的问题是：证书颁发机构（CA）是否已在证书到期之前将其吊销。你可以从证书中列出的分发点下载 CRL，在其中检索该证书的序列号，也可以直接使用 OpenSSL 的 verify -crl_check 命令。浏览器和操作系统会在 TLS 握手过程中自动完成这项检查，但任何管理公钥基础设施（PKI）或验证文档签署证书的人，都应该理解手动检查的步骤。本指南将说明 CRL 是什么、为什么吊销检查很重要、如何用 OpenSSL 等工具执行检查，以及 CRL 与 OCSP 的对比——帮助你判断哪种方式适合自己的工作流程。在生产环境中依赖任何检查结果之前，务必对照最新的 RFC 5280、CA 政策和厂商文档确认细节。
什么是证书吊销列表（CRL）？
证书吊销列表（CRL）是由 CA 签发并发布的、带有签名和时间戳的文件，用于公告哪些数字证书在到期前已被吊销。CRL 在 RFC 5280 中定义，其内容包含颁发者名称、列表生成日期（"this update"）、下一份列表的预期发布日期（"next update"），以及被吊销证书的序列号清单——每个序列号都附带吊销日期和一个可选的原因代码，例如私钥泄露、CA 被入侵或运营终止。
CA 吊销证书的原因有多种：私钥已泄露、证书被误发、订户已停止运营，或证书正被新证书替代。如果没有渠道获知这些吊销信息，依赖方就会继续信任一张证书直到它自然到期——哪怕 CA 早已宣布它不可信。
有几个实践细节值得注意：
- 基础 CRL（base CRL） 列出 CA 已知的全部被吊销证书；增量 CRL（delta CRL） 只列出相对上一份基础 CRL 的变化，从而降低带宽和解析开销。
- CRL 由颁发它的 CA 签名，因此其完整性可以被独立验证。
- 客户端通常会将 CRL 缓存至其 "next update" 时间，到期后下载新副本。
CRL 只是 PKI 吊销机制的一半，OCSP 提供另一半。两者回答的是同一个问题：这张证书现在是否仍然可信？想更全面地了解颁发证书并发布 CRL 的机构，请参阅我们的面向浏览器与电子签名的证书颁发机构列表。
为什么需要检查证书吊销状态
检查吊销状态，区别开“证书看起来有效”和“证书确实有效”。一张证书完全可以通过基本的信任链检查——颁发者正确、日期在有效期内、签名无误——却早已被吊销。如果你跳过吊销检查，就等于把所有未到期的证书都当作有效证书对待，这会让整个吊销机制形同虚设。
吊销检查最关键的场景包括：
- 私钥泄露。 攻击者一旦拿到私钥，CA 就会吊销对应的证书，让依赖方停止接受它。若不做吊销检查，你会继续信任用被盗私钥生成的签名。
- CA 误发。 CA 可能发现某张证书发给了错误的主体，或包含错误的属性。吊销是它事后撤回这张证书的手段。
- 运营终止。 公司停业或域名易主时，绑定在旧主体上的证书应被吊销，以免被他人复用。
- 文档与电子签名验证。 数字签名的 PDF 内嵌一张证书。如果该证书在签署之前（或在签署与验证之间）被吊销，签名的可信度就会随之改变。想深入了解完整的验证流程，请阅读我们关于如何验证商业场景中的数字签名的指南。
一个容易忽略的细节：被吊销的证书不等于已过期的证书。过期是自动的、基于日期的；吊销是 CA 的主动行为。这也是只检查有效期并不足够的原因。关于生命周期层面的背景，参见我们关于数字证书是否会过期的文章。
如何对照 CRL 检查证书
具体步骤因工具而异，但流程是一致的：在证书中找到 CRL 分发点（CDP），下载 CRL，然后检索证书的序列号。
第 1 步：找到 CRL 分发点。 每张支持 CRL 检查的证书都带有 CRL Distribution Points 扩展，其中包含一个或多个 URL。用 OpenSSL 提取：
```
openssl x509 -in certificate.pem -noout -text | grep -A 4 "CRL Distribution"
```
第 2 步：下载 CRL。 用 curl 或 wget 从找到的 URL 获取 CRL。CRL 通常以 DER 格式分发：
```
curl -o crl.der http://crl.example.com/intermediate.crl
```
第 3 步：查看 CRL 内容。 转换并解析 CRL，查看其颁发者、更新时间和被吊销的序列号：
```
openssl crl -in crl.der -inform DER -text -noout
```
第 4 步：对照 CRL 验证证书。 将 CA 证书与 CRL 合并为一个文件，然后带上 -crl_check 参数运行 OpenSSL 的 verify 命令：
```
cat ca.crt crl.pem > ca-crl.pem
openssl verify -crl_check -CAfile ca-crl.pem certificate.pem
```
如果证书的序列号出现在 CRL 中，OpenSSL 会报告吊销错误。如果 CRL 已过期（超过其 "next update" 时间）或无法访问，检查同样会失败——这是安全的默认行为。
浏览器与操作系统层面的检查。 主流浏览器会在 TLS 过程中自动执行吊销检查，不过如今许多浏览器依赖 OCSP 或专有的更新机制，而不是下载完整 CRL。在 Windows 上，certutil -dump crl.crl 可以显示 CRL 内容，双击 .crl 文件则会打开系统内置的查看器。如果你想在浏览器环境中信任一张证书之前先验证它，请参阅我们关于如何检查数字证书的指南。
CRL 与 OCSP：如何选择吊销检查方法
CRL 和 OCSP（在线证书状态协议，RFC 6960）回答的都是“这张证书被吊销了吗？”CRL 是拉取式的批量模型：客户端下载一份清单并在本地检索。OCSP 是查询式的实时模型：客户端向响应器询问某一张证书的状态，得到的回答为有效、已吊销或未知。
大多数现代浏览器偏向使用 OCSP（或 OCSP stapling）完成实时 Web 检查，而企业 PKI 团队在内部 CA 部署中往往依赖 CRL——因为那些环境不保证能访问 OCSP 响应器。两者是互补而非互斥的，许多客户端会同时使用。如果你在排查一个验证失败的签名，吊销检查方式是最先要核查的事项之一；我们关于数字签名为何无效的文章逐一分析了常见原因。
对于长期签名验证——即多年之后仍需证明签名在签署当时是有效的——吊销数据必须与签名一并归档。我们的如何确保数字签名的长期有效性（LTV）指南提供了该场景的 LTV 检查清单。
Nota Sign：当签署平台能感知证书状态时
手动执行一次 CRL 或 OCSP 检查，回答的只是某一时刻的问题。而在生产签署场景中，你真正需要的是一个把"证书状态感知"折叠进签署事件本身的平台——这样审计追踪记录的是签署当时证书的效力。Nota Sign——法大大（FaDaDa）旗下的全球电子签名平台——正是围绕这一思路构建的：每一份已签署文档都带有防篡改记录，与证书的有效性绑定。
它的市场成绩是公开的——IDC 中国电子签名市场排行中，Nota Sign 已连续多年位列第一。由于吊销与数据驻留义务因 CA 政策和法域而异，请先对照自身需求确认细节。方案按工作流计价，而不是看人数，签署量增长不会抬高账单。让 Nota Sign 带你走一遍生产环境下的 CRL/OCSP 检查——联系 Nota Sign 团队。
