配置 HTTPS 服务器

要配置 HTTPS 服务器，必须在 server 块中的 监听套接字 上启用 ssl 参数，并且指定服务器证书 和 私钥文件 的位置：

  1. server {
  2.     listen              443 ssl;
  3.     server_name         www.example.com;
  4.     ssl_certificate     www.example.com.crt;
  5.     ssl_certificate_key www.example.com.key;
  6.     ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  7.     ssl_ciphers         HIGH:!aNULL:!MD5;
  8.     ...
  9. }

服务器证书是一个公共实体。它被发送到每个连接到服务器的客户端。私钥是一个安全实体，存储在一个访问受限的文件中，但是它对 nginx 的主进程必须是可读的。私钥也可以存储在与证书相同的文件中：

  1. ssl_certificate     www.example.com.cert;
  2. 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 资源。在多处理器系统上，应该运行多个 工作进程（worker process），不得少于可用 CPU 核心的数量。大多数 CPU 密集型操作是发生在 SSL 握手时。有两种方法可以最大程度地减少每个客户端执行这些操作的次数。首先，启用 keepalive 连接，通过一个连接来发送多个请求，第二个是复用 SSL 会话参数，避免相同的和后续的连接发生 SSL 握手。会话存储在工作进程间共享的 SSL 会话缓存中，由 ssl_session_cache 指令配置。1MB 缓存包含约 4000 个会话。默认缓存超时时间为 5 分钟，可以用 ssl_session_timeout 指令来增加。以下是一个优化具有 10MB 共享会话缓存的多核系统的配置示例：

  1. worker_processes auto;
  3. http {
  4.     ssl_session_cache   shared:SSL:10m;
  5.     ssl_session_timeout 10m;
  7.     server {
  8.         listen              443 ssl;
  9.         server_name         www.example.com;
  10.         keepalive_timeout   70;
  12.         ssl_certificate     www.example.com.crt;
  13.         ssl_certificate_key www.example.com.key;
  14.         ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  15.         ssl_ciphers         HIGH:!aNULL:!MD5;
  16.         ...

SSL 证书链

某些浏览器可能会不承认由知名证书颁发机构签发的证书，而其他浏览器可能会接受该证书。之所以发生这种情况，是因为颁发机构已经在特定浏览器分发了一个中间证书，该证书不存在于知名可信证书颁发机构的证书库中。在这种情况下，权威机构提供了一系列链式证书，这些证书应该与已签名的服务器证书相连。服务器证书必须出现在组合文件中的链式证书之前：

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

在 ssl_certificate 指令中使用生成的文件：

  1. server {
  2.     listen              443 ssl;
  3.     server_name         www.example.com;
  4.     ssl_certificate     www.example.com.chained.crt;
  5.     ssl_certificate_key www.example.com.key;
  6.     ...
  7. }

如果服务器证书与捆绑的链式证书的相连顺序错误，nginx 将无法启动并显示错误消息：

  1. SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
  2.    (SSL: error:0B080074:x509 certificate routines:
  3.     X509_check_private_key:key values mismatch)

因为 nginx 已尝试使用私钥和捆绑的第一个证书而不是服务器证书。

浏览器通常会存储他们收到的中间证书，这些证书由受信任的机构签名，因此积极使用这些存储证书的浏览器可能已经具有所需的中间证书，不会发生不承认没有链接捆绑发送的证书的情况。可以使用 openssl 命令行工具来确保服务器发送完整的证书链，例如：

  1. $ openssl s_client -connect www.godaddy.com:443
  2. ...
  3. Certificate chain
  4.  0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
  5.      /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
  6.      /OU=MIS Department/CN=www.GoDaddy.com
  7.      /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
  8.    i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
  9.      /OU=http://certificates.godaddy.com/repository
  10.      /CN=Go Daddy Secure Certification Authority
  11.      /serialNumber=07969287
  12.  1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
  13.      /OU=http://certificates.godaddy.com/repository
  14.      /CN=Go Daddy Secure Certification Authority
  15.      /serialNumber=07969287
  16.    i:/C=US/O=The Go Daddy Group, Inc.
  17.      /OU=Go Daddy Class 2 Certification Authority
  18.  2 s:/C=US/O=The Go Daddy Group, Inc.
  19.      /OU=Go Daddy Class 2 Certification Authority
  20.    i:/L=ValiCert Validation Network/O=ValiCert, Inc.
  21.      /OU=ValiCert Class 2 Policy Validation Authority
  22.      /CN=http://www.valicert.com//emailAddress=info@valicert.com
  23. ...

在本示例中，www.GoDaddy.com 服务器证书 ＃0 的主体（“s”）由发行机构（“i”）签名，发行机构本身是证书 ＃1 的主体，是由知名发行机构 ValiCert, Inc. 签署的证书 ＃2 的主体，其证书存储在浏览器的内置证书库中。

如果没有添加证书包（certificate bundle），将仅显示服务器证书 ＃0。

HTTP/HTTPS 服务器

可以配置单个服务器来处理 HTTP 和 HTTPS 请求：

  1. server {
  2.     listen              80;
  3.     listen              443 ssl;
  4.     server_name         www.example.com;
  5.     ssl_certificate     www.example.com.crt;
  6.     ssl_certificate_key www.example.com.key;
  7.     ...
  8. }

在 0.7.14 之前，无法为各个 socket 选择性地启用 SSL，如上所示。只能使用 ssl 指令为整个服务器启用 SSL，从而无法设置单个 HTTP/HTTPS 服务器。可以通过添加 listen 指令的 ssl 参数来解决这个问题。因此，不建议在现在的版本中使用 ssl 指令。

基于名称的 HTTPS 服务器

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

  1. server {
  2.     listen          443 ssl;
  3.     server_name     www.example.com;
  4.     ssl_certificate www.example.com.crt;
  5.     ...
  6. }
  8. server {
  9.     listen          443 ssl;
  10.     server_name     www.example.org;
  11.     ssl_certificate www.example.org.crt;
  12.     ...
  13. }

使用了此配置，浏览器会接收默认服务器的证书，即 www.example.com，而无视所请求的服务器名称。这是由 SSL 协议行为引起的。SSL连接在浏览器发送 HTTP 请求之前建立，nginx 并不知道请求的服务器名称。因此，它只能提供默认服务器的证书。

最古老、最强大的解决方法是为每个 HTTPS 服务器分配一个单独的 IP 地址：

  1. server {
  2.     listen          192.168.1.1:443 ssl;
  3.     server_name     www.example.com;
  4.     ssl_certificate www.example.com.crt;
  5.     ...
  6. }
  8. server {
  9.     listen          192.168.1.2:443 ssl;
  10.     server_name     www.example.org;
  11.     ssl_certificate www.example.org.crt;
  12.     ...
  13. }

具有多个名称的 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 级配置，以便在所有服务器中继承其单个内存副本：

  1. ssl_certificate     common.crt;
  2. ssl_certificate_key common.key;
  4. server {
  5.     listen          443 ssl;
  6.     server_name     www.example.com;
  7.     ...
  8. }
  10. server {
  11.     listen          443 ssl;
  12.     server_name     www.example.org;
  13.     ...

服务器名称指示

在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（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（支持 SNI 的 Windows 版本需要 Vista 或更高版本）
  • Chrome（支持 SNI 的 Windows 版本需要 Vista 或更高版本）

只有域名可以在 SNI 中传递，然而，如果请求包含 IP 地址，某些浏览器可能会错误地将服务器的 IP 地址作为名称传递。不应该依靠这个。

要在 nginx 中使用 SNI，其必须支持构建后的 nginx 二进制的 OpenSSL 库以及在可在运行时动态链接的库。自 0.9.8f 版本起（OpenSSL），如果 OpenSSL 使用了配置选项 --enable-tlsext 构建，是支持 SNI 的。自 OpenSSL 0.9.8j 起，此选项是默认启用。如果 nginx 是用 SNI 支持构建的，那么当使用 nginx -V 命令时 ，nginx 会显示：

  1. $ nginx -V
  2. ...
  3. TLS SNI support enabled
  4. ...

但是，如果启用了 SNI 的 nginx 在没有 SNI 支持的情况下动态链接到 OpenSSL 库，那么 nginx 将会显示警告：

  1. nginx was built with SNI support, however, now it is linked
  2. dynamically to an OpenSSL library which has no tlsext support,
  3. therefore SNI is not available

兼容性

  • 从 0.8.21 和 0.7.62 起，SNI 支持状态通过 -V开关显示。
  • 从 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 编辑

原文档