Apache 不支持 SSLCARevocationCheck 指令，该名称是混淆产物；实际 OCSP 校验由 OpenSSL 自动完成，Apache 仅通过 SSLUseStapling、SSLCertificateChainFile 和 SSLStaplingCache 三个配置项间接影响其生效。
Apache 没有 SSLCARevocationCheck 这个指令，它根本不存在 —— 所有试图在 ssl.conf 或虚拟主机里写这行配置的操作都会被 apachectl configtest 报错或静默忽略。
为什么搜到的“SSLCARevocationCheck”全是误导
这个名称是典型混淆产物：它混搭了 OpenSSL 的 X509_V_FLAG_CRL_CHECK 标志、Nginx 的 ssl_stapling_verify on 语义，以及对 Apache mod_ssl 文档的误读。Apache 官方 Directive Index（截至 2026 年 4 月）中查不到该指令，mod_ssl 源码里也无对应实现。
真实情况是：mod_ssl 不提供直接开关来“开启 OCSP 实时校验”，它只通过 SSLUseStapling 机制接收并转发 OCSP 响应；而是否验证该响应签名、是否拒绝未通过验证的响应，由底层 OpenSSL 行为决定，且 Apache 未暴露控制接口。
OCSP 响应验证实际由 OpenSSL 控制，但 Apache 不让你配
OpenSSL 在收到 OCSP 响应后，会自动用签发该响应的 OCSP 签名证书（通常是 CA 的专用 OCSP responder 证书）验证签名。这个过程默认启用，无法关闭 —— 但前提是：
-
SSLCertificateChainFile必须包含完整的中间证书链（不含根证书），否则 OpenSSL 找不到用于验证 OCSP 响应签名的公钥 - OCSP 签名证书本身必须在信任链中可回溯至
SSLCACertificateFile中的某个 CA（否则验证失败，Apache 就不 stapling） - 若 OCSP 响应签名无效、过期或使用了不被信任的算法，OpenSSL 会丢弃该响应，
openssl s_client -status将显示OCSP response: no response sent，而非报错
真正能影响 OCSP 校验行为的 Apache 配置项只有三个
它们不叫 “revocation check”，但共同决定了 OCSP 是否生效、是否可信：
-
SSLUseStapling on：启用 stapling，但单独这一行毫无作用 -
SSLCertificateChainFile /path/to/fullchain.pem：缺失或错误会导致 OCSP 响应签名验证失败，stapling 直接失效 -
SSLStaplingCache "shmcb:/var/run/apache2/stapling-cache(128000)"：缓存位置必须可写，否则首次获取 OCSP 响应后无法存储，后续请求全走网络重查（易超时）
注意：SSLUseStaplingWhenClientProvidesBuffer on 在 Apache ≥ 2.4.37 是硬性要求，否则现代客户端（尤其是 TLS 1.3）协商时不会发送 OCSP 扩展，服务器连尝试 stapling 的机会都没有。
验证你是不是真在用 OCSP 校验，别信配置文件
运行这条命令，看输出里有没有可信的响应体：
openssl s_client -connect example.com:443 -status -servername example.com 2>&1 | grep -A 10 "OCSP response"
关键信号不是“OCSP response:”那行，而是后面紧跟着的 Response verify OK 和 Base64 编码块。如果只有 OCSP response: no response sent，说明 stapling 没建立成功，十有八九是 SSLCertificateChainFile 不对或 SSLStaplingCache 路径不可写。
最容易被忽略的一点：Apache 不会把 OCSP 验证失败记为 error 日志，默认只记 warning；得打开 LogLevel ssl:trace6 才能看到 OpenSSL 底层拒绝响应的具体原因，比如 verify error:num=10:certificate has expired 或 unable to get certificate CRL —— 后者其实和 OCSP 无关，是 CRL 逻辑残留日志，别被带偏。
