必须启用sslproxyverify require，并配套sslproxyengine on、sslproxycacertificatefile、sslproxycheckpeername on和sslproxycheckpeerexpire on四指令，缺一不可；optional/none实为跳过校验，存在中间人攻击风险。
要让 Apache 在反向代理 HTTPS 后端时真正校验对方身份，必须启用 SSLProxyVerify require，并配套完成证书链信任、主机名匹配和有效期检查三要素。光写这一行指令几乎必然失败——它是个“开关”，但不提供信任根、不定义匹配规则、也不加载校验逻辑依赖。
必须配齐的四个核心指令
SSLProxyVerify require 单独存在毫无意义。它需要与以下三个指令协同工作，缺一不可：
- SSLProxyEngine on：开启 Apache 作为 HTTPS 客户端的能力。没它，连 TLS 握手都触发不了，后续所有校验都是空谈；
- SSLProxyCACertificateFile /path/to/ca-bundle.crt：明确指定可信 CA 根证书（不是你自己的服务证书！）。若后端用的是企业私有 CA 或自签名证书，系统默认信任库（如 /etc/ssl/certs/ca-certificates.crt）不会自动生效；
- SSLProxyCheckPeerName on：强制校验后端证书中的 Subject Alternative Name（SAN），而非已废弃的 CN 字段。例如 ProxyPass /api https://order.internal/，则后端证书必须包含 DNS:order.internal；
- SSLProxyCheckPeerExpire on：检查证书是否过期。时间偏差超过 5 分钟就会拒绝连接，且错误日志往往只显示 “SSL handshake failed”，需特别注意服务器时钟同步。
为什么 SSLProxyVerify optional 或 none 不等于“弱一点”
optional 和 none 都代表跳过完整校验链：它们不验证证书签名是否由可信 CA 签发、不检查吊销状态（CRL/OCSP）、不比对 SAN 域名、也不校验有效期。换句话说，只要证书格式合法、能解析出来，就放行。这等同于裸连 HTTPS 服务，中间人可伪造任意证书冒充后端，完全丧失身份管控能力。
require 是唯一能实现强认证的选项——它要求证书链可向上追溯至你指定的 CA、域名精确匹配、未过期、且签名有效。生产环境必须用它。
常见报错及快速定位方法
启用 require 后出现 500 或连接重置，大概率是以下三类问题：
-
CA 文件路径错误或权限不足：Apache 进程用户（如 www-data）读不到 SSLProxyCACertificateFile 指定的文件。用
sudo -u www-data cat /path/to/ca.crt测试可读性，同时检查 SELinux 上下文（RHEL/CentOS）； -
后端证书 SAN 缺失或不匹配：用
openssl x509 -in backend.crt -text -noout | grep -A1 "Subject Alternative Name"查看实际 SAN 内容，确保与 ProxyPass 目标域名完全一致； -
握手失败但日志信息模糊：用
openssl s_client -connect svc.internal:443 -CAfile /path/to/ca.crt模拟 Apache 行为，它会明确提示 “verify error:num=20:unable to get local issuer certificate” 或 “verify error:num=62:Hostname mismatch”，比 Apache 日志直观得多。
不推荐跳过的安全强化项
在 require 基础上，建议补充：
- SSLProxyVerifyDepth 2：限制证书链验证深度，防环形引用或恶意超长链；
- SSLProxyCheckPeerCN off：显式关闭已废弃的 CN 校验，避免配置残留干扰；
- ProxyPreserveHost on：确保后端收到原始 Host 头，便于日志追踪和路由识别；
- 若后端要求客户端证书，则额外配置 SSLProxyMachineCertificateFile 和密钥，实现双向 TLS。
