如何调整proxy_ssl_verify_depth深度以优化后端负载均衡节点信任链校验？

本文共计741个文字，预计阅读时间需要3分钟。

为了让+Nginx在反向代理场景中正确校验，请确保以下配置：

理解 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 不会生效，以下四者缺一不可：

• 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 中已包含该自签根证书