证书吊销列表(CRL).

CRL 是由 CA 签名的文档,包含不应再被信任的证书序列号及其吊销日期,常见原因包括私钥泄露、主体信息变更或证书错误签发。其格式由 RFC 5280 定义:一个带有 thisUpdate/nextUpdate 时间戳以及逐条吊销原因码(如 keyCompromise、cessationOfOperation、affiliationChanged)的签名结构。依赖方从证书 CRLDistributionPoints 扩展所指定的 URL 下载 CRL,并拒绝任何序列号出现在其中的证书。

CRL 有两个结构性弱点:时效性和体积。由于客户端在 nextUpdate 之前一直信任已缓存的 CRL,在一个周期中途被吊销的证书仍可能被接受数小时甚至数天——这正是引入 OCSP(RFC 6960)和 OCSP 装订以获取近实时状态的原因。在大规模吊销事件中,体积问题尤为突出:Heartbleed(2014)之后,运营方大批重签并吊销证书,Cloudflare 报告称,发布由此产生的 CRL 使某家 CA 的带宽账单每月增加约 40 万美元。Mozilla 曾测得约 3000 份 CRL、总计约 300 MB,这正是浏览器转向聚合方案、而非逐连接下载的原因。

现代部署更倾向于压缩、推送式的吊销数据。Chrome 内置 CRLSets,Firefox 则启用了 CRLite——它将来自 Certificate Transparency 日志的全部 WebPKI 吊销信息编码为 Bloom filter 级联结构,每 12 小时刷新一次,并在本地私密查询——自 Firefox 137 起面向所有桌面用户。CA/Browser Forum 推动短期证书(到 2029 年将最长有效期压缩至 47 天)进一步降低了对吊销机制的依赖,因为一张很快就过期的证书几乎无需吊销。

flowchart TD
  A[私钥泄露 / 证书错误签发] --> B[CA 将序列号加入 CRL]
  B --> C[CA 用 thisUpdate / nextUpdate 签名 CRL]
  C --> D[发布到 CRLDistributionPoints URL]
  D --> E[TLS 客户端 / 浏览器下载 CRL]
  E --> F{序列号在列表中?}
  F -->|是| G[拒绝连接]
  F -->|否| H[接受 - 信任至 nextUpdate]
  C -.列表庞大, 缓存过期.-> I[OCSP stapling / CRLite / 短期证书]
  style G fill:#c0392b,color:#fff
  style H fill:#27ae60,color:#fff