CRL 机制详解：工作原理、结构字段与分发点

好，咱们接着聊证书吊销。上一章我讲了为什么要吊销证书，这一章咱们深入看看 CRL——证书吊销列表。说白了，CRL 就是 CA 签发的一张「黑名单」。这张名单上记录了所有被吊销的证书序列号，以及吊销的原因和时间。

我在项目里见过不少团队，证书配了一大堆，CRL 却从来没配过。结果设备被入侵后，攻击者拿着旧证书照样畅通无阻。嗯，这章咱们就把 CRL 彻底讲透。

CRL 的工作原理

CRL 的工作流程其实不复杂，我画个图你就明白了。

流程其实就五步：

1. CA 签发证书——证书正常使用中
2. 设备被入侵或私钥泄露——触发吊销条件
3. 管理员提交吊销请求——向 CA 报告该证书作废
4. CA 签发 CRL——将证书序列号加入黑名单，并签名发布
5. 依赖方下载 CRL 并验证——浏览器、服务器等客户端定期拉取 CRL，检查证书是否在名单上

这里有个关键点：CRL 是由 CA 签名的。也就是说，任何人都可以下载 CRL，但只有 CA 才能签发它。篡改 CRL 会导致签名验证失败，客户端会直接拒绝信任。

CRL 结构字段解析

CRL 的结构在 X.509 标准里有明确定义。咱们直接看一个典型的 CRL 数据格式：

CertificateList  ::=  SEQUENCE  {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}

TBSCertList  ::=  SEQUENCE  {
    version                 Version OPTIONAL,
    signature               AlgorithmIdentifier,
    issuer                  Name,
    thisUpdate              Time,
    nextUpdate              Time,
    revokedCertificates     SEQUENCE OF SEQUENCE  {
        userCertificate         CertificateSerialNumber,
        revocationDate          Time,
        crlEntryExtensions      Extensions OPTIONAL
    } OPTIONAL,
    crlExtensions           [0]  Extensions OPTIONAL
}

看着有点晕？别急，我拆开讲。核心字段就这几个：

字段	说明	我的备注
version	CRL 版本号，目前主流是 v2	v1 不支持扩展字段，建议用 v2
issuer	签发该 CRL 的 CA 名称	必须与证书中的签发者一致
thisUpdate	本次 CRL 的签发时间	精确到秒，用于判断时效
nextUpdate	下次 CRL 更新的时间	客户端在这个时间之前必须重新下载
revokedCertificates	被吊销证书的列表	包含序列号、吊销时间、原因
signatureValue	CA 对 CRL 的数字签名	防篡改的关键

这里我要特别强调 revokedCertificates 里的吊销原因字段。RFC 5280 定义了以下原因码：

• unspecified (0)——未指定原因，能不用就别用
• keyCompromise (1)——私钥泄露，最常见的原因
• cACompromise (2)——CA 私钥泄露，这是大事
• affiliationChanged (3)——用户离职或组织变更
• superseded (4)——证书被新证书替代
• cessationOfOperation (5)——业务停止，证书不再需要
• certificateHold (6)——临时挂起，可以恢复

CRL 分发点（CDP）

CDP 的全称是 CRL Distribution Point。说白了，它就是告诉客户端「你去哪里下载 CRL」。这个信息是写在证书扩展字段里的。

咱们用 OpenSSL 看看一个典型证书的 CDP 信息：

openssl x509 -in cert.pem -text -noout | grep -A 3 "CRL Distribution Points"

    X509v3 CRL Distribution Points:
        Full Name:
          URI:http://crl.example.com/intermediate.crl
          URI:ldap://ldap.example.com/cn=IntermediateCA,dc=example,dc=com?certificateRevocationList

看到没？CDP 可以配置多个 URI。客户端会依次尝试，直到下载成功。常见的 URI 协议有：

• HTTP/HTTPS——最常用，简单直接
• LDAP——适合企业内网环境
• file://——本地文件，测试时用

CDP 的设计有几个关键考量：

1. 冗余性——至少配两个 CDP，一个挂了还有备用
2. 就近访问——CDP 服务器最好靠近客户端，减少延迟
3. 安全性——能用 HTTPS 就别用 HTTP，防止中间人篡改

CRL 的局限性

说实话，CRL 机制并不完美。我在实际项目中踩过不少坑：

• 实时性差——CRL 是定期签发的，不是实时更新。从证书被吊销到 CRL 发布，中间有个时间窗口
• 体积膨胀——吊销的证书多了，CRL 文件会越来越大。我见过一个 CRL 超过 100MB，客户端下载都超时
• 下载延迟——客户端每次验证都要下载 CRL，网络不好的时候体验很差

针对这些问题，业界后来推出了 OCSP（在线证书状态协议），这个咱们后面章节会详细讲。但 CRL 作为基础机制，至今仍是 PKI 体系的标配。

小结