如何在Nginx中利用Proxy-Ssl-Verify验证后端微服务的证书合法性-linux运维-PHP中文网

proxy_ssl_verify 是 nginx 作为反向代理连接上游 https 服务时，校验该上游服务器返回的 tls 证书合法性的开关；它不验证客户端证书，也不影响 nginx 自身对外提供的证书，必须配合 proxy_ssl_trusted_certificate 等指令协同生效，否则静默降级。

如何在nginx中利用proxy-ssl-verify验证后端微服务的证书合法性

nginx proxy_ssl_verify 是什么，它到底验证谁的证书

proxy_ssl_verify 控制的是 Nginx 作为反向代理时，**主动连接上游（upstream）HTTPS 服务时**，是否校验该上游服务器返回的 TLS 证书。它不验证客户端传来的证书，也不影响 Nginx 自己对外提供的 HTTPS 证书。

常见误解是以为它能用来做“客户端证书透传校验”，其实不是——那是 ssl_client_certificate + ssl_verify_client 的事。这里只管“Nginx 去连后端微服务”这一跳的安全性。

必须搭配 proxy_ssl_trusted_certificate 使用，否则即使设为 on 也无效（Nginx 会静默降级）
若后端用的是自签名证书或私有 CA 签发的证书，proxy_ssl_trusted_certificate 必须包含对应根证书（PEM 格式）
默认值是 off，不显式开启就等于完全不校验，哪怕后端证书已过期、域名不匹配、链不完整，Nginx 都照转不误

启用验证的关键配置项和顺序不能错

这组指令必须出现在 location 或 upstream 块内，且依赖关系明确：先指定可信 CA，再开启校验，最后可选控制严格程度。

典型安全配置如下：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

location /api/ {
    proxy_pass https://backend-svc;
    proxy_ssl_verify on;
    proxy_ssl_trusted_certificate /etc/nginx/certs/internal-ca.pem;
    proxy_ssl_verify_depth 2;
    proxy_ssl_session_reuse off;
}

proxy_ssl_trusted_certificate 路径必须可读，且内容是 PEM 格式根证书（支持多个拼在一起），不能是证书链中间件或终端实体证书
proxy_ssl_verify_depth 指证书链最大验证深度，默认 1；若后端用的是二级中间 CA 签发的证书，就得设为 2，否则校验失败
proxy_ssl_session_reuse off 建议关闭——开启时可能复用旧 session，绕过证书重校验，导致异常证书被缓存生效
所有 proxy_ssl_* 指令在 HTTP 块中全局设置无效，必须在具体转发上下文中声明

验证失败时 Nginx 怎么报错？怎么快速定位问题

失败不会返回 502 Bad Gateway 这类通用错误，而是直接抛出 SSL_do_handshake() failed 类似日志，并伴随具体原因，比如：

SSL certificate verify error: unable to get local issuer certificate → proxy_ssl_trusted_certificate 缺少对应根证书
SSL certificate verify error: certificate has expired → 后端证书过期，或系统时间不同步（注意：Nginx 不自动同步时间，宿主机时间不准会导致误判）
SSL certificate verify error: certificate is not yet valid → 后端证书未生效，或 Nginx 所在机器时间快于实际时间
SSL certificate verify error: hostname mismatch → 后端证书里的 Subject Alternative Name 不含 proxy_pass 中写的域名/IP（例如你写 https://10.1.2.3，但证书只签了 svc.cluster.local）

调试时务必打开 error_log /var/log/nginx/error.log debug;，否则这些细节全被吞掉。

微服务场景下容易被忽略的三个硬伤

在 Kubernetes 或 Service Mesh 环境中，直接套用文档默认配置大概率踩坑：

后端是 Pod IP 直连（如 https://10.244.1.5:8443），但证书通常只签了 service name 或 pod FQDN，IP 不在 SAN 里 → 解决方法：要么重签含 IP 的证书，要么改用 DNS 名（如 https://my-svc.namespace.svc.cluster.local）并确保 resolver 可用
使用 cert-manager 自动生成证书，但没把 CA Bundle 注入到 Nginx 容器的 /etc/nginx/certs/ 下，或者挂载路径权限不对（Nginx worker 是非 root 用户，需确保文件 world-readable）
启用了 proxy_ssl_server_name on 却没配 SNI，导致某些 gRPC 或 Istio sidecar 拒绝握手 → 实际上多数内部微服务不需要 SNI，除非你明确知道后端依赖它，否则别开

最麻烦的一点是：验证失败日志只打在 error log，access log 里完全看不出异样，请求看起来只是“慢”或“超时”，容易误判成网络或后端性能问题。