SSL/TLS: 閱讀本文之前，請先了解SSL/TLS, 不熟悉請參考我的另外一篇文章：SSL/TLS，TLSv1.2是當(dāng)前使用最多的版本，而TLSv1.3是馬上將會普及得版本。所以下面的配置會同時涉及到這兩個版本。Ngi" />

国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

15158846557 或 在線咨詢 在線咨詢
15158846557 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 網(wǎng)站運(yùn)營 > Nginx配置HTTPS詳解

Nginx配置HTTPS詳解

時間：2023-07-15 00:24:01 | 來源：網(wǎng)站運(yùn)營

時間：2023-07-15 00:24:01 來源：網(wǎng)站運(yùn)營

Nginx配置HTTPS詳解：前向知識：

參考網(wǎng)站

測試TLS安全性： https://www.ssllabs.com/ssltest/analyze.html

TLS配置： https://ssl-config.mozilla.org/ HTTPS

Nginx配置博客：https://segmentfault.com/a/1190000013380916

HTTPS部署位置：

DNS + 后端web服務(wù)器

配置在后端web服務(wù)器上，Nginx 模塊： ngx_http_ssl_module

DNS + 四層設(shè)備 + 后端web服務(wù)器

TLS/SSL協(xié)議是TCP的上層協(xié)議，不支持在四層設(shè)備上面配置SSL/TLS, 只能在后端web服務(wù)器上面配置

DNS + 四層設(shè)備 + 七層設(shè)備 + 后端web服務(wù)器

在七層設(shè)備上面部署HTTPS

DNS + CDN + 后端web服務(wù)器

部署在CDN上面

Nginx配置HTTPS

Nginx機(jī)器環(huán)境

Nginx要支持SSL/TLS，需要安裝ngx_http_ssl_module模塊，使用發(fā)現(xiàn)版的安裝工具默認(rèn)已安裝，自己編譯安裝如下：

$ ./configure --with-http_ssl_module$ make


本文使用編譯安裝的Nginx演示，準(zhǔn)備環(huán)境：

# 源碼目錄創(chuàng)建一個tmp目錄來存放nginx.conf，access.log$ mkdir tmp# 啟動Nginx命令$ objs/nginx -p $(pwd) -c tmp/nginx.conf


Wireshark抓包環(huán)境設(shè)置 配置環(huán)境變量SSLKEYLOGTFILE和Wireshark Pre-Master-Secret log filename指向相同的日志文件

  1. 配置環(huán)境變量
$ export SSLKEYLOGFILE=/mnt/c/Users/slynxes/Desktop/sslkey.log2. 配置Wireshark

編輯 --> 首選項 --> TLS




HTTPS基礎(chǔ)配置

Nginx開啟HTTPS，最少配置項，其他采用默認(rèn)配置

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; # SSL 協(xié)議版本 ssl_protocols TLSv1.2; # 證書 ssl_certificate ssl/ecc.pem; # 私鑰 ssl_certificate_key ssl/ecc.key; return 200 "https ok /n"; }}

False Start

版本：TLSv1.2, 時間：1-RTT False Start 指還未完成SSL/TLS握手協(xié)議，就進(jìn)行HTTPS請求/應(yīng)答?？梢詫LSv1.2版本2-RTT的握手時間縮短為1-RTT，RSA密鑰協(xié)商算法是不支持False Start的，只有ECDHE密鑰協(xié)商算法才支持。Nginx只要ssl_ciphers套件里面有支持ECDHE的，瀏覽器自動會使用False Start。

原理

不使用False Start的SSL/TLS握手過程










使用False Start的SSL/TLS握手過程




示例

驗證使用RSA密鑰協(xié)商算法不能開啟False Start

示例1：使用RSA密鑰協(xié)商算法, 無法開啟False Start

ssl_ciphers套件中不包含ECDHE

# nginx.confdaemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; # SSL 協(xié)議版本 ssl_protocols TLSv1.2; # 證書 ssl_certificate ssl/rsa.pem; # 私鑰 ssl_certificate_key ssl/rsa.key; # ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_ciphers AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256; # 與False Start沒關(guān)系，默認(rèn)此項開啟，此處減少抓包的干擾而關(guān)閉 ssl_session_tickets off; return 200 "https ok /n"; }}


示例2：使用ECDHE密鑰協(xié)商算法, 瀏覽器自動開啟False Start

# nginx.confdaemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; # SSL 協(xié)議版本 ssl_protocols TLSv1.2; # 證書 ssl_certificate ssl/rsa.pem; # 私鑰 ssl_certificate_key ssl/rsa.key; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; # ssl_ciphers AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256; # 與False Start沒關(guān)系，默認(rèn)此項開啟，此處減少抓包的干擾而關(guān)閉 ssl_session_tickets off; return 200 "https ok /n"; }}


TLS Session Resumption: TLS 會話復(fù)用

TLS會話復(fù)用指客戶端與服務(wù)端經(jīng)過首次握手后，客戶端內(nèi)存中保存了服務(wù)端發(fā)過來的會話信息，后面的握手過程客戶端攜帶上會話信息，服務(wù)端驗證會話信息，驗證通過直接恢復(fù)會話，跳過證書驗證、密鑰交換等握手過程。

原理

根據(jù)服務(wù)端內(nèi)存中是否保存客戶端的會話信息，有兩種會話復(fù)用技術(shù)：













Nginx配置

# Session IDssl_session_cache off | none | [builtin[:size]] [shared:name:size]# Session Ticketssl_session_tickets on | off# 密鑰文件，服務(wù)器生成Session Ticket需要進(jìn)行加密，驗證時候需要解密。不指定服務(wù)器自行生成隨機(jī)的密鑰。# 密鑰文件要求80字節(jié)的AES256密鑰: openssl rand 80 > current.keyssl_session_ticket_key FILE;# 可以配置多個, 保證更換密鑰，但不影響以前的解密，順序從上到下。ssl_session_ticket_key current.keyssl_session_ticket_key previous.key# 設(shè)置Nginx可以重復(fù)使用session參數(shù)時間，包括Session ID, Session Ticketssl_session_timeout time;

示例

Session Ticket配置及抓包

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; ssl_protocols TLSv1.2; ssl_certificate ssl/rsa.pem; ssl_certificate_key ssl/rsa.key; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; # Session Ticket # 可以配置多個密鑰，這樣做的目的是為了定期更換密鑰，保證前向安全性。 # 將更換的密鑰配置在上面，Nginx會優(yōu)先采用上面的密鑰進(jìn)行加/解密， # 若使用舊密鑰加密的會話，上面的密鑰解密不了，就使用后面的密鑰進(jìn)行解密。 ssl_session_tickets on; ssl_session_ticket_key ./current.key; ssl_session_ticket_key ./previous.key; # Session ID # ssl_session_cache shared:mysession:10m; return 200 "https ok /n"; }}首次握手

后續(xù)握手




Session ID配置及抓包

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; ssl_protocols TLSv1.2; ssl_certificate ssl/rsa.pem; ssl_certificate_key ssl/rsa.key; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; # Session Ticket ssl_session_tickets off; # ssl_session_ticket_key ./current.key; # ssl_session_ticket_key ./previous.key; # Session ID ssl_session_cache shared:mysession:10m; return 200 "https ok /n"; }}首次握手

后續(xù)握手




密碼套件

SSL/TLS涉及多種密碼學(xué)算法，選擇安全、且性能高的密碼套件非常重要。但安全和性能是反相關(guān)的，需要平衡這兩者。下面是選擇建議：

TLSv1.2的密碼套件非常多，但建議按照上面的進(jìn)行選擇，按上面的組合后：




TLSv1.3廢除了許多不安全的密碼套件, 只保留了以下5種密碼套件

TLSv1.3中保留的算法

廢除密鑰交換算法RSA, DH的原因是，這兩種算法不具備前向安全性（今日收集，明日破解）

Nginx配置

# 密碼套件# 選擇密碼套件的順序是從左到右ssl_ciphers ciphers;# 選擇密碼套件時，以客戶端發(fā)送的密碼套件的順序為準(zhǔn)，還是以服務(wù)端ssl_ciphers配置的順序為準(zhǔn)。# off: 以客戶端優(yōu)先級為準(zhǔn), 默認(rèn)值# on: 以服務(wù)端優(yōu)先級為準(zhǔn)ssl_prefer_server_ciphers on | off# ECC橢圓曲線，不設(shè)置Nginx根據(jù)OpenSSL選擇ssl_ecdh_curve X25519:P-256;# 若使用DHE密鑰協(xié)商算法需要配置DHE Param, 不配會報錯，DHE-Param要求2048bit# 可通過openssl dhparam -out tmp/ssl/dhparam.pem 2048 生成dhparam.pemssl_dhparam tmp/ssl/dhparam.pem;

示例

示例1：同時兼容TLSv1.2, TLSv1.3的密碼套件

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_ecdh_curve X25519:P-256; # Session Ticket ssl_session_tickets on; ssl_session_ticket_key ./current.key; ssl_session_ticket_key ./previous.key; # Session ID # ssl_session_cache shared:mysession:10m; return 200 "https ok /n"; }}

示例2：ssl_perfer_server_ciphers

ssl_perfer_server_ciphers默認(rèn)值，即off時，以客戶端的密碼套件順序為準(zhǔn)

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305; # ssl_prefer_server_ciphers on; # Session Ticket ssl_session_tickets on; ssl_session_ticket_key ./current.key; ssl_session_ticket_key ./previous.key; # Session ID # ssl_session_cache shared:mysession:10m; return 200 "https ok /n"; }}測試：

$ openssl s_client -connect www.xlhtec.com:443 -tls1_2 -cipher 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256' 2>&1 </dev/null | grep CipherNew, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305 Cipher : ECDHE-ECDSA-CHACHA20-POLY1305$ openssl s_client -connect www.xlhtec.com:443 -tls1_3 -ciphersuites 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256' 2>&1 </dev/null | grep CipherNew, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256ssl_perfer_server_ciphers為on是，以服務(wù)端端的密碼套件順序為準(zhǔn)

ssl_session_tickets on;測試

$ openssl s_client -connect www.xlhtec.com:443 -tls1_2 -cipher 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256' 2>&1 </dev/null | grep CipherNew, TLSv1.2, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256 Cipher : ECDHE-ECDSA-AES128-GCM-SHA256

HSTS(HTTP Strict Transport Security)

Strict-Transport-Security 是一個HTTP響應(yīng)頭部字段，用來告訴瀏覽器只能使用HTTPS訪問服務(wù)器資源。

訪問HTTPS網(wǎng)站時，若不指定https協(xié)議頭，仍然會使用http進(jìn)行請求。通常在服務(wù)端會使用301、302進(jìn)行跳轉(zhuǎn)到https。這樣做雖然也可以最終讓瀏覽器通過https訪問服務(wù)器，但是存在兩個問題：1. 首次訪問時仍然時http，2.需要跳轉(zhuǎn)浪費(fèi)1-RTT的時間。

為了讓瀏覽器訪問時自動切換為HTTPS協(xié)議頭，在服務(wù)端響應(yīng)報文中增加頭部字段Strict-Transport-Security即可，瀏覽器除了首次訪問可能是http，后續(xù)將自動轉(zhuǎn)為https進(jìn)行訪問。若首次訪問都想讓HTTP自動切換為HTTPS，可以加入HSTS Preload List(一個谷歌維護(hù)的列表，現(xiàn)在大部分主流瀏覽器都支持這個列表，這個列表直接告訴瀏覽器要用 HTTPS 訪問的站點有哪些，所以在訪問站點之前，瀏覽器先撈一遍這個列表，如果要訪問的站點在這里面，就直接用 HTTPS 進(jìn)行訪問，所以即使是第一次訪問，也會走 HTTPS 了。)

Strict-Transport-Security頭部字段格式：

Strict-Transport-Security: max-age=<expire-time>Strict-Transport-Security: max-age=<expire-time>; includeSubDomainsStrict-Transport-Security: max-age=<expire-time>; preload

Nginx配置

# Nginx響應(yīng)報文中增加頭部字段語法# always: 無論響應(yīng)狀態(tài)碼是多少，都要增加該頭部字段add_header name value [always];# 增加 Strict-Transport-Security頭部字段add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

0-RTT(TLSv1.3)

TLSv1.2無論是False Start, Session ID, Session Ticket都只能將TLS握手縮短到1-RTT, 而TLSv1.3可以使用更激進(jìn)的方法，將TLS握手過程縮短為0-RTT，不過現(xiàn)在大多數(shù)瀏覽器還不支持0-RTT。Firefox Nightly支持，可以用其測試。

原理

  1. 首次握手過后客戶端保存了服務(wù)端發(fā)過來的New Session Ticket，并且攜帶了early_data?？蛻舳松蒔SK
  2. 后續(xù)握手過程中帶上PSK，和數(shù)據(jù)。服務(wù)端驗證PSK正確。則接收數(shù)據(jù)，有點像TCP Fast Open






開啟條件

  1. TLSv1.3版本
  2. 配置了會話復(fù)用：Session ID 或 Session Ticket
  3. 瀏覽器支持?，F(xiàn)在大多瀏覽器還不支持，我測試了Firefox Nightly是支持的
瀏覽器不支持的話，可以使用openssl命令測試

$ openssl s_client -connect www.xlhtec.com:443 -tls1_3 -keylogfile=./tls13.log -sess_out=./tls13.sess 2>&1 | grep 'Early data'$ openssl s_client -connect www.xlhtec.com:443 -tls1_3 -keylogfile=./tls13.log -sess_in=./tls13.sess -early_data=./req.txt 2>&1 < /dev/null | grep 'Early data'

Nginx配置

# 0-RTTssl_early_data on;# Session Ticketssl_session_tickets off;# ssl_session_ticket_key ./current.key;# ssl_session_ticket_key ./previous.key;# Session IDssl_session_cache shared:mysession:10m;

示例：抓包0-RTT

Nginx配置如下

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_ecdh_curve X25519:P-256; ssl_dhparam ssl/dhparam.pem; # Session Ticket ssl_session_tickets off; # ssl_session_ticket_key ./current.key; # ssl_session_ticket_key ./previous.key; # Session ID ssl_session_cache shared:mysession:10m; # 0-RTT ssl_early_data on; location / { return 200 "https ok /n"; } }}首次握手

后續(xù)握手實現(xiàn)0-RTT




HTTP/2

HTTP/2是為了優(yōu)化HTTP而誕生的協(xié)議，那么HTTP存在什么問題呢？

HTTP問題1：隊首阻塞 HTTP單個TCP連接中，多個請求應(yīng)答必須按照嚴(yán)格的順序排隊進(jìn)行。比如服務(wù)器接收到多個請求報文，響應(yīng)報文要按照請求報文發(fā)來時的先后順序依次響應(yīng)。這會造成隊首阻塞問題，即第一個報文響應(yīng)延遲，其他報文均需等待。為了解決此問題，瀏覽器通常打開多個TCP連接，但是這會造成服務(wù)連接過多，壓力大。所以默認(rèn)瀏覽器最多打開6個連接。

HTTP/2優(yōu)化方法： HTTP/2為了兼容HTTP。報文語義上仍然由Header + Body組成，只是將每個請求/應(yīng)答虛擬成一個Stream。然后將HTTP報文切割成幾塊，每一塊封裝成一個二進(jìn)制幀。一個Stream中的所有二進(jìn)制幀頭部包含相同的Stream ID ，不同Stream中的二進(jìn)制Stream ID不相同。然后一個TCP連接中多個Stream可以并發(fā)請求，服務(wù)器也可以并發(fā)應(yīng)答。并且Stream之間相互獨立，不存在先后順序。從而解決了HTTP中隊首阻塞的問題。但是一個Stream中的多個二進(jìn)制幀必須嚴(yán)格按照順序進(jìn)行請求/應(yīng)答。

HTTP問題2：頭部字段占用空間大 HTTP報文中有非常多的頭部字段，經(jīng)常會出現(xiàn)一個請求報文中Body非常小，甚至沒有，而Header仍然很大，就像大頭娃娃。

HTTP/2優(yōu)化方法： 雖然HTTP中也存在gzip壓縮方法，但是該方法只是用來對Body進(jìn)行壓縮的，并沒有對頭部字段進(jìn)行壓縮。HTTP/2專門針對HTTP中的頭部字段設(shè)計了HPACK壓縮算法。該算法是一個有狀態(tài)的算法。首先通信雙方維護(hù)一張靜態(tài)表，對常用的頭部字段進(jìn)行編號，這些編號稱為Index，發(fā)送的報文中就只需要帶上編號。接收方通過編號查找靜態(tài)表從而恢復(fù)頭部字段。由于編號比頭部字段小得多，從而起到壓縮頭部字段的作用。若出現(xiàn)靜態(tài)表中沒有的字段，則會雙方動態(tài)的將這些字段添加都靜態(tài)表中。

原理

HTTP/2特性：







HTTP/2二進(jìn)制幀結(jié)構(gòu)







HTTP/2建立連接過程




  1. 首先進(jìn)行TCP三次握手建立TCP連接
  2. SSL/TLS握手，握手過程中，若服務(wù)端支持HTTP/2協(xié)議，則在TLS子協(xié)議Encrypted Extensions擴(kuò)展字段ALPN中攜帶h2
  3. 客戶端需要回復(fù)一個特定的報文，稱為Magic: PRI * HTTP/2.0/r/n/r/nSM/r/n/r/n，該過程稱為連接首頁。后面雙方就升級為HTTP/2協(xié)議進(jìn)行通信。
  4. 雙方可以在單個TCP連接中多個Stream并發(fā)請求/應(yīng)答，稱為多路復(fù)用。

Nginx配置

listen 443 ssl http2;

示例：HTTP/2連接抓包

Nginx配置文件

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl http2; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_ecdh_curve X25519:P-256; # Session Ticket ssl_session_tickets off; # ssl_session_ticket_key ./current.key; # ssl_session_ticket_key ./previous.key; # Session ID # ssl_session_cache shared:mysession:10m; location / { index index.html; root /tmp/picture; # return 200 "https ok /n"; } }}升級HTTP/2協(xié)議過程

多路復(fù)用，可以看出并行發(fā)送了多個請求，響應(yīng)也是并行的。




OCSP stapling

TLS握手過程，客戶端需要對證書進(jìn)行驗證，比如日期、域名、吊銷狀態(tài)。以前驗證證書吊銷狀態(tài)使用CLR，CA將所有吊銷的證書添加到一張黑名單中，客戶端請求這張黑名單，匹配服務(wù)器證書是否在其中。不在則證書有效。這種方式隨著吊銷列表越來越大，請求該文件和匹配都變得非常低效。

后面出現(xiàn)OCSP（Oline Certificate Status Protocol）來解決該問題?？蛻舳蓑炞C服務(wù)器證書只需攜帶證書的序列號Serial Number請求CA的OCSP服務(wù)器，該服務(wù)器返回使用自己私鑰簽名的證書狀態(tài)?？蛻舳擞肅A解壓響應(yīng)結(jié)果。 OCSP雖然高效，但還存在兩個問題

  1. 他會泄露客戶端的隱私，因為客戶端都要攜帶證書Serial Number請求，OCSP服務(wù)器從而知道客戶端想訪問的網(wǎng)站
  2. 所有的客戶端驗證證書狀態(tài)都要向OCSP發(fā)起請求，導(dǎo)致OCSP服務(wù)器壓力倍增。
為了解決OCSP的問題，出現(xiàn)了OCSP stapling




Nginx配置

# 開啟OCSP stapling ssl_stapling on | off;# Nginx是否需要驗證OCSP服務(wù)器的響應(yīng)（比如證書吊銷狀態(tài)）# 若配置為on就需要使用CA的公鑰對響應(yīng)結(jié)果解密。# 就需要使用ssl_trusted_certificate指定證書鏈, # 但若ssl_cetificate中已經(jīng)包含了完整的證書鏈，就不用指定了。ssl_stapling_verify on | off;ssl_trusted_certificate FILE;# 若Nginx無法請求到OCSP服務(wù)器的響應(yīng)，比如網(wǎng)絡(luò)不好等等，也可以自己手動跟新響應(yīng)，# 然后將響應(yīng)保存到一個DER格式的文件中，然后指定該文件。ssl_stapling_file DER_FILE; # 自己指定OCSP服務(wù)，默認(rèn)包含在證書中，不用指定。ssl_stapling_responder http://OCSP_SERVER;

示例：驗證OCSP stapling是否生效

Nginx配置文件

daemon off;pid tmp/nginx.pid;error_log stderr debug;events {}http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl http2; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_ecdh_curve X25519:P-256; ssl_dhparam ssl/dhparam.pem; # Session Ticket ssl_session_tickets off; # ssl_session_ticket_key ./current.key; # ssl_session_ticket_key ./previous.key; # Session ID ssl_session_cache shared:mysession:10m; # 0-RTT ssl_early_data on; # OCSP stapling ssl_stapling on; location / { return 200 "https ok /n"; } }}驗證

$ openssl s_client -connect www.xlhtec.com:443 -status < /dev/null 2>&1 | grep -i "OCSP response"OCSP response:OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response

多虛擬主機(jī)配置不同證書 及 一個虛擬主機(jī)配置多證書

多虛擬主機(jī)配置不同證書

Nginx支持多虛擬主機(jī)，并且可以實現(xiàn)每個虛擬主機(jī)配置不同的證書。我們知道只有完成SSL/TLS握手后才能進(jìn)行HTTPS通信，而在TLS握手階段，Server需要發(fā)送證書給客戶端，那么配置了多虛擬主機(jī)不同證書的Server如何知道要發(fā)送哪一個證書呢？這就要感謝TLS 子協(xié)議Client Hello擴(kuò)展字段SNI（Server Name Indication extension）,該字段會攜帶服務(wù)器域名




域名證書配置實例

每個虛擬主機(jī)證書不一樣

http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl http2; server_name www.xlhtec.com ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/www_xlhtec_com_ecc.pem; ssl_certificate_key ssl/www_xlhtec_com_ecc.key; ... } server { listen 443 ssl http2; server_name blog.xlhtec.com ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/blog_xlhtec_com_ecc.pem; ssl_certificate_key ssl/blog_xlhtec_com_ecc.key; ... }}若虛擬主機(jī)的證書都一樣，就不用這么麻煩了，在http {}塊中配置即可

http { access_log tmp/access.log; default_type text/html; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; server { listen 443 ssl http2; server_name www.xlhtec.com ... } server { listen 443 ssl http2; server_name blog.xlhtec.com ... }}

一個虛擬主機(jī)配置多個證書

一個虛擬主機(jī)可以配置多個證書，比如同時配置ECCDSA、RSA證書

http { access_log tmp/access.log; default_type text/html; server { listen 443 ssl http2; server_name www.xlhtec.com ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ssl/ecc.pem; ssl_certificate_key ssl/ecc.key; ssl_certificate ssl/rsa.pem; ssl_certificate_key ssl/rsa.key; ... }}

Nginx ngx-http_ssl_module相關(guān)變量

喔：語雀里面寫了導(dǎo)入過來的，表格亂了，只能截圖哈

Nginx日志中添加上面的變量

http { log_format main 'ssl_protocol: $ssl_protocol/n' 'ssl_cipher: $ssl_cipher/n' 'ssl_ciphers: $ssl_ciphers/n' 'ssl_curves: $ssl_curves/n' 'ssl_server_name: $ssl_server_name/n' 'ssl_session_id: $ssl_session_id/n' 'http2: $http2/n'; access_log tmp/access.log main; ...}日志輸出

$ tail -f tmp/access.logssl_protocol: TLSv1.3ssl_cipher: TLS_AES_256_GCM_SHA384ssl_ciphers: TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DES-CBC3-SHAssl_curves: X25519:prime256v1:secp384r1:secp521r1:0x0100:0x0101ssl_server_name: www.xlhtec.comssl_session_id: 1d54d0e1009f9a25edb60f95951987762da4e8b3f483873db55fc95a4b1774f4http2: h2

關(guān)鍵詞：配置

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關(guān)閉