OpenSSL中-crl_download与-CRLFile验证CRL结果不同的问题排查

这个问题我之前也碰到过类似情况，结合你用的OpenSSL 1.0.2g版本，咱们一步步拆解原因：

核心差异：-CRLfile vs -crl_download #

首先得明确这两个参数的本质区别：

• -CRLfile：直接让OpenSSL读取你指定的本地CRL文件，跳过了「下载CRL」和「定位CRL地址」的环节，只要文件本身合法，就能正常完成验证。
• -crl_download：让OpenSSL自动从证书内置的CRL分发点（CDP）地址下载CRL，这个过程涉及三个关键环节：证书是否配置了正确的CDP、下载过程是否顺畅、下载后的CRL能否被OpenSSL正确识别。

可能的原因及排查步骤 #

1. 中级证书未配置正确的CRL分发点（CDP） #

这是最常见的原因！OpenSSL使用-crl_download时，必须从证书的X509扩展里找到CRL的下载地址，否则它根本不知道该去哪里下载。

你可以用这条命令检查证书的CDP配置：

openssl x509 -in interm1.crt -noout -text | grep -A 5 "CRL Distribution Points"

如果输出里没有这个字段，或者URI不是http://127.0.0.1:8080/file.crl，那问题就出在这——你需要重新签发中级证书，在配置文件里添加CRL分发点扩展，比如：

[ v3_intermediate_ca ]
...
crlDistributionPoints = URI:http://127.0.0.1:8080/file.crl

2. Nginx返回的CRL文件MIME类型不符合要求 #

虽然wget能正常下载CRL，但OpenSSL对HTTP响应的Content-Type有严格要求。如果Nginx默认返回的是text/plain或其他类型，OpenSSL可能会拒绝解析这个CRL。

你可以用curl检查响应头：

curl -I http://127.0.0.1:8080/file.crl

如果Content-Type不是application/pkix-crl或application/x-pkcs7-crl，就需要在Nginx的location配置里添加：

location /file.crl {
    add_header Content-Type application/pkix-crl;
    # 保留你原有的其他配置
}

3. OpenSSL 1.0.2g的旧版本bug #

1.0.2g是2016年的老版本，后续的1.0.2补丁版本修复了不少CRL下载相关的问题，比如：

• 对HTTP重定向的支持不足（如果你的Nginx有重定向规则，OpenSSL可能不会自动跟随）
• 对本地回环地址的CRL下载有特殊限制
• CRL解析时的兼容性问题

你可以先测试直接下载并解析CRL：

openssl crl -in <(curl -s http://127.0.0.1:8080/file.crl) -noout -text

如果这个命令报错，那大概率是版本bug导致的，建议升级到1.0.2的最新补丁版本（比如1.0.2zh），或者直接迁移到1.1.1系列（长期支持版本）。

4. 网络/权限的小概率问题 #

虽然wget能下载，但OpenSSL进程的网络权限可能和你当前用户不同？比如用root运行Docker，但OpenSSL以普通用户身份运行？不过这个可能性很低，你可以试试用root用户运行OpenSSL验证命令，排除权限问题。

总结 #

按优先级排查的话：

1. 先检查证书的CDP配置是否正确
2. 再检查Nginx的Content-Type设置
3. 最后考虑升级OpenSSL版本

内容的提问来源于stack exchange，提问作者René Heuven