nginx 学习笔记(9) 配置HTTPS服务器--转载

时间 2019-11-13

原文原文链接

HTTPS服务器优化
SSL证书链
合并HTTP/HTTPS主机
基于名字的HTTPS主机
带有多个主机名的SSL证书
主机名指示
兼容性

配置HTTPS主机，必须在server配置块中打开SSL协议，还须要指定服务器端证书和密钥文件的位置：html

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;
    ...
}

服务器证书是公开的，会被传送到每个链接到服务器的客户端。而私钥不是公开的，须要存放在访问受限的文件中，固然，nginx主进程必须有读取密钥的权限。私钥和证书能够存放在同一个文件中：nginx

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

这种状况下，证书文件一样得设置访问限制。固然，虽然证书和密钥存放在同一个文件，只有证书会发送给客户端，密钥不会发送。web

ssl_protocols和ssl_ciphers指令能够用来强制用户链接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始，nginx默认使用“ssl_protocols SSLv3 TLSv1”和“ssl_ciphers HIGH:!aNULL:!MD5”，因此只有在以前的版本，明确地配置它们才是有意义的。从1.1.13和1.0.12版本开始，nginx默认使用“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”。算法

CBC模式的加密算法容易受到一些攻击，尤为是BEAST攻击（参见CVE-2011-3389）。能够经过下面配置调整为优先使用RC4-SHA加密算法：浏览器

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

HTTPS服务器优化

SSL操做须要消耗CPU资源，因此在多处理器的系统，须要启动多个工做进程，并且数量须要很多于可用CPU的个数。最消耗CPU资源的SSL操做是SSL握手，有两种方法能够将每一个客户端的握手操做数量降到最低：第一种是保持客户端长链接，在一个SSL链接发送多个请求，第二种是在并发的链接或者后续的链接中重用SSL会话参数，这样能够避免SSL握手的操做。会话缓存用于保存SSL会话，这些缓存在工做进程间共享，可使用ssl_session_cache指令进行配置。1M缓存能够存放大约4000个会话。默认的缓存超时是5分钟，可使用ssl_session_timeout加大它。下面是一个针对4核系统的配置优化的例子，使用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证书链

有些浏览器不接受那些众所周知的证书认证机构签署的证书，而另一些浏览器却接受它们。这是因为证书签发使用了一些中间认证机构，这些中间机构被众所周知的证书认证机构受权代为签发证书，可是它们本身却不被普遍认知，因此有些客户端不予识别。针对这种状况，证书认证机构提供一个证书链的包裹，用来声明众所周知的认证机构和本身的关系，须要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里，服务器证书须要出如今认证方证书链的前面：服务器

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

这个文件须要使用ssl_certificate指令来引用：session

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

若是服务器证书和认证方证书链合并时顺序弄错了，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首先须要用私钥去解密服务器证书，而遇到的倒是认证方的证书。工具

浏览器一般会将那些被受信的认证机构认证的中间认证机构保存下来，那么这些浏览器之后在遇到使用这些中间认证机构但不包含证书链的状况时，由于已经保存了这些中间认证机构的信息，因此不会报错。可使用openssl命令行工具来确认服务器发送了完整的证书链：

$ 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的服务器证书（#0）的受签者（“s”）是被签发机构（“i”）签名的，而这个签发机构又是证书（#1）的受签者，接着证书（#1）的签发机构又是证书（#2）的受签者，最后证书（#2）是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中，被浏览器自动识别（这段话神似英国诗《在Jack盖的房子里》里面的内容）。

若是没有加入认证方证书链，就只会显示服务器证书（#0）。

合并HTTP/HTTPS主机

若是HTTP和HTTPS虚拟主机的功能是一致的，能够配置一个虚拟主机，既处理HTTP请求，又处理HTTPS请求。配置的方法是删除ssl on的指令，并在*:443端口添加参数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参数的监听端口才能添加 ssl参数：
listen  443  default ssl;

基于名字的HTTPS主机

若是在同一个IP上配置多个HTTPS主机，会出现一个很广泛的问题：

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;
    ...
}

使用上面的配置，不论浏览器请求哪一个主机，都只会收到默认主机www.example.com的证书。这是由SSL协议自己的行为引发的——先创建SSL链接，再发送HTTP请求，因此nginx创建SSL链接时不知道所请求主机的名字，所以，它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每一个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证书

也有其余一些方法能够实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，好比www.example.com和www.example.org。可是，“SubjectAltName”字段的长度有限制。

另外一种方式是使用主机名中含有通配符的证书，好比*.example.org。这个证书匹配www.example.org，可是不匹配example.org和www.sub.example.org。这两种方法能够结合在一块儿——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既能够是确切的名字，也能够是通配符，好比example.org和*.example.org。

最好将带有多个名字的证书和它的密钥文件配置在http配置块中，这样能够只保存一分内容拷贝，全部主机的配置都从中继承：

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），它容许浏览器和服务器进行SSL握手时，将请求的主机名传递给服务器，所以服务器能够知道使用哪个证书来服务这个链接。但SNI只获得有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息：

Opera 8.0；
MSIE 7.0（仅在Windows Vista操做系统及后续操做系统）；
Firefox 2.0和使用Mozilla平台1.8.1版本的其余浏览器；
Safari 3.2.1（Windows版须要最低Vista操做系统）；
Chrome（Windows版须要最低Vista操做系统）。

经过SNI只能传递域名，可是，当请求中包含可读的IP地址时，某些浏览器将服务器的IP地址做为服务器的名字进行了传送。这是一个错误，你们不该该依赖于这个。

为了在nginx中使用SNI，那么不管是在编译nginx时使用的OpenSSL类库，仍是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL经过“--enable-tlsext”配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示以下信息：

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

可是，当开启SNI支持的nginx被动态连接到不支持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支持状态信息。
从0.7.14版本开始，listen指令支持ssl参数。
从0.5.32版本开始，支持SNI。
从0.5.6版本开始，支持SSL会话缓存，并可在工做进程间共享。

0.7.6五、0.8.19及之后版本，默认SSL协议是SSLv三、TLSv一、TLSc1.1和TLSv1.2（若是OpenSSL库支持）。
0.7.6四、0.8.18及之前版本，默认SSL协议是SSLv二、SSLv3和TLSv1。

1.0.5及之后版本，默认SSL密码算法是HIGH:!aNULL:!MD5。
0.7.6五、0.8.20及之后版本，默认SSL密码算法是HIGH:!ADH:!MD5。
0.8.19版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM。
0.7.6四、0.8.18及之前版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP。

做者: Igor Sysoev编辑: Brian Mercer翻译: cfsego