手把手教学|Nginx 如何配置 HTTPS 服务器

配置 HTTPS 服务器

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

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 握手。

有两种方法可以最小化每个客户机的这些操作的数量：第一种方法是允许 keepalive 连接通过一个连接发送多个请求，第二个是重用 SSL 会话参数，以避免并行连接和后续连接使用 SSL 握手。会话存储在一个 SSL 会话缓存中，在工作进程之间共享，并由 ssl_session_cache 指令配置。一个兆字节的缓存包含大约 4000 个会话。默认的缓存超时时间为 5 分钟。它可以通过使用 ssl_session_timeout 指令来增加。下面是一个为 10 兆共享会话缓存的多核系统优化的配置示例：

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

如果服务端证书和 bundle 以错误的顺序连接，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 尝试将私钥与 bundle 的第一个证书一起使用，而不是服务端证书。

浏览器通常会存储它们收到的并由受信任的权威机构签署的中间证书，因此活跃使用的浏览器可能已经拥有所需的中间证书，并且可能不会抱怨在没有链接包的情况下发送的证书。为了确保服务器发送完整的证书链，可以使用 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
...

当用 SNI 测试配置时，指定-servername 选项很重要，因为 openssl 默认情况下不使用 SNI。

在这个例子中，www.godaddy.com 服务器 0 号证书的主题(" s ")是由颁发者(" i ")签名的，而它本身就是 1 号证书的主题，它又由它的颁发者("i")签名，而它的颁发者又是 2 号证书的主题("s")，它又由著名的颁发机构 ValiCert, Inc 签名。而它的证书存储在浏览器的内置证书库中。

如果没有添加证书包，则只显示服务器 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;
    ...
}

使用此配置，浏览器将接收默认服务器的(设置了 default 参数的 server 块，或者第一个 server 块)证书，即 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 服务器名称指示扩展 (SNI, RFC 6066)，它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道它应该使用哪个证书进行连接。SNI 目前被大多数现代浏览器支持，尽管一些旧的或特殊的客户端可能不使用。

只有域名可以通过 SNI，但是如果请求包含字面 IP 地址，有些浏览器可能会错误地将服务器的 IP 地址作为其名称传递。我们不应该依赖于此。

为了在 nginx 中使用 SNI，它必须同时得到 OpenSSL 库和运行时动态链接到它的库的支持。OpenSSL 从 0.9.8f 版本开始支持 SNI，如果它是用配置选项“--enable-tlsext”构建的。从 OpenSSL 0.9.8j 开始默认情况下启用了这个选项。如果 nginx 是用 SNI 支持构建的，那么 nginx 在使用" -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 开始，SNI 支持状态一直由“-V”开关显示。
• 自 0.7.14 以来，已经支持 listen 指令的 ssl 参数。在 0.8.21 之前，它只能与默认参数一起指定。
• SNI 从 0.5.23 开始受到支持。
• 从 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”