配置 HTTPS 服务器

• HTTPS 服务器优化
• SSL 证书链
• 单个 HTTP/HTTPS 服务器
• 基于名称的 HTTPS 服务器
  • 具有多个名称的 SSL 证书
  • 服务器名称指示
• Compatibility

要配置 HTTPS 服务器，必须在server块中的listening sockets上启用ssl参数，并且应指定server certificate和private key文件的位置：

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”，因此通常不需要显式配置它们。请注意，这些指令的默认值是changed数倍。

HTTPS 服务器优化

SSL 操作会消耗额外的 CPU 资源。在 multiprocessing 器系统上，应运行多个worker processes，不少于可用的 CPU 内核数。最耗 CPU 的操作是 SSL 握手。有两种方法可以最大程度地减少每个客户端的这些操作数量：第一种方法是通过启用keepalive连接通过一个连接发送多个请求，第二种方法是重用 SSL 会话参数，以避免并行和后续连接的 SSL 握手。会话存储在工作程序之间共享的 SSL 会话缓存中，并由ssl_session_cache指令配置。一兆字节的缓存包含大约 4000 个会话。默认的缓存超时为 5 分钟。可以通过使用ssl_session_timeout指令来增加它。这是针对具有 10 MB 共享会话缓存的多核系统进行优化的示例配置：

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 尝试将私有密钥与 Binding 包的第一个证书一起使用，而不是服务器证书。

浏览器通常存储接收到的并由受信任的 Authority 机构签名的中间证书，因此活跃使用的浏览器可能已经具有所需的中间证书，并且可能不会抱怨没有链式 Binding 包发送的证书。为了确保服务器发送完整的证书链，可以使用openssl命令行 Util，例如：

$ 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”)由本身是证书#1 主题的发行者(“ i”)签名，证书本身由作为主题的发行者签名的证书#1 证书#2，由著名发行人 ValiCert，Inc.签名，证书存储在浏览器的内置证书库(位于 Jack 所建房屋中)中。

如果尚未添加证书 Binding 包，则仅显示服务器证书#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;
    ...
}

基于名称的 HTTPS 服务器

配置两个或多个侦听单个 IP 地址的 HTTPS 服务器时，会出现一个常见问题：

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 协议行为引起的。在浏览器发送 HTTP 请求之前，已构建 SSL 连接，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 服务器名称指示扩展(SNI，RFC 6066)，它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道应使用哪个证书。用于连接。目前，大多数现代浏览器都使用supported SNI，尽管某些老客户或特殊客户可能不会使用 SNI。

为了在 nginx 中使用 SNI，必须在已构建 nginx 二进制文件的 OpenSSL 库以及在运行时将其动态链接到的库中都支持它。如果 OpenSSL 使用配置选项“ --enable-tlsext”构建，则从 0.9.8f 版本开始支持 SNI。从 OpenSSL 0.9.8j 开始，默认情况下启用此选项。如果 nginx 是使用 SNI 支持构建的，那么当使用“ -V”开关运行时，nginx 将显示此信息：

$ 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

Compatibility

• 从 0.8.21 和 0.7.62 开始，“-V”开关显示了 SNI 支持状态。

• 自 0.7.14 开始支持listen指令的ssl参数。在 0.8.21 之前，只能与default参数一起指定。

• 自 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”。

由 Igor Sysoev 写
Brian Mercer 编辑