CRL（Certificate Revocation List，证书吊销列表）是 CA（证书颁发机构） 定期发布并签名的已吊销证书序列号列表，用于判断某张 数字证书 是否不应再被信任。
核心问题
证书可能在过期前就需要失效，例如私钥泄露、员工离职、设备报废、域名控制权变化或误签。CRL 让客户端可以下载一份由 CA 签名的列表，在本地检查证书序列号是否已被吊销。
核心机制
CRL 通常包含：
| 字段 | 作用 |
|---|---|
| issuer | 发布这份 CRL 的 CA |
| thisUpdate | 本次列表发布时间 |
| nextUpdate | 下次预期更新时间 |
| revoked certificates | 已吊销证书序列号、吊销时间和原因 |
| signature | CA 或授权 CRL 签发者对列表的签名 |
验证逻辑可以写成：
verify_signature(crl, issuer_public_key)
require now between crl.thisUpdate and crl.nextUpdate
reject if certificate.serial in crl.revoked_certificatesCRL 是批量发布模型。客户端拿到列表后可以离线检查，但列表可能很大，而且状态新鲜度取决于发布周期和缓存策略。
工程用途
- 企业内网、离线环境或设备侧批量检查吊销状态。
- TLS、VPN、Wi-Fi、mTLS 等证书体系的撤销机制之一。
- 合规审计中保留吊销原因、时间和发布记录。
- 与 OCSP 互补：CRL 适合批量和离线，OCSP 适合单证书在线查询。
边界与常见坑
- CRL 不是实时状态：发布周期越长，吊销生效延迟越大。
- 列表过大影响性能：大型 CA 的 CRL 可能很大，需要缓存和增量策略。
- 过期 CRL 不能继续信任：
nextUpdate已过时意味着吊销状态不新鲜。 - 必须验证 CRL 签名：否则攻击者可以伪造“空吊销列表”。
- 吊销检查失败如何处理是安全策略：软失败提高可用性但降低吊销效果，硬失败更安全但可能造成中断。