配置HTTPS服務(wù)器

配置HTTPS服務(wù)器

配置HTTPS主機，必須在server配置塊中打開SSL協(xié)議，還需要指定服務(wù)器端證書和密鑰文件的位置：

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

服務(wù)器證書是公開的，會被傳送到每一個連接到服務(wù)器的客戶端。而私鑰不是公開的，需要存放在訪問受限的文件中，當(dāng)然，nginx主進(jìn)程必須有讀取密鑰的權(quán)限。私鑰和證書可以存放在同一個文件中：

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

這種情況下，證書文件同樣得設(shè)置訪問限制。當(dāng)然，雖然證書和密鑰存放在同一個文件，只有證書會發(fā)送給客戶端，密鑰不會發(fā)送。

ssl_protocols和ssl_ciphers指令可以用來強制用戶連接只能引入SSL/TLS那些強壯的協(xié)議版本和強大的加密算法。從1.0.5版本開始，nginx默認(rèn)使用“ssl_protocols SSLv3 TLSv1”和“ssl_ciphers HIGH:!aNULL:!MD5”，所以只有在之前的版本，明確地配置它們才是有意義的。從1.1.13和1.0.12版本開始，nginx默認(rèn)使用“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”。

CBC模式的加密算法容易受到一些攻擊，尤其是BEAST攻擊（參見CVE-2011-3389）?？梢酝ㄟ^下面配置調(diào)整為優(yōu)先使用RC4-SHA加密算法：

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

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

SSL操作需要消耗CPU資源，所以在多處理器的系統(tǒng)，需要啟動多個工作進(jìn)程，而且數(shù)量需要不少于可用CPU的個數(shù)。最消耗CPU資源的SSL操作是SSL握手，有兩種方法可以將每個客戶端的握手操作數(shù)量降到最低：第一種是保持客戶端長連接，在一個SSL連接發(fā)送多個請求，第二種是在并發(fā)的連接或者后續(xù)的連接中重用SSL會話參數(shù)，這樣可以避免SSL握手的操作。會話緩存用于保存SSL會話，這些緩存在工作進(jìn)程間共享，可以使用ssl_session_cache指令進(jìn)行配置。1M緩存可以存放大約4000個會話。默認(rèn)的緩存超時是5分鐘，可以使用ssl_session_timeout加大它。下面是一個針對4核系統(tǒng)的配置優(yōu)化的例子，使用10M的共享會話緩存：

worker_processes 4;

http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

server {
listen 443;
server_name www.example.com;
keepalive_timeout 70;

ssl on;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
…

SSL證書鏈

有些瀏覽器不接受那些眾所周知的證書認(rèn)證機構(gòu)簽署的證書，而另外一些瀏覽器卻接受它們。這是由于證書簽發(fā)使用了一些中間認(rèn)證機構(gòu)，這些中間機構(gòu)被眾所周知的證書認(rèn)證機構(gòu)授權(quán)代為簽發(fā)證書，但是它們自己卻不被廣泛認(rèn)知，所以有些客戶端不予識別。針對這種情況，證書認(rèn)證機構(gòu)提供一個證書鏈的包裹，用來聲明眾所周知的認(rèn)證機構(gòu)和自己的關(guān)系，需要將這個證書鏈包裹與服務(wù)器證書合并成一個文件。在這個文件里，服務(wù)器證書需要出現(xiàn)在認(rèn)證方證書鏈的前面：

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

這個文件需要使用ssl_certificate指令來引用：

server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
…
}

如果服務(wù)器證書和認(rèn)證方證書鏈合并時順序弄錯了，nginx就不能正常啟動，而且會顯示下面的錯誤信息：

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

因為nginx首先需要用私鑰去解密服務(wù)器證書，而遇到的卻是認(rèn)證方的證書。

瀏覽器通常會將那些被受信的認(rèn)證機構(gòu)認(rèn)證的中間認(rèn)證機構(gòu)保存下來，那么這些瀏覽器以后在遇到使用這些中間認(rèn)證機構(gòu)但不包含證書鏈的情況時，因為已經(jīng)保存了這些中間認(rèn)證機構(gòu)的信息，所以不會報錯?？梢允褂胦penssl命令行工具來確認(rèn)服務(wù)器發(fā)送了完整的證書鏈：

$ openssl s_client -connect www.godaddy.com:443
…
Certificate chain
0 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=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
/OU=http://certificates.godaddy.com/repository
/CN=Go Daddy Secure Certification Authority
/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
i:/L=ValiCert Validation Network/O=ValiCert, Inc.
/OU=ValiCert Class 2 Policy Validation Authority
/CN=http://www.valicert.com//emailAddress=info@valicert.com
…

在這個例子中，www.GoDaddy.com的服務(wù)器證書（#0）的受簽者（“s”）是被簽發(fā)機構(gòu)（“i”）簽名的，而這個簽發(fā)機構(gòu)又是證書（#1）的受簽者，接著證書（#1）的簽發(fā)機構(gòu)又是證書（#2）的受簽者，最后證書（#2）是被眾所周知的簽發(fā)機構(gòu)ValiCert, Inc簽發(fā)。ValiCert, Inc的證書內(nèi)嵌在瀏覽器中，被瀏覽器自動識別（這段話神似英國詩《在Jack蓋的房子里》里面的內(nèi)容）。

如果沒有加入認(rèn)證方證書鏈，就只會顯示服務(wù)器證書（#0）。

合并HTTP/HTTPS主機

如果HTTP和HTTPS虛擬主機的功能是一致的，可以配置一個虛擬主機，既處理HTTP請求，又處理HTTPS請求。 配置的方法是刪除ssl on的指令，并在*:443端口添加參數(shù)ssl：

server {
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
…
}

在0.8.21版本以前，只有添加了default參數(shù)的監(jiān)聽端口才能添加ssl參數(shù)：
listen 443 default ssl;
基于名字的HTTPS主機
如果在同一個IP上配置多個HTTPS主機，會出現(xiàn)一個很普遍的問題：

server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
…
}

server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
…
}

使用上面的配置，不論瀏覽器請求哪個主機，都只會收到默認(rèn)主機www.example.com的證書。這是由SSL協(xié)議本身的行為引起的——先建立SSL連接，再發(fā)送HTTP請求，所以nginx建立SSL連接時不知道所請求主機的名字，因此，它只會返回默認(rèn)主機的證書。

最古老的也是最穩(wěn)定的解決方法就是每個HTTPS主機使用不同的IP地址：

server {
listen 192.168.1.1:443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
…
}

server {
listen 192.168.1.2:443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
…
}

帶有多個主機名的SSL證書

也有其他一些方法可以實現(xiàn)多個HTTPS主機共享一個IP地址，但都有不足。其中一種方法是使用在“SubjectAltName”字段中存放多個名字的證書，比如www.example.com和www.example.org。但是，“SubjectAltName”字段的長度有限制。

另一種方式是使用主機名中含有通配符的證書，比如*.example.org。這個證書匹配www.example.org，但是不匹配example.org和www.sub.example.org。這兩種方法可以結(jié)合在一起——使用在“SubjectAltName”字段中存放的多個名字的證書，這些名字既可以是確切的名字，也可以是通配符，比如example.org和*.example.org。

最好將帶有多個名字的證書和它的密鑰文件配置在http配置塊中，這樣可以只保存一份內(nèi)容拷貝，所有主機的配置都從中繼承：

ssl_certificate common.crt;
ssl_certificate_key common.key;

server {
listen 443;
server_name www.example.com;
ssl on;
…
}

server {
listen 443;
server_name www.example.org;
ssl on;
…
}

主機名指示

在一個IP上運行多個HTTPS主機的更通用的方案是TLS主機名指示擴展（SNI，RFC6066），它允許瀏覽器和服務(wù)器進(jìn)行SSL握手時，將請求的主機名傳遞給服務(wù)器，因此服務(wù)器可以知道使用哪一個證書來服務(wù)這個連接。但SNI只得到有限的瀏覽器的支持。下面列舉支持SNI的瀏覽器最低版本和平臺信息：

Opera 8.0；
MSIE 7.0（僅在Windows Vista操作系統(tǒng)及后續(xù)操作系統(tǒng)）；
Firefox 2.0和使用Mozilla平臺1.8.1版本的其他瀏覽器；
Safari 3.2.1（Windows版需要最低Vista操作系統(tǒng)）；
Chrome（Windows版需要最低Vista操作系統(tǒng)）。
通過SNI只能傳遞域名，但是，當(dāng)請求中包含可讀的IP地址時，某些瀏覽器將服務(wù)器的IP地址作為服務(wù)器的名字進(jìn)行了傳送。這是一個錯誤，大家不應(yīng)該依賴于這個。
為了在nginx中使用SNI，那么無論是在編譯nginx時使用的OpenSSL類庫，還是在運行nginx時使用的OpenSSL運行庫，都必須支持SNI。從0.9.8f版本開始，OpenSSL通過“–enable-tlsext”配置選項加入SNI支持，從0.9.8j版本開始，此選項成為默認(rèn)選項。當(dāng)nginx被編譯成支持SNI時，在使用“-V”選項運行時會顯示如下信息：

$ nginx -V
…
TLS SNI support enabled
…

但是，當(dāng)開啟SNI支持的nginx被動態(tài)鏈接到不支持SNI的OpenSSL庫上時，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版本開始，使用“-V”選項運行nginx時，將顯示SNI支持狀態(tài)信息。
從0.7.14版本開始，listen指令支持ssl參數(shù)。
從0.5.32版本開始，支持SNI。
從0.5.6版本開始，支持SSL會話緩存，并可在工作進(jìn)程間共享。
0.7.65、0.8.19及以后版本，默認(rèn)SSL協(xié)議是SSLv3、TLSv1、TLSc1.1和TLSv1.2（如果OpenSSL庫支持）。
0.7.64、0.8.18及以前版本，默認(rèn)SSL協(xié)議是SSLv2、SSLv3和TLSv1。
1.0.5及以后版本，默認(rèn)SSL密碼算法是HIGH:!aNULL:!MD5。
0.7.65、0.8.20及以后版本，默認(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。

全球可信CA機構(gòu)