3. CRL 分发失败现象分类
做 PKI 运维这几年，我见过太多 CRL 分发失败的案例了。
说句实话，问题表象五花八门，但根因往往就那么几类。
我个人习惯是，先分类，再定位。这就好比医生看病，先分内科外科，再开检查单。
这一章，我就带你把这些“症状”梳理清楚。
3.1 总体分类框架
CRL 分发失败，从整个链路来看，本质上是“发布-获取”这个闭环断了。
我把它归纳为四大类，你看完这张图就能有个全局印象。
从图上你可以看到，我把问题分成了两大层面：
- 上游（CA/服务端侧）：CRL 根本没生成，或者生成后发布脚本出问题。
- 下游（客户端/传输侧）：CRL 确实生成了，但客户端拿不到，或者拿到的是错的。
下面我逐个拆解，说说每种现象的特征、原因和我的排查思路。
3.2 服务端未生成 CRL
这是最“冤”的一种情况。说白了，就是源头没水。
客户端那边抓耳挠腮地请求，但 CA 根本没签发新 CRL。
为什么会这样？我遇到过的原因主要有这么几个：
- CA 服务异常：比如证书服务进程卡死、数据库连接失败。我记得有一次，客户反馈所有客户端都报“证书吊销状态未知”，查了一圈，最后发现是 CA 所在的 Windows Server 把“证书服务”这个服务给停了。
- CRL 有效期策略配置不当：有的 CA 配置了“CRL 仅在特定条件触发时生成”，比如吊销新证书时才生成。如果一段时间内没人吊销证书，CRL 就一直是旧的，直到过期。
- 定时任务（cron job）失效：很多企业用脚本或计划任务定时触发 CRL 生成。如果这个脚本执行失败，或者主机时间被篡改，CRL 就停更了。
3.3 网络超时
这一大类，严格来说属于“传输层”问题。CRL 文件好好的在服务器上，但客户端就是拉不下来。
你想想看，一个 CRL 文件的大小可能只有几 KB 到几十 KB，按理说传输非常快。但一旦涉及跨网络、跨机房、甚至跨公网，问题就来了。
| 子现象 | 可能原因 | 排查方向 |
|---|---|---|
| HTTP/HTTPS 下载超时 | CDN 回源失败、源站带宽打满、防火墙拦截 .crl 后缀 | 检查 CDN 日志、源站带宽监控、防火墙规则 |
| LDAP 连接超时 | 域名解析失败、LDAP 端口(389/636)被屏蔽、AD 服务器负载过高 | nslookup 验证域名、telnet 测试端口、检查 AD 健康状态 |
| SCP/FTP 传输超时 | 认证凭据失效、SFTP 服务未启动、磁盘空间不足 | 检查传输日志、验证账户权限、df -h 查看磁盘 |
我曾经排查过一个案例：客户端从阿里云上的 CA 下载 CRL，时好时坏。最后发现是某个 CDN 节点缓存了过期的 CRL 文件，而且没有正确处理 Cache-Control: no-cache 头。客户端每次请求都命中同一个坏缓存，导致永远拿不到最新 CRL。
3.4 客户端无法获取 CRL（非网络原因）
这类问题，网络是通的，但客户端行为或配置导致它拿不到。
- HTTPS 证书验证失败：如果 CRL 分发点用的是 HTTPS，而客户端不信任该站点的证书（比如自签名证书），就会直接拒绝下载。
- LDAP 绑定失败：客户端尝试通过 LDAP 协议绑定到 AD 获取 CRL，但提供的凭据没有权限，或者客户端机器未加入域。
- 客户端缓存策略问题：比如 Windows 系统会缓存 CRL，如果缓存未过期，它根本不会去 CDP 地址拉新的。这不算“失败”，但会导致实际生效的 CRL 比最新版本晚了一个缓存周期。
3.5 CDP（CRL Distribution Point）配置错误
这属于“配置即代码”的范畴，也是我建议所有运维同学重点关注的地方。
CDP 配置写在 CA 的证书里或者 CA 的策略里，它告诉客户端“去哪儿下载 CRL”。如果这个地址写错了，那一切都白搭。
| 配置错误类型 | 举例 | 影响 |
|---|---|---|
| URL 包含死地址 | http://old-ca-server/crl.crl 但该服务器已下线 |
客户端尝试连接旧地址超时，影响获取 |
| LDAP DN 路径错误 | ldap:///CN=CRL...?base?objectClass=cRLDistributionPoint 拼写错误 |
LDAP 查询无结果 |
| 多级 CA 的 CDP 不一致 | 根 CA 的 CDP 指向子 CA 的地址，但子 CA 未在该地址发布 CRL | 证书链验证失败 |
这类问题，我个人建议用 openssl 命令直接查看证书里的 CDP 扩展字段，一目了然。
# 从服务器证书中提取 CDP 信息
openssl x509 -in server.crt -text -noout | grep -A 5 "CRL Distribution Points"
# 测试 CDP 地址是否可达
curl -v -o /dev/null http://crl.example.com/intermediate.crl我记得有一次帮客户排查，发现他们二级 CA 的 CDP 里写的是 HTTP，但实际发布点只有 HTTPS。客户端尝试 HTTP 连接，被防火墙阻断，直接导致所有客户端无法 CRL 检查。
3.6 实战分类口诀
为了让你好记，我总结了一个口诀，排查时可以直接对号入座：
日志无痕是未生，文件不动问配置。
网络通畅还报错，八成 CDP 写错路。
时区不对也是坑，NTP 同步要靠谱。
说白了，大多数 CRL 分发失败，都逃不出这四大类。下次你再遇到这类告警，别慌。先问自己三个问题：
- CRL 文件是否真的生成了？（服务端视角）
- 我是否能手动下载/获取到这个 CRL？（传输层视角）
- 客户端配置的 CDP 地址，和我实际发布地址是否一致？（配置视角）
把这三个问题回答清楚了，90% 的问题都能定位。剩下的 10%，可能就需要深入抓包分析协议交互了，那部分我们会在后面的章节单独聊。