對於一定規模的企業來說，在部署 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 on
proxy_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 的負載。
參考:
