apache 不支持 sslcarevocationfile 指令，因其从未存在于官方 mod_ssl 模块中；正确方式是使用 sslcarevocationpath 配合 c_rehash 工具，并仅在 sslverifyclient require 且配置 sslcacertificatefile 时生效。
Apache 不支持 SSLCARevocationFile 指令，配置它不会生效，也不会报错——只会静默忽略。
为什么 SSLCARevocationFile 在 Apache 中无效
该指令从未存在于官方 mod_ssl 模块中。你在文档、博客或旧配置里看到它，基本是以下情况之一：
- 误把 Nginx 的
ssl_crl或 IIS / Tomcat 的类似配置当成了 Apache 语法； - 引用了已废弃的第三方模块（如极早期的
mod_nss）； - 混淆了 Java 应用（如 Tomcat、HttpClient）中
certificateRevocationFile的用法——那和 Apache HTTP Server 完全无关。
Apache 官方文档、源码及所有稳定发行版（2.2/2.4）均无此指令。运行 apachectl -t -D DUMP_MODULES 或查 mod_ssl.c 源码可验证。
Apache 真正支持的 CRL 加载方式只有 SSLCARevocationPath
它要求：
- 路径下存放的是 PEM 格式的 CRL 文件；
- 必须经
c_rehash工具处理（生成哈希符号链接），不能直接放一个ca.crl文件； - CRL 文件名必须以
.crl结尾，且内容严格为 PEM 编码（-----BEGIN X509 CRL-----到-----END X509 CRL-----）； - 仅在启用客户端证书验证（
SSLVerifyClient require）且已配置SSLCACertificateFile时才触发检查。
示例配置片段：
SSLCACertificateFile /etc/ssl/certs/ca-bundle.crt SSLCARevocationPath /etc/ssl/crl/ SSLVerifyClient require
然后执行：c_rehash /etc/ssl/crl/ ——注意不是 c_rehash /etc/ssl/crl/ca.crl，后者会失败。
大规模 CRL 的实际问题与替代方案
即使正确配置 SSLCARevocationPath，对“大规模吊销列表”也几乎不可行：
- CRL 文件越大，OpenSSL 解析越慢，TLS 握手延迟显著上升（尤其在高并发场景）；
- CRL 更新不及时，CA 通常按小时/天发布新版本，存在窗口期；
- Apache 不支持增量 CRL（delta CRL），每次加载都是完整文件；
- 没有内置缓存机制，每次握手都重新读取并解析。
生产环境应优先启用 OCSP Stapling：
SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)
它由服务器主动向 CA 的 OCSP 响应器查询并缓存结果，不依赖本地 CRL 文件，响应快、实时性强、无分发负担。
如果合规审计硬性要求 CRL 检查，必须注意的关键点
这不是加一行配置就能解决的事：
- 确保 OpenSSL 版本 ≥ 1.0.2（推荐 1.1.1+），且编译时未禁用 CRL 支持；
-
SSLCARevocationCheck必须设为chain或leaf（默认是none），否则SSLCARevocationPath不起作用； - Apache 不会校验 CRL 签名有效性，依赖 OpenSSL 底层行为，而旧版 OpenSSL 默认跳过签名验证；
- 日志中几乎不输出 CRL 相关错误，调试只能靠 OpenSSL 错误码（如
SSL_R_CRL_VERIFY_FAILURE）和抓包看 handshake 是否中断。
真正落地时，CRL 路径权限、哈希一致性、OpenSSL 配置、mod_ssl 编译选项、甚至系统 ulimit 对文件描述符的限制，都可能让吊销检查在某个环节彻底失效——而你很难第一时间发现。
