apache作为https反向代理时,必须启用sslproxyverify require并配置正确的ca信任库和严格匹配的san证书,否则将因校验失败导致ssl握手错误。

Apache 作为 HTTPS 反向代理时,若后端服务用 HTTPS,Apache 就是“客户端”——它必须验证后端证书是否可信。报错如 SSL handshake failed、500 Internal Server Error 或日志里出现 SSLProxy: peer certificate not verified,基本都指向这一环节,而非前端浏览器看到的证书问题。
重点不是配好自己的 SSL,而是让 Apache 正确校验上游
必须启用并配置 SSLProxyVerify require
默认 SSLProxyVerify 是 none,即完全跳过校验,风险极高。生产环境必须设为 require,否则无法防止中间人攻击。
- 在
<virtualhost></virtualhost>或<proxy></proxy>块中明确写:SSLProxyVerify require SSLProxyCheckPeerName on SSLProxyCheckPeerExpire on SSLProxyCheckPeerCN off # 不依赖已废弃的 CN 字段,只认 SAN
-
SSLProxyVerify optional或optional_no_ca等同于没开校验,不能用。
指定正确的上游 CA 信任库
Apache 不会自动读系统 CA 包(如 /etc/ssl/certs/ca-certificates.crt),必须显式指定:
- 使用
SSLProxyCACertificateFile指向一个 PEM 文件,里面只放后端证书所依赖的根证书 + 中间证书(不能含私钥、不能含终端证书); - 文件权限设为
644,确保 Apache 工作进程(如www-data)可读; - 若后端用 Let’s Encrypt,可用其 R3 和 ISRG Root X1;若为内网服务,必须提供对应私有 CA 的根证书。
验证命令:
openssl x509 -in /path/to/upstream-ca.crt -text -noout | grep "Subject:"
输出应包含你期望的 CA 名称。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
确保后端证书 SAN 与 ProxyPass 目标完全匹配
SSLProxyCheckPeerName on 要求:后端证书的 Subject Alternative Name(SAN)中,至少有一项 严格等于 ProxyPass 指令里的主机名。
例如:
ProxyPass /api https://svc.internal/
则后端证书必须包含 DNS:svc.internal —— svc.internal.(带尾点)、SVCS.INTERNAL(大小写不一致)、*.internal(通配符不匹配)都不行。
检查方式:
openssl s_client -connect svc.internal:443 -servername svc.internal 2>/dev/null | openssl x509 -text -noout | grep -A1 "Subject Alternative Name"
排查常见失败原因
- 后端服务时间偏差超过 5 分钟 →
SSLProxyCheckPeerExpire on会直接拒绝,且错误不直观; -
SSLProxyCACertificateFile路径错误、文件为空、或 Apache 进程无读取权限(尤其注意 SELinux 上下文); - 后端未返回完整证书链(只发了终端证书,缺中间证书)→ Apache 校验失败;
- 用了变量拼接
ProxyPass(如https://${BACKEND_HOST}/),但SSLProxyCheckPeerName无法动态解析,需配合SSLProxyServerName on和SSLProxyName显式指定。
不复杂但容易忽略










