对于一定规模的企业来说，在部署 HTTPS 的时候，一般不会在具体的 WEB 服务器（RealServer）上部署证书和密钥对，原因有多个：

• 为了负载均衡，大部分企业在 WEB 服务器（RealServer）前面一般会部署负载均衡服务器，比如 Load Balance 或者反向代理服务器。

• 在 RealServer 上部署证书，假如具体服务器数量很多，管理证书非常繁琐

• 同时 HTTPS 的交互非常消耗 CPU，在 RealServer 上部署证书，可能会影响具体服务的运行（比如 PHP-FPM）

所以很多企业在具体部署的时候，会选择这样一个方案：Client=>（HTTPS）Nginx=>（HTTP）RealServer，选择这个方案的原因在于：

• Nginx 代理 RealServer，这样 RealServer 很好扩容

• 同时 Nginx 负责大量运算的 SSL 请求，而 RealServer 负责具体的 HTTP 请求，和没有部署 HTTPS 以前一样。

看了这个方案，有些开发者会说代理服务器到 RealServer 的请求是 HTTP 的，会不会还是存在安全问题？理论上说确实会。不过考虑到 RealServer 一般处于内部防火墙保护中，可以认为相对是安全的。不过一般危险总是从内部产生的，所以可以采用这样一个方案：Client=>（HTTPS）Nginx=>（HTTPS）RealServer。

初看到这样一个方案的时候，会有以下的疑惑：

• 另外 Nginx 作为代理服务器，如何像客户端一样进行 HTTPS 交互，比如 Nginx 代理服务器并没有根证书。

• 假如内部请求也是 HTTPS 连接，那么是否表示需要更多的证书？

• 在每个层面都有证书，证书管理是一项大工程。

• 假如内部也是 HTTPS 连接，那么 RealServer 负载就会很大，因为也有完整的 HTTPS 交互流程。

幸好 Nginx 功能非常强大，看如何解决的。先贴具体的配置：

#### Nginx 代理服务器server {listen 443;server_name sitename.example.org;location / {proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header Host $http_host;proxy_set_header X-Forwarded-Proto https;proxy_redirect off;proxy_ssl_verify off;proxy_ssl_session_reuse onproxy_pass http://internal.sitename.example.org;proxy_http_version 1.1;}ssl on;....ssl_certificate /etc/ssl/certs/wildcard.example.org.pem;ssl_certificate_key /etc/ssl/private/wildcard.example.org.key;}

#### RealServer，安装的也是 Nginx server {ssl listen 443;server_name internal.sitename.example.org;ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;}

我们主要看 RealServer 配置:

proxy_ssl_verify 指令关闭证书的校验，表示代理服务器信任证书即可，不做严格的校验。这个指令是 Nginx 1.7 才支持的，假如你的 Nginx 版本比较低，没有关系，因为默认是关闭的。

RealServer 上的证书没有必要购买，可以自建在签名证书，在 Ubuntu 系统上默认有“snakeoil” 证书，默认地址是 /etc/ssl/certs/ssl-cert-snakeoil.pem ，假如没有这文件，运行这命令 make-ssl-cert generate-default-snakeoil --force-overwrite 就会产生。这个命令的好处就是每次运行得到的证书都是变化的，这样就避免了证书管理的安全问题。

在代理服务器上，对于内部的 HTTPS 请求，不会进行证书的校验，这样减少了 RealServer 具体处理负载（具体有多少影响没有验证）。

进一步优化，开启 proxy_ssl_session_reuse 指令后，表示重用上一次 SSL 连接，这样进一步减少了 RealServer 的负载。

参考:

• HTTPS behind your reverse proxy

• SECURING HTTP TRAFFIC TO UPSTREAM SERVERS

• SECURING TCP TRAFFIC TO UPSTREAM SERVERS