日本少妇寂寞少妇aaa,国产婷婷色一区二区三区,JK浴室自慰到不停喷水尿失禁,一本一道波多野结衣av黑人

歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司！
電話(huà)圖標(biāo) 余先生：13699882642

網(wǎng)站百科

為您解碼網(wǎng)站建設(shè)的點(diǎn)點(diǎn)滴滴

nginx 配置 HTTPS 服務(wù)

發(fā)表日期：2016-07 文章編輯：小燈 瀏覽次數(shù)：2727

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

目錄：

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

簡(jiǎn)介

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

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

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

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

使用 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àn) “兼容性” 小節(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ì)話(huà)參數(shù)，使并行的或者后續(xù)的連接不再需要進(jìn)行 SSL 握手。

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

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

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

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

一個(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)聽(tīng)套接字設(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ù)器

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

子目錄：

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

概念講解

如何設(shè)置監(jiān)聽(tīng)于一個(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è)置了不同的證書(shū)，但是當(dāng)使用瀏覽器訪(fǎng)問(wèn)該 web 站點(diǎn)時(shí)，無(wú)論訪(fǎng)問(wèn)的主機(jī)名是 www.example.com 還是 www.example.org，瀏覽器都將收到同一個(gè)服務(wù)器證書(shū)：服務(wù)器的默認(rèn)證書(shū)。在這里的默認(rèn)證書(shū)是 www.example.com.crt。

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

對(duì)于這個(gè)問(wèn)題，最老的方法，也是最 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ū)

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

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

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

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

對(duì)于這種在多個(gè) HTTPS servers 之間共享一個(gè) IP 地址的應(yīng)用場(chǎng)景，最好在配置中，將服務(wù)器的證書(shū)和私鑰放到 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)的證書(shū)。

但是 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è)訪(fǎng)問(wèn)請(qǐng)求中包含有 IP 地址， 一些瀏覽器會(huì)錯(cuò)誤地將服務(wù)器的 IP 地址當(dāng)做所請(qǐng)求的主機(jī)名傳遞給服務(wù)器。因此，不能 完全依賴(lài) SNI。

為了在 nginx 中使用 SNI，要求兩種函數(shù)庫(kù)支持 SNI：一是 nginx 編譯時(shí)使用的 OpenSSL 庫(kù)，二是 nginx 在運(yùn)行時(shí)動(dòng)態(tài)鏈接的庫(kù)。OpenSSL 從 0.9.8f 版開(kāi)始支持 SNI（要求 OpenSSL 在編譯時(shí)使用了 “--enable-tlsext” 選項(xiàng)）。從 0.9.8j 版開(kāi)始，該選擇是默認(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 開(kāi)始，可使用 nginx -V 顯示 SNI 支持狀態(tài)信息。

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

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

從 1.9.1 開(kāi)始，默認(rèn)的 SSL 協(xié)議為 TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library)
從 0.7.65, 0.8.19 開(kāi)始，到 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 開(kāi)始，默認(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ò)收集編輯所得，所有資料僅供用戶(hù)學(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.cokiv.cn/20471.html
相關(guān)開(kāi)發(fā)語(yǔ)言