作为网络安全从业人员，我经常遇到企业使用NGINX作为反向代理时出现的HTTPS证书错误问题。这些错误不仅影响网站可用性，还可能带来安全隐患。本文将深入浅出地解析NGINX代理中常见的HTTPS证书错误，手把手教你如何排查和修复。

一、NGINX代理HTTPS的基本工作原理

在解决问题前，我们需要先理解NGINX处理HTTPS的基本流程。当NGINX作为反向代理时，它实际上扮演着"中间人"的角色：

1. 客户端与NGINX之间：建立TLS加密连接（使用NGINX的证书）

2. NGENIX与后端服务器之间：可以加密（HTTPS）也可以不加密（HTTP）

```

客户端 ──(HTTPS)──> NGINX ──(HTTP/HTTPS)──> 后端服务器

这种架构下容易出现两类证书问题：NGINX自身的证书问题和后端服务的证书验证问题。

二、常见证书错误及解决方案

1. SSL证书链不完整（"SSL certificate problem: unable to get local issuer certificate"）

错误现象：

- 浏览器显示"此网站的安全证书不受信任"

- curl请求返回"SSL certificate problem: unable to get local issuer certificate"

原因分析：

这通常是因为服务器没有发送完整的证书链。想象一下就像寄快递只寄了包裹没附带运单号 - 快递公司无法验证包裹来源。

解决方案：

确保nginx配置中包含完整的证书链：

```nginx

server {

listen 443 ssl;

ssl_certificate /path/to/fullchain.pem;

包含服务器证书+中间CA

ssl_certificate_key /path/to/privkey.pem;

...

}

*实操技巧*：

使用`openssl s_client -connect example.com:443 -showcerts`命令检查接收到的证书链是否完整。

2. 主机名不匹配（"SSL: no alternative certificate subject name matches target host name"）

- "此网站的安全证书是为其他地址颁发的"

- curl报错："does not match the host name"

典型案例：

假设你配置了：

server_name api.example.com;

proxy_pass https://backend.internal;

但backend.internal的证书是颁发给backend-prod.example.com的

解决方案A（推荐）：在后端服务上使用正确的域名证书

proxy_pass https://backend-prod.example.com;

解决方案B（应急）：关闭主机名验证（不建议生产环境使用）

proxy_ssl_verify off;

3. 自签名证书不被信任

在企业内网环境中常见这种情况：

location / {

proxy_pass https://internal-server;

而internal-server使用的是自签名证书

安全解决方案A（推荐）：

将自签名CA添加到NGINX信任库中：

proxy_ssl_trusted_certificate /path/to/internal-ca.crt;

proxy_ssl_verify on;

临时方案B（仅测试环境）：

*安全提醒*：禁用验证会使中间人攻击成为可能！

4. 协议/密码套件不匹配

有时会出现这样的报错："SSL routines:ssl3_read_bytes:sslv3 alert handshake failure"

这通常是因为：

1. NGINX和后端服务支持的TLS版本不一致

2. Cipher suite(加密套件)不匹配

解决方案示例配置：

proxy_ssl_protocols TLSv1.2 TLSv1.3;

指定支持的协议版本

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

定义密码套件偏好顺序

proxy_ssl_server_name on;

SNI支持很重要！

三、高级调试技巧

当遇到复杂问题时，这些方法能帮你快速定位：

1. OpenSSL诊断大法

检查远程服务器信息：

```bash

openssl s_client -connect backend:443 -servername backend.example.com -showcerts

检查本地信任情况：

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt your-cert.pem

2. NGINX调试日志

启用详细日志记录：

error_log /var/log/nginx/error.log debug;

http {

proxy_temp_path /var/log/nginx/proxy_temp;

然后观察日志中的SSL握手细节。

3. CURL测试不同场景

测试不带SNI的情况：

```bash

curl -vk https://backend.internal

测试带SNI的情况：

curl -vk --resolve backend.example.com:443:192.168.1.100 https://backend.example.com

四、最佳安全实践建议

根据OWASP安全指南和NIST标准，建议：

1. 强制TLS1.2+协议

```nginx

proxy_ssl_protocols TLSv1.2 TLSv1.3;

```

2. 禁用弱密码套件

proxy_ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384...';

3. 启用OCSP装订提高性能

ssl_stapling on;

ssl_stapling_verify on;

resolver 8.8.8.8 valid=300s;

4.定期轮换密钥和更新CRL

设置自动化流程每90天更新一次密钥和吊销列表。

五、真实案例解析：电商网站支付失败问题排查

某电商平台报告支付页面间歇性失败。经过排查发现：

1?? 现象分析

- Chrome用户稳定复现，Safari用户正常 → UA相关？

- F12控制台显示NET::ERR_CERT_AUTHORITY_INVALID → CA问题？

2?? 深入调查

通过Wireshark抓包发现:

- NGINX发送的服务器缺少中间CA → Chrome严格验证而Safari会自动获取中间CA

3?? 根本原因

CDN配置的PEM文件只包含终端实体证书，漏掉了中间CA

4?? 最终解决

重新生成fullchain.pem文件并更新CDN配置:

cat example-com.crt SectigoRSAOrganizationValidationSecureServerCA.crt USERTrustRSAAddTrustCA.crt > fullchain.pem

这个案例告诉我们：不同浏览器的TLS实现存在差异，必须确保完整的信任链传递。

通过以上内容我们可以看到，NGINX HTTPS代理中的各种问题都有其特定的技术背景和解决方法。关键是要理解TLS握手的基本原理，掌握适当的诊断工具和方法论。希望这篇指南能帮助你在遇到类似问题时快速定位并解决！

TAG:NGINX代理HTTPS证书错误,nginx代理ssl,nginx部署证书,nginx配置ssl证书无效,nginx证书链,nginx证书申请