Nginx：配置 HTTPS 服务器 _Linux伊甸园开源社区-24小时滚动更新开源资讯，全年无休！

要配置一个https服务，配置中的ssl参数必须按照listening sockets 在服务中的配置，而且本地的服务端证书和私钥文件必须明确：

            
                        server {
    listen              443 **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;
    ...}

服务端证书是一个公钥，用来发送到连接到此服务的没一个客户端。这个私钥是一个安全实体保存在文件中用来验证客户端的通信，并且，该文件必须可以供nginx主进程访问。这个私钥文件可以跟证书文件保存在同一个文件中。

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

为了让文件正确的访问，应该增加相应的限制。尽管证书文件和私钥文件保存在同一个文件中，但只发送证书内容给客户端。

指导文件ssl_protocols 和 ssl_ciphers 可以用来限制各种连接，只包含有最安全可靠版本的SSL/TLS的加密套件。默认情况下nginx使用的是 ssl_protocols TLSv1 TLSv1.1 TLSv1.2” 和 “ssl_ciphers HIGH:!aNULL:!MD5”，所以如果没有特殊要求可以使用默认配置。值得注意的是这些指导文件中的默认配置有时候是需要更改的。

#### HTTPS 服务优化

SSL 操作会消耗额外的 CPU 资源。在多处理器系统中，多个工作进程都将会被运行，但它不应该少于可用的 CPU 核心数。最密集的 CPU 操作是 SSL 握手。有两种方法可以减少每个客户端的这些操作：第一是通过可授权的保活连接，在一次连接中发送多次请求；第二点是通过并行和分布式连接来重用 SSL 会话参数去避免 SSL 握手。会话被存储在一个 SSL 会话缓存（session cache）中，通过 ssl会话缓存（ssl_session_cache）指令在被配置过的工作进程（worker）间共享。 1MB 的缓存包含着大约 4000 个会话信息。默认的缓存超时时间是 5 分钟。如果要增加超时时间可以使用 ssl会话超时（ssl_session_timeout）指令。下面是一个针对多核系统，大约有 10MB 共享的优化配置案例。

            
                        **worker_processes auto**;http {
    **ssl_session_cache   shared:SSL:10m**;
    **ssl_session_timeout 10m**;
 
    server {
        listen              443 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 证书链

一些浏览器可能会对一些有知名证书颁发机构的签名证书不信任，而其他浏览器可能认为该证书没有问题。出现这种情况是因为证书签发机构使用中级证书来签发服务器证书，而这个中级证书不存在部分浏览器分发的知名可信颁发证书库中。在这种情况下证书颁发机构需要提供一组证书链，这个证书链应该链路到签名的服务器证书。服务器证书必须出现在组合文件中的证书链之前。

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

生成的文件应该在ssl_certificate 命令使用：

            
                        server {
    listen              443 ssl;
    server_name         www.example.com;
    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尝试使用私钥和证书链中的第一张证书来匹配，而不是服务器证书。

浏览器通常存储他们接受的并且由可信的CA 签名的中级证书，所以经常使用的浏览器可能包含了请求中的中级证书，并且可能不会在没有证书链情况下对发送的证书而告警。为了确保服务端发送了完整的证书链，可以使用 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的主题，其由发行者是证书＃2的主题，由知名CA ValiCert，Inc.签名，其证书存储在浏览器的内置证书库（位于Jack构建的房子中）中。

如果未添加证书链，则仅显示服务器证书＃0。

####一个简单的http/https服务

配置一个可以处理http和https请求的简单服务配置:

            
                        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.7.14之前SSL不能选择性启用针对单个的套接字监听，只能使用SSL指令为整个服务启用SSL，从而无法设置单个的HTTP/HTTPS服务。于是添加了listen指令ssl参数来解决此问题。因此不建议在新版本中使用SSL伪指令

####在基于HTTPS名称的服务中

当配置两个或者多个https服务监听单个ip地址时常见的一个问题：

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

使用该配置，浏览器会接收默认的服务器证书，即：www.example.com，无论请求的服务器名称是什么。都是由SSL的协议行为造成的。在SSL连接建立前浏览器发送一个HTTP请求，但nginx并不知道请求中的服务器名称是什么。因此，只能提供默认的服务器证书。

解决该问题最原始最可靠的办法是为每个https服务分配一个单独的ip地址：

            
                        server {
    listen          192.168.1.1:443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...}server {
    listen          192.168.1.2:443 ssl;
    server_name     www.example.org;
    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 ssl;
    server_name     www.example.com;
    ...}server {
    listen          443 ssl;
    server_name     www.example.org;
    ...}

#####服务器名称指令

在单个IP地址上运行多个HTTPS服务，有一个更通用的解决方案，那就是TLS服务名称扩展指令TLS Server Name Indication extension (SNI, RFC 6066),它允许浏览器在SSL握手期间传递请求的服务器名称，因此服务器将知道哪个证书它应该用于连接。然而，只有有限的浏览器支持SNI。目前浏览器中以下版本开始支持：

Opera 8.0;
MSIE 7.0 (但只适用于 Windows Vista 及以上的版本);
Firefox 2.0 及其它使用 Mozilla Platform rv:1.8.1 的浏览器 ;
Safari 3.2.1 (Windows Vista 支持 SNI 或更高版本);
Chrome (Windows Vista 支持 SNI 或更高版本).

只有域名能在 SNI 中传递，然而，如果请求中包括服务器 IP 地址，会错误的传递ip地址作为服务器的名称。因此，不应依赖这项命令。

为了在nginx中使用SNI，必须在已经构建nginx二进制的OpenSSL库以及在运行时的动态链接库中支持它。 OpenSSL支持SNI自0.9.8f版本起，如果它是用配置选项“ - enable-tlsext”构建。因为OpenSSL 0.9.8j此选项默认情况下启用。如果nginx是用SNI支持构建的，那么当使用“-V”开关运行时，nginx会显示这一点：

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

然而，如果支持SNI的nginx动态链接的openssl库不支持SNI，那么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

####兼容性

SNI支持的状态可以用“-v”选项来显示从0.8.21 到 0.7.62版本.
支持SSL参数指令 listen的从 0.7.14.开始，在0.8.21版本之前它只能与默认参数一起指定。
从 0.5.23版开始支持SNI.
从 0.5.6开始支持SSL共享缓存.
版本 1.9.1和更高版本：默认SSL协议是TLSv1，TLSv1.1和TLSv1.2（如果OpenSSL库支持）。
版本 0.7.65,0.8.19和更高版本：默认SSL协议是SSLv3，TLSv1，TLSv1.1和TLSv1.2（如果OpenSSL库支持）
版本 0.7.64,0.8.18和更早版本：默认SSL协议是SSLv2，SSLv3和TLSv1。
版本 1.0.5和更高版本：默认SSL密码为“HIGH：！aNULL：！MD5”。
版本 0.7.65,0.8.20和更高版本：默认SSL密码为“HIGH：！ADH：！MD5”。
版本 0.8.19：默认SSL加密是“ALL：！ADH：RC4 + RSA：+ HIGH：+ MEDIUM”。
版本 0.7.64,0.8.18和更早版本：默认SSL密码为“ALL：！ADH：RC4 + RSA：+ HIGH：+ MEDIUM：+ LOW：+ SSLv2：+ EXP”。

新闻

软件

博客

论坛

商城

人才

广告

联系

投稿

3G Eden

RSS

Nginx：配置 HTTPS 服务器

英文原文：Nginx: Configuring HTTPS servers