編譯自：
[configuring_https_servers][1]
[1]: http://nginx.org/en/docs/http/configuring_https_servers.html

目錄：

• 簡(jiǎn)介
• HTTPS 服務(wù)器優(yōu)化
• SSL 證書鏈
• 一個(gè) HTTP/HTTPS 服務(wù)器
• Name-based HTTPS 服務(wù)器
  • 多個(gè) server 共享一個(gè) SSL 證書
  • Server Name Indication
• 兼容性

簡(jiǎn)介

---

配置 HTTPS 服務(wù)，必須為 listen 指令加上 ssl 參數(shù)，并指定服務(wù)器的證書和私鑰：

server { listen443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ... } 

服務(wù)器證書將被發(fā)送給每個(gè)連接服務(wù)器的客戶端。私鑰必須在服務(wù)器端保存，應(yīng)該為私鑰添加嚴(yán)格的訪問限制，nginx 主進(jìn)程必須對(duì)其有讀權(quán)限。私鑰可以和證書存放在同一個(gè)文件中：

ssl_certificate www.example.com.cert; ssl_certificate_key www.example.com.cert; 

這個(gè)文件當(dāng)然也應(yīng)該加上嚴(yán)格的權(quán)限設(shè)置。雖然證書和私鑰被存放在同一個(gè)文件中，但只有證書會(huì)被發(fā)送給客戶端。

使用 ssl_protocols 指令 和 ss_chiphers 指令，可設(shè)置加密連接使用高安全性的協(xié)議版本以及加密性強(qiáng)的算法（SSL/TLS協(xié)議）。nginx 默認(rèn)使用 “ssl_protocols TLSv1 TLSv1.1 TLSv1.2” 以及 “ssl_ciphers HIGH:!aNULL:!MD5”，它們分別指定了默認(rèn)的協(xié)議版本和加密算法，所以這些算法不需要顯式地指定。要注意的是，這兩個(gè)指令的默認(rèn)值已經(jīng)多次發(fā)生改變（詳見 “兼容性” 小節(jié)）。

[listen][2] 指令
[2]: http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

[server][3] 指令
[3]: http://nginx.org/en/docs/http/ngx_http_core_module.html#server

[server certificate][4] 指令
[4]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate

[private key][5] 指令
[5]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key

[ssl_protocols][6] 指令
[6]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols

[ss_chiphers][7] 指令
[7]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers

HTTPS 服務(wù)器優(yōu)化

---

處理 SSL 連接會(huì)消耗額外的 CPU 資源。在多處理器系統(tǒng)上，應(yīng)設(shè)置對(duì)應(yīng)CPU核心個(gè)數(shù)的 worker 進(jìn)程。（參考：worker_processes）

建立 SSL 連接的握手階段是最消耗 CPU 的，有兩種方法可最小化建立每個(gè) SSL 連接所需要的握手操作次數(shù)：

• 第一是啟用 keepalive 連接保持。啟動(dòng)連接保持，可以在一個(gè)已建立的 SSL 連接上處理多個(gè)請(qǐng)求
• 第二是重用 SSL 會(huì)話參數(shù)，使并行的或者后續(xù)的連接不再需要進(jìn)行 SSL 握手。

SSL 連接的會(huì)話參數(shù)被保存在 SSL 會(huì)話緩存中，該緩存被所有的 worker 進(jìn)程共享，可使用 ssl_session_cache 指令對(duì)其進(jìn)行配置。1MB SSL 會(huì)話可容納約 4000 個(gè)會(huì)話。

默認(rèn)的緩存超時(shí)為 5 分鐘，可使用 ssl_session_timeout 指令進(jìn)行調(diào)整。

下面是一個(gè) SSL 優(yōu)化配置樣例，假設(shè)系統(tǒng)擁有的 CPU 核心總數(shù)為 10個(gè)，為其配置 10 MB 的共享會(huì)話緩存：

worker_processes auto;http { ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;server { listen443 ssl; server_name www.example.com; keepalive_timeout 70;ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ...

[ssl_session_cache][9]
[9]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache

[ssl_session_timeout][10]
[10]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout

SSL 證書鏈

---

有時(shí)會(huì)出現(xiàn)這樣的情況，對(duì)一個(gè)由知名 CA 簽發(fā)的證書，一些瀏覽器發(fā)出警告，而另一些瀏覽器會(huì)接受。這是因?yàn)楹灠l(fā)該證書的 CA 使用了一個(gè) intermediate certificate 簽發(fā)證書，這個(gè) intermediate certificate 沒有包含在跟隨瀏覽器一起分發(fā)的證書庫(kù)中。為應(yīng)對(duì)這個(gè)問題，CA 提供了 a bundle of chained certificate ，可將該證書與你的服務(wù)器證書合并成一個(gè)文件。在這個(gè)文件中，服務(wù)器的證書必須位于 chained certificate 的前面：

$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt 

使用它作為 ssl_certificate 指令的參數(shù)：

server { listen443 ssl; server_name www.example.com; ssl_certificate www.example.com.chained.crt; ssl_certificate_key www.example.com.key; ... } 

如果順序顛倒了，把服務(wù)器證書放在了 chained certificate 的后面，nginx 不能成功啟動(dòng)，并且顯示如下錯(cuò)誤消息:

SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed(SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch) 

這是因?yàn)?nginx 發(fā)現(xiàn)服務(wù)器的私鑰和 chained certificate 的第一個(gè)證書不匹配造成的。

當(dāng)瀏覽器收到 intermediate certificates 時(shí)，一般都會(huì)將它存儲(chǔ)下來(lái)。所以瀏覽器可能在第一次收到 intermediate certificates 時(shí)發(fā)出警告，但存儲(chǔ)下來(lái)之后再次收到時(shí)就不會(huì)發(fā)出警告了。

要確定一個(gè) web 服務(wù)器是否發(fā)送了完整的 certificate chain，可使用 openssl 命令：

$ openssl s_client -connect www.godaddy.com:443 ... Certificate chain0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc/OU=MIS Department/CN=www.GoDaddy.com/serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=079692871 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authorityi:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com ... Server certificate -----BEGIN CERTIFICATE-----... 

在此例中的 Certificate chain 中，#0號(hào)證書的對(duì)象 (“s”) 的證書頒發(fā)者是 (“i”)，#0證書的 (“i”) 同時(shí)又是 #1 號(hào)證書的對(duì)象 (“s”)；#1號(hào)證書頒發(fā)者 (“i”) 是 #2號(hào)證書的對(duì)象 (“s”)，#2號(hào)證書的頒發(fā)者 (“i”) 是知名 CA “ValiCert, Inc”，這個(gè) CA 的證書是存儲(chǔ)在隨瀏覽器分發(fā)的內(nèi)建證書庫(kù)中的。

如果服務(wù)器發(fā)送給客戶端的證書沒有包含 certificate chain，上面的信息只會(huì)顯示 #0 號(hào)服務(wù)器證書。

一個(gè) HTTP/HTTPS 服務(wù)器

---

建立一個(gè)可同時(shí)處理 HTTP 和 HTTPS 請(qǐng)求的 web 服務(wù)器：

server { listen80; listen443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ... }Note: nginx 0.7.14 版之前，不支持像上面這樣單獨(dú)將某個(gè)監(jiān)聽套接字設(shè)置為 SSL 連接。 只能在 server 區(qū)塊中使用 ssl {on|off} 指令，定義整個(gè) server 提供 HTTPS 服務(wù)， 因此不能設(shè)置可同時(shí)處理 HTTP/HTTPS 請(qǐng)求的 server 區(qū)塊?，F(xiàn)在不建議在新版本的 nginx中使用 ssl 指令，建議使用 ssl 參數(shù)。 

Name-based HTTPS 服務(wù)器

---

基于名稱的 HTTPS 服務(wù)器。

子目錄：

• 概念講解
• 多個(gè) server 共享一個(gè) SSL 證書
• Server Name Indication

概念講解

---

如何設(shè)置監(jiān)聽于一個(gè) IP 地址的多個(gè) HTTPS 服務(wù)器？

server { listen443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ... }server { listen443 ssl; server_name www.example.org; ssl_certificate www.example.org.crt; ... } 

雖然在這樣的配置中為兩個(gè) server 設(shè)置了不同的證書，但是當(dāng)使用瀏覽器訪問該 web 站點(diǎn)時(shí)，無(wú)論訪問的主機(jī)名是 www.example.com 還是 www.example.org，瀏覽器都將收到同一個(gè)服務(wù)器證書：服務(wù)器的默認(rèn)證書。在這里的默認(rèn)證書是 www.example.com.crt。

這是由 SSL 協(xié)議的行為所決定的。SSL 連接建立于 TCP/IP 連接之上，SSL 連接在握手的階段，會(huì)收到由 nginx 服務(wù)器發(fā)送的服務(wù)器證書，SSL 連接建完成之時(shí)，瀏覽器還沒有發(fā)送 HTTP 請(qǐng)求給 nginx，因此 nginx 無(wú)法在建立 SSL 連接時(shí)得知瀏覽器所請(qǐng)求的是哪一個(gè)虛擬主機(jī)，因此，nginx 只能發(fā)送默認(rèn)的服務(wù)器證書給瀏覽器。

對(duì)于這個(gè)問題，最老的方法，也是最 robust 的方法，是為每個(gè) HTTPS 服務(wù)設(shè)置獨(dú)立的 IP 地址：

server { listen192.168.1.1:443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ... }server { listen192.168.1.2:443 ssl; server_name www.example.org; ssl_certificate www.example.org.crt; ... } 

多個(gè) server 共享一個(gè) SSL 證書

---

有多種方式可實(shí)現(xiàn)在多個(gè) HTTPS servers 之間共享一個(gè) IP 地址，但這些方法都有各自的缺點(diǎn)。

一種方法是在證書的 SubjectAltName 字段中設(shè)置多個(gè)主機(jī)名，比如設(shè)置兩個(gè)主機(jī)名：www.example.com 和 www.example.org。缺點(diǎn)是 SubjectAltName 字段的長(zhǎng)度是有限制的。

另一種方法是在證書中設(shè)置“通配主機(jī)名”，比如 *.example.org，但它只能匹配一個(gè)名字區(qū)域的主機(jī)名，比如，它不能匹配 example.org 和 www.sub.example.org。

以上兩種方法可以結(jié)合使用，也就是在證書的 SubjectAltName 字段中同時(shí)包含多個(gè) “準(zhǔn)確主機(jī)名” 和 “通配主機(jī)名”。比如同時(shí)包含：example.org 和 *.example.org。

對(duì)于這種在多個(gè) HTTPS servers 之間共享一個(gè) IP 地址的應(yīng)用場(chǎng)景，最好在配置中，將服務(wù)器的證書和私鑰放到 http 區(qū)塊中，使得所有的 server 區(qū)塊可繼承該配置：

ssl_certificate common.crt; ssl_certificate_key common.key;server { listen443 ssl; server_name www.example.com; ... }server { listen443 ssl; server_name www.example.org; ... } 

Server Name Indication

---

對(duì)于實(shí)現(xiàn)在多個(gè) HTTPS servers 之間共享一個(gè) IP 地址，或者說(shuō)基于同一個(gè) IP 地址運(yùn)行多個(gè) HTTPS server，一種更為通用的解決方案是使用 TLS Server Name Indication extension (SNI, RFC 6066)。

通過(guò) SNI 可允許瀏覽器在與 web 服務(wù)器進(jìn)行 SSL 握手的階段，將所請(qǐng)求的 server name 傳遞給服務(wù)器，這樣服務(wù)器就能夠?yàn)檫@個(gè) SSL 連接選擇對(duì)應(yīng)的證書。

但是 SNI 對(duì)瀏覽器的版本有要求，目前支持 SNI 的瀏覽器版本如下：

Opera 8.0; MSIE 7.0 (but only on Windows Vista or higher); Firefox 2.0 and other browsers using Mozilla Platform rv:1.8.1; Safari 3.2.1 (Windows version supports SNI on Vista or higher); and Chrome (Windows version supports SNI on Vista or higher, too).Note: 在 SNI 中只能傳遞 domain names（域名）。如果一個(gè)訪問請(qǐng)求中包含有 IP 地址， 一些瀏覽器會(huì)錯(cuò)誤地將服務(wù)器的 IP 地址當(dāng)做所請(qǐng)求的主機(jī)名傳遞給服務(wù)器。因此，不能 完全依賴 SNI。 

為了在 nginx 中使用 SNI，要求兩種函數(shù)庫(kù)支持 SNI：一是 nginx 編譯時(shí)使用的 OpenSSL 庫(kù)，二是 nginx 在運(yùn)行時(shí)動(dòng)態(tài)鏈接的庫(kù)。OpenSSL 從 0.9.8f 版開始支持 SNI（要求 OpenSSL 在編譯時(shí)使用了 “--enable-tlsext” 選項(xiàng)）。從 0.9.8j 版開始，該選擇是默認(rèn)的選項(xiàng)。如果 nginx 編譯進(jìn)了對(duì) SNI 的支持，那么使用 nginx -V 命令查看時(shí)，可看到：

$ nginx -V ... TLS SNI support enabled ... 

附上譯者的測(cè)試：

[root@lamp1 ~]# nginx -V nginx version: nginx/1.10.1 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled ... 

如果 SNI-enabled nginx 動(dòng)態(tài)鏈接不支持 SNI 的 OpenSSL 庫(kù)，nginx 將顯示如下警告：

nginx was built with SNI support, however, now it is linked dynamically to an OpenSSL library which has no tlsext support, therefore SNI is not available 

兼容性

---

從 0.8.21 和 0.7.62 開始，可使用 nginx -V 顯示 SNI 支持狀態(tài)信息。

從 0.7.14 開始，nginx 支持在 listen 指令中使用 ssl 參數(shù)，而且在 0.8.21 之前，ssl 參數(shù)只能和 default 參數(shù)一起使用。

從 0.5.32 開始支持 SNI。
從 0.5.6 開始支持 SSL 會(huì)話緩存。

從 1.9.1 開始，默認(rèn)的 SSL 協(xié)議為 TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library)
從 0.7.65, 0.8.19 開始，到 1.9.1 之前，默認(rèn)的 SSL 協(xié)議為 SSLv3, TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library)。
0.7.64, 0.8.18 及之前，默認(rèn)的 SSL 協(xié)議為 SSLv2, SSLv3, and TLSv1。

從 1.0.5 開始，默認(rèn)的 SSL 加密算法為 “HIGH:!aNULL:!MD5”。
0.7.65, 0.8.20 之后，1.0.5 之前，默認(rèn)的 SSL 加密算法為 “HIGH:!ADH:!MD5”。
0.8.19: 默認(rèn)的 SSL 加密算法為 “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”。
0.7.64, 0.8.18 及之前，默認(rèn)的 SSL 加密算法為 “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”。

written by Igor Sysoev
edited by Brian Mercer

---

版權(quán)信息：
本文編譯自 nginx.org 的部分，遵循其原來(lái)的 licence 聲明： 2-clause BSD-like license

本頁(yè)內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過(guò)網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁(yè)中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://www.juherenli.com/20471.html