Nginx上部署HTTPS + HTTP2

Nginx上部署HTTPS依賴OpenSSL庫和包含文件，即須先安裝好libssl-dev(或者OpenSSL)，且ln -s /usr/lib/x86_64-linux-gnu/libssl.so  /usr/lib/，然后在編譯配置Nginx時(shí)要指定--with-http_ssl_module和--with-http_v2_module。另外，若要在本地運(yùn)行openssl命令，要安裝OpenSSL包，本人用的OpenSSL-1.0.2g。注：本文采用Ubuntu 16.04上的操作實(shí)例。

　　下圖展示了數(shù)字證書(HTTPS中使用的由CA簽名的公鑰證書)的簽名和驗(yàn)證原理：

• TLS保障信息傳輸安全：對于每一次新的對話(連接握手階段。這里講的對話不是HTTP中涉及的應(yīng)用層對話，而是TLS對話)，客戶端和服務(wù)端都會協(xié)商一個(gè)對話密鑰和對稱加密算法(了解更多可參考“加密套件”“四次握手”相關(guān)內(nèi)容)用來加減密信息，這樣就避免非對稱加減密耗時(shí)過長，運(yùn)算速度更快；而Public/Private密鑰對只用于"pre-master key"的加解密。特別地，在連接斷開后，舊對話的恢復(fù)(兩種實(shí)現(xiàn)方法：session ID和session ticket)不屬于建立新的對話，無需協(xié)商一個(gè)新的對話密鑰和對稱加密算法。

• HTTP2：HTTP2 基于SPDY設(shè)計(jì)，支持HTTPS。但HTTP2與SPDY不同的是，不強(qiáng)制使用 HTTPS，但目前還沒有瀏覽器支持；HTTP2 消息頭的壓縮算法采用 HPACK ，而非 SPDY 采用的 DELEFT。HTTP2基本兼容HTTP1.x的語義，只是改變了HTTP1.x的傳輸方式，在連接中是否使用HTTP2是通過協(xié)議協(xié)商(NPN、ALPN或Upgrade頭)來決定的。HTTP2擁有許多新特性：

1. 二進(jìn)制協(xié)議：HTTP2.0協(xié)議采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯；HTTP1.x采用的是文本格式

2. 頭部壓縮：HTTP/1.x 每次請求，都會攜帶大量冗余頭信息，浪費(fèi)了很多帶寬資源，頭壓縮能夠很好的解決該問題

3. 多路復(fù)用：多個(gè)請求和響應(yīng)通過一個(gè) TCP 連接并發(fā)完成，還支持請求優(yōu)先級劃分和流控制

4. Server Push：服務(wù)端可以主動把 JS 和 CSS 文件推送給客戶端，而不需要客戶端先解析 HTML 再發(fā)送這些請求。當(dāng)客戶端需要的時(shí)候，它們已經(jīng)在客戶端了

　　下圖是HTTP2 Frame 格式：RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

• Nginx上部署HTTPS + HTTP2

1. 自簽發(fā)證書：開發(fā)測試環(huán)境下可以在其他機(jī)器上去生成證書，然后再將所生成server.crt和server.key復(fù)制一份至Nginx的/usr/local/nginx/conf下即可

   $ cd /usr/local/nginx/conf
   $ openssl genrsa -des3 -out server.key 1024 #建議：2048$ openssl req -new -key server.key -out server.csr #證書簽名請求（CSR）
   $ cp server.key server.key.org
   $ openssl rsa -in server.key.org -out server.key
   $ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt #證書簽名

2. 修改配置文件nginx.conf：為減少CPU負(fù)載，建議只運(yùn)行一個(gè)工作進(jìn)程，并且開啟keep-alive。另外，version 0.6.7以上的Nginx ssl_certificate和ssl_certificate_key的默認(rèn)關(guān)聯(lián)目錄為nginx.conf所在的目錄，默認(rèn)文件名都為cert.pem

   

   worker_processes 1;
   server {
   
       server_name YOUR_DOMAINNAME_HERE;
       listen 443 ssl http2;# http2 is available only since OpenSSL version 1.0.2
       listen 80;
       if ($scheme = http) {
               rewrite ^(.*)$ https://$server_name$1 permanent;
       }
       ssl_certificate server.crt;
       ssl_certificate_key server.key;
       keepalive_timeout    70;
   }

   

    

3. 重啟Nginx：HTTPS在Nginx上的部署至此已近完畢，然后就可以通過ht t ps : / / YO U R _ D OM A I N N A ME _ H E R E來訪問了。由于本例中采用自簽發(fā)證書(不同于CA自簽名的Root證書)，在Chrome下將看到如圖警告信息，表明該證書不受信任。瀏覽器在默認(rèn)情況下內(nèi)置了一些CA機(jī)構(gòu)的Root證書，這些證書受到絕對信任。

　　另外，本人在Chromium 58.0.3029.110 和 Firefox 53.0.3 下均證實(shí)了HTTP2被成功啟用：

• 私鑰保護(hù)：私鑰是重要的財(cái)產(chǎn)，盡可能限制能接觸到私鑰的人

1. 在一臺可信的計(jì)算機(jī)上生成私鑰和CSR(Certificate Signing Requests)。有一些CA會為你生成密鑰和CSR，但這樣做明顯不妥

2. 受密碼保護(hù)的密鑰可以阻止在備份系統(tǒng)中被截獲

3. 在發(fā)現(xiàn)被截獲后，撤回老的證書，生成新的密鑰和證書

4. 每年更新證書，總是使用最新的私鑰

• 部署證書鏈：證書鏈(Certificate Chain)包括信任錨（CA 證書）和簽名證書，是由一系列 CA 證書發(fā)出的證書序列，最終以根 CA 證書結(jié)束；Web 瀏覽器已預(yù)先配置了一組瀏覽器自動信任的根 CA 證書，來自其他證書授權(quán)機(jī)構(gòu)的所有證書都必須附帶證書鏈，以檢驗(yàn)這些證書的有效性。在很多部署場景中，單一的服務(wù)器證書顯得不足，而多個(gè)證書則需要建立一個(gè)信任鏈。一個(gè)常見的問題是正確的配置了服務(wù)器證書但卻搞忘了包含其他所需要的證書。此外，雖然其他證書通常有很長的有效期，但它們也會過期，如果它們過期就會影響整個(gè)鏈條。一個(gè)無效證書鏈會導(dǎo)致服務(wù)器證書失效和客戶端瀏覽器報(bào)警告，這個(gè)問題有時(shí)候不是那么容易被檢測到，因?yàn)橛行g覽器可以自己重構(gòu)一個(gè)完整的信任鏈而有些則不行。關(guān)于Nginx上部署證書鏈：

  if you have a chain certificate file (sometimes called an intermediate certificate)
  you don't specify it separately like you do in Apache. Instead you need to add the 
  information from the chain cert to the end of your main certificate file. This can be done 
  by typing "cat chain.crt >> mysite.com.crt" on the command line. Once that is done you
  won't use the chain cert file for anything else, you just point Nginx to the main certificate file

　　 下圖展示了證書鏈的工作原理：

• Nginx上SSL配置指令說明：下邊只列舉了部分，更多配置項(xiàng)可參考 http://www.nginx.cn/doc/optional/ssl.html。
  

1. ssl：開啟HTTPS

   syntax:ssl [on|off]

   default:ssl off

   context:main, server

2. ssl_certificate：證書文件，默認(rèn)證書和密鑰都位于cert.pem中，該文件還可以包含其他證書。自version 0.6.7起，ssl_certificate的默認(rèn)關(guān)聯(lián)目錄為nginx.conf所在的目錄。

   syntax:ssl_certificate file

   default:ssl_certificate cert.pem

   context:main, server 

3. ssl_certificate_key：證書密鑰文件，默認(rèn)密鑰位于cert.pem中。自version 0.6.7起，ssl_certificate_key的默認(rèn)關(guān)聯(lián)目錄為nginx.conf所在的目錄。

   syntax:ssl_certificate_key file

   default:ssl_certificate_key cert.pem

   context:main, server

4. ssl_client_certificate：Indicates file with certificates CA in PEM format, utilized for checking the client certificates.

   syntax:ssl_client_certificate file

   default:none

   context:main, server

5. ssl_dhparam：Indicates file with Diffie-Hellman parameters in PEM format, utilized for negotiating TLS session keys.

   syntax: ssl_dhparam file

   default: none

   context: main, server 

6. ssl_ciphers：Directive describes the permitted ciphers. Ciphers are assigned in the formats supported by OpenSSL.

   syntax: ssl_ciphers file

   default: ssl_ciphers ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

   context: main, server

   ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

   Complete list can be looked with the following command:

   openssl ciphers

    

7. ssl_prefer_server_ciphers：Requires protocols SSLv3 and TLSv1 server ciphers be preferred over the client's ciphers.

   syntax: ssl_prefer_server_ciphers [on|off]

   default: ssl_prefer_server_ciphers off

   context: main, server

8. ssl_protocols：Directive enables the protocols indicated. TLS v1.0以上的版本是比較安全的，最好是棄用SSLv3以下的版本，SSLv2以下堅(jiān)決不用

   syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1]

   default: ssl_protocols SSLv2 SSLv3 TLSv1

   context: main, server

9. ssl_session_cache：The directive sets the types and sizes of caches to store the SSL sessions.

   syntax:ssl_session_cache off|none|builtin:size and/or shared:name:size

   default:ssl_session_cache off

   context:main, server

   ssl_session_cache builtin:1000 shared:SSL:10m;

    

10. ssl_session_timeout：Assigns the time during which the client can repeatedly use the parameters of the session, which is stored in the cache.

    syntax:ssl_session_timeout time

    default:ssl_session_timeout 5m

    context:main, server