Nginx反向代理校验后端HTTPS证书链需同时配置proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name on，且proxy_ssl_verify_depth应设为2（适配主流CA两级链），缺一不可。
要让 Nginx 在反向代理场景中正确校验后端负载均衡节点的 HTTPS 证书链，proxy_ssl_verify_depth 是关键一环——它不是单独起作用的开关，而是和证书链完整性、SNI 声明、验证开关共同构成信任锚点的校验深度阈值。
理解 depth 的真实含义
该值表示 Nginx 允许向上追溯的中间 CA 数量上限，不包含终端证书本身。例如：
- 设为 1：只接受“终端证书 → 根 CA”结构（无中间 CA）
- 设为 2：允许“终端证书 → 中间 CA → 根 CA”，这是 Let’s Encrypt R3、DigiCert TLS EA 等主流证书的典型结构
- 设为 3：适用于企业私有 PKI 中存在两级中间 CA 的场景（如终端 → 部门签发 CA → 企业根 CA）
必须同步配置的四项指令
仅调大 proxy_ssl_verify_depth 不会生效，以下四者缺一不可：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- proxy_ssl_verify on; —— 明确启用上游证书校验（默认是 off）
- proxy_ssl_trusted_certificate /path/to/ca-bundle.pem; —— 指向含完整信任链的 PEM 文件，必须同时包含所有中间 CA 和根 CA（不能只放根）
-
proxy_ssl_name "backend.example.com"; —— 显式声明期望的 SNI 主机名，用于匹配证书中的 SAN 字段；若
proxy_pass使用 IP 或变量，此项必填 - proxy_ssl_server_name on; —— 启用 TLS SNI 扩展，确保握手时向后端发送正确域名，避免返回默认证书
常见故障与定位方法
启用后出现 502 或日志报 certificate verify failed，优先检查：
- 后端是否只返回终端证书？需确认其 HTTPS 服务配置了完整证书链（如 Nginx 的
ssl_certificate文件应含终端 + 中间证书） -
proxy_ssl_trusted_certificate文件是否遗漏某一级中间 CA？可用openssl crl2pkcs7 -nocrl -certfile ca-bundle.pem | openssl pkcs7 -print_certs -noout查看所含证书数量与层级 -
proxy_ssl_name是否与后端证书中任一 SAN 域名完全一致？大小写、通配符（*.api.example.com）、IP 地址都需匹配 - 是否在 reload 后用
openssl s_client -connect backend-ip:443 -servername backend.example.com -showcerts手动抓取并验证实际返回的证书链长度？
安全与兼容的平衡建议
不建议盲目设高，也不宜卡死过低：
- 生产环境推荐从 2 起步，多数云厂商与公共 CA 证书链为两级
- 确认为三级链再升至 3，避免因误配导致 502
- 超过 4 属于过度放宽，可能引入不可控中间签发者，且 OpenSSL 默认最大深度为 100，恶意构造长链可成为 DoS 攻击面
- 自签名或单层内网证书可维持 1，但务必确保
proxy_ssl_trusted_certificate中已包含该自签根证书
