您好,登錄后才能下訂單哦!
Nginx上部署HTTPS依賴OpenSSL庫和包含文件,即須先安裝好libssl-dev(或者OpenSSL),且ln -s /usr/lib/x86_64-linux-gnu/libssl.so /usr/lib/,然后在編譯配置Nginx時要指定--with-http_ssl_module和--with-http_v2_module。另外,若要在本地運行openssl命令,要安裝OpenSSL包,本人用的OpenSSL-1.0.2g。注:本文采用Ubuntu 16.04上的操作實例。
下圖展示了數字證書(HTTPS中使用的由CA簽名的公鑰證書)的簽名和驗證原理:
TLS保障信息傳輸安全:對于每一次新的對話(連接握手階段。這里講的對話不是HTTP中涉及的應用層對話,而是TLS對話),客戶端和服務端都會協商一個對話密鑰和對稱加密算法(了解更多可參考“加密套件”“四次握手”相關內容)用來加減密信息,這樣就避免非對稱加減密耗時過長,運算速度更快;而Public/Private密鑰對只用于"pre-master key"的加解密。特別地,在連接斷開后,舊對話的恢復(兩種實現方法:session ID和session ticket)不屬于建立新的對話,無需協商一個新的對話密鑰和對稱加密算法。
HTTP2:HTTP2 基于SPDY設計,支持HTTPS。但HTTP2與SPDY不同的是,不強制使用 HTTPS,但目前還沒有瀏覽器支持;HTTP2 消息頭的壓縮算法采用 HPACK ,而非 SPDY 采用的 DELEFT。HTTP2基本兼容HTTP1.x的語義,只是改變了HTTP1.x的傳輸方式,在連接中是否使用HTTP2是通過協議協商(NPN、ALPN或Upgrade頭)來決定的。HTTP2擁有許多新特性:
二進制協議:HTTP2.0協議采用二進制格式,實現方便且健壯;HTTP1.x采用的是文本格式
頭部壓縮:HTTP/1.x 每次請求,都會攜帶大量冗余頭信息,浪費了很多帶寬資源,頭壓縮能夠很好的解決該問題
多路復用:多個請求和響應通過一個 TCP 連接并發完成,還支持請求優先級劃分和流控制
Server Push:服務端可以主動把 JS 和 CSS 文件推送給客戶端,而不需要客戶端先解析 HTML 再發送這些請求。當客戶端需要的時候,它們已經在客戶端了
下圖是HTTP2 Frame 格式:RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
Nginx上部署HTTPS + HTTP2
自簽發證書:開發測試環境下可以在其他機器上去生成證書,然后再將所生成server.crt和server.key復制一份至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 #證書簽名
修改配置文件nginx.conf:為減少CPU負載,建議只運行一個工作進程,并且開啟keep-alive。另外,version 0.6.7以上的Nginx ssl_certificate和ssl_certificate_key的默認關聯目錄為nginx.conf所在的目錄,默認文件名都為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; }
重啟Nginx:HTTPS在Nginx上的部署至此已近完畢,然后就可以通過ht t ps : / / YO U R _ D OM A I N N A ME _ H E R E來訪問了。由于本例中采用自簽發證書(不同于CA自簽名的Root證書),在Chrome下將看到如圖警告信息,表明該證書不受信任。瀏覽器在默認情況下內置了一些CA機構的Root證書,這些證書受到絕對信任。
另外,本人在Chromium 58.0.3029.110 和 Firefox 53.0.3 下均證實了HTTP2被成功啟用:
私鑰保護:私鑰是重要的財產,盡可能限制能接觸到私鑰的人
在一臺可信的計算機上生成私鑰和CSR(Certificate Signing Requests)。有一些CA會為你生成密鑰和CSR,但這樣做明顯不妥
受密碼保護的密鑰可以阻止在備份系統中被截獲
在發現被截獲后,撤回老的證書,生成新的密鑰和證書
每年更新證書,總是使用最新的私鑰
部署證書鏈:證書鏈(Certificate Chain)包括信任錨(CA 證書)和簽名證書,是由一系列 CA 證書發出的證書序列,最終以根 CA 證書結束;Web 瀏覽器已預先配置了一組瀏覽器自動信任的根 CA 證書,來自其他證書授權機構的所有證書都必須附帶證書鏈,以檢驗這些證書的有效性。在很多部署場景中,單一的服務器證書顯得不足,而多個證書則需要建立一個信任鏈。一個常見的問題是正確的配置了服務器證書但卻搞忘了包含其他所需要的證書。此外,雖然其他證書通常有很長的有效期,但它們也會過期,如果它們過期就會影響整個鏈條。一個無效證書鏈會導致服務器證書失效和客戶端瀏覽器報警告,這個問題有時候不是那么容易被檢測到,因為有些瀏覽器可以自己重構一個完整的信任鏈而有些則不行。關于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配置指令說明:下邊只列舉了部分,更多配置項可參考 http://www.nginx.cn/doc/optional/ssl.html。
ssl:開啟HTTPS
syntax:ssl [on|off]
default:ssl off
context:main, server
ssl_certificate:證書文件,默認證書和密鑰都位于cert.pem中,該文件還可以包含其他證書。自version 0.6.7起,ssl_certificate的默認關聯目錄為nginx.conf所在的目錄。
syntax:ssl_certificate file
default:ssl_certificate cert.pem
context:main, server
ssl_certificate_key:證書密鑰文件,默認密鑰位于cert.pem中。自version 0.6.7起,ssl_certificate_key的默認關聯目錄為nginx.conf所在的目錄。
syntax:ssl_certificate_key file
default:ssl_certificate_key cert.pem
context:main, server
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
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
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
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
ssl_protocols:Directive enables the protocols indicated. TLS v1.0以上的版本是比較安全的,最好是棄用SSLv3以下的版本,SSLv2以下堅決不用
syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1]
default: ssl_protocols SSLv2 SSLv3 TLSv1
context: main, server
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;
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
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。