CRL 分发机制：CDP 原理与多级架构

CRL 能不能用，关键看你能不能拿到它。拿不到，证书验证就卡住了。这一章我们聊聊 CRL 分发点（CDP）——说白了，就是告诉客户端“你去哪儿下载 CRL”。

CDP 在证书中的扩展

每个 X.509 证书里都有一个叫 CRL Distribution Points 的扩展。我刚开始接触 PKI 时，总觉得这玩意儿就是个 URL 列表。后来踩了坑才明白，它其实是个结构体，能表达多个分发点、不同原因、甚至分片。

看一个典型的 CDP 扩展内容：

CRL Distribution Points:
  Point 1:
    Distribution Point Name:
      Full Name:
        URL=http://crl.example.com/ca1.crl
        URL=ldap://ldap.example.com/cn=CA1,o=Example?certificateRevocationList
    Reasons: keyCompromise, CACompromise
    CRL Issuer: <empty>
  Point 2:
    Distribution Point Name:
      Full Name:
        URL=http://crl2.example.com/ca1.crl
    Reasons: all
    CRL Issuer: <empty>

这里有几个关键字段：

• Distribution Point Name：分发点名称，通常是一个 URL 列表
• Reasons：这个分发点负责的吊销原因。比如只处理密钥泄露，不处理其他
• CRL Issuer：如果为空，默认就是证书签发者自己签发 CRL

多级 CRL 分发架构

单点分发 CRL 在小规模场景下没问题。但一旦 CA 签发了几十万张证书，单点下载一个几十 MB 的 CRL 就太慢了。这时候就需要多级架构。

我参与过一个金融项目，CA 签发了超过 200 万张证书。最初的单点 CRL 文件超过 80MB，客户端下载一次要十几秒，验证交易时经常超时。后来我们改成了多级分发架构，问题才解决。

多级架构的核心思路：

1. 根 CA 只签发基础 CRL，不直接面向终端
2. 中间 CA 签发增量 CRL，只包含最近变更
3. 分发节点做缓存和负载均衡，客户端就近获取

下面这张图展示了典型的多级 CRL 分发架构：

CDP 的部署策略

部署 CDP 时，有几个点我建议你特别注意：

CDP 的缓存策略

CRL 文件本身有有效期（nextUpdate 字段），但客户端不一定每次都去下载。你想想看，如果每个 HTTPS 连接都去下载一次 CRL，那性能就完蛋了。

客户端通常的做法：

• 缓存 CRL 到本地，直到 nextUpdate 过期
• 增量 CRL：只下载变更部分，减少带宽
• 预取：在 CRL 过期前主动刷新缓存

我建议你在 CDP 响应头里加上 Cache-Control 和 Expires，让中间缓存设备也能帮忙分担压力：

Cache-Control: public, max-age=3600
Expires: Thu, 01 Dec 2025 16:00:00 GMT

这样 CDN 或反向代理就能缓存 CRL 文件一小时，减少源站压力。