关于nginx:HTTPS基础原理和配置3

书接上文：HTTPS 根底原理和配置 – 2，接下来介绍：

配置 NGINX
后端 HTTPS
查看配置
配置 HSTS
OCSP Stapling

重要局部来了。如何应用这些选项并配置 NGINX?

这里有一些根本的原语（或叫做指令），你能够应用:ssl_certificate、ssl_certificate_key、ssl_protocols 和 ssl_ciphers。

在开始之前: NGINX 解决 TLS 的形式是应用 OpenSSL，我置信你曾经在新闻中据说过这个库。它因 Heartbleed 和其余一些破绽而闻名。它的确是最宽泛应用的内置加密库。这是 NGINX 用于加密的。

因而，在服务器上要做的一件事是查看正在应用的 OpenSSL 版本。你可能不想应用 0.9.8 之类的版本。你心愿在 1.0.1p 或 1.0.2 范畴内应用，因为多年来他们曾经修复了许多 bug。你永远不晓得下一个 OpenSSL 破绽什么时候呈现，但至多当初它是十分牢靠的 (1.0.1p)。它还领有所有古代加密算法。

所以，当你在 NGINX 中设置你的服务器局部时，ssl_certificate 就是你的证书链。这是你的证书加上所有的信赖链始终到根证书。而后你还须要提供你的私钥。

ssl_certificate_key 就是你的私钥。

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
    ssl_dhparam /path/to/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
}

你还能够增加一些与会话复原无关的额定选项。如前所述，当你第一次建设 TLS 连贯时，须要额定的两次往返，因为你必须实现整个握手和替换证书。如果你以前连贯过一个客户端，并且他们曾经缓存了会话传输所应用的密钥，那么你能够只复原该会话。这是一个称为会话复原的个性。

你只须要一个超时来阐明你心愿将会话保留多长时间，以及这些会话的缓存能够有多大。在本例中，默认是 10 MB 的会话; 那应该够你用很长时间了。共享缓存是首选，因为这样你就能够在所有 NGINX worker 之间共享它们。

例如，如果你的一个 worker 是最后建设连贯的那个，而第二个连贯被建设到另一个 NGINX worker，你依然能够复原连贯。还有另一个选项叫做「session ticket」。它只在 Chrome 内核浏览器和 Firefox 中应用，但实质上是一样的。你必须生成一个随机的 48 字节文件，但我倡议临时只应用会话缓存。

作为一个非常明显的下一步，你必须列出心愿反对的协定和明码。在这种状况下，上文是 Mozilla 举荐的明码，以及从 1.2 版到 1.3 版的 TLS 协定。

我提到过你如何协商你抉择的明码; 你能够抉择客户端的抉择或服务器的抉择。最好抉择服务器的抉择。这里有一个指令: ssl_prefer_server_ciphers——始终关上它。

如果你有多个站点，并且它们应用雷同的证书，那么你实际上能够合成 HTTP 定义。你能够在顶层应用 SSL 证书，在底层应用不同的服务器。这里你须要记住的一件事是如果你有 example.com 和 example.org，你必须有一个证书对这两个名字都无效，这样能力工作。

ssl_certificate        multiSAN.crt;
ssl_certificate_key    multiSAN.key;

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

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

以上基本上就是为 NGINX 设置 HTTPS。

更高级的话题是: 如何应用 NGINX 作为其余 HTTPS 服务的代理?

咱们称之为后端加密。所以，你的访客拜访你的 NGINX 服务器是齐全加密的。NGINX 背地产生了什么? 在这种状况下，NGINX 必须充当浏览器拜访你的后端服务。

这能够在 NGINX 中以相似的形式配置。也有相似于 ssl_protocols 和 ssl_ciphers 的指令; 在本例中，你将它放在一个代理下。NGINX 作为客户端将应用 proxy_ssl_protocols 和 proxy_ssl_cipher 指令。

http {
    server {
        proxy_ssl_protocols        TLSv1.2 TLSv1.3;    # 协定
        proxy_ssl_ciphers        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;    # 明码套件
        proxy_ssl_trusted_certificate    /etc/ssl/certs/trusted_ca_cert.crt;    # 受信赖的 CA
        
        proxy_ssl_verify        on;
        proxy_ssl_verify_depth    2;
        proxy_ssl_session-reuse    on;
    }
}

我倡议应用完全相同的明码套件和协定集。这里的次要区别是客户端对服务器进行身份验证。所以，在浏览器的状况下，你有一组你信赖的证书颁发机构，而 NGINX 作为客户端，你也须要一组你信赖的证书颁发机构。

你能够应用两种不同的理念来实现这一指标，一种是创立你本人的外部证书颁发机构并在外部治理它。这有点辣手，但它更便宜，也更容易治理，因为你能够为任何服务颁发证书，并将它们颁发给你领有并齐全管制的证书颁发机构。在这种状况下，proxy_ssl_trusted_certificate 将被设置为你的证书颁发机构。

或者，你能够应用我在上一篇文章中形容的雷同技术。你能够为你所有的服务购买证书，而后如果你的 NGINX 须要信赖它们，它能够信赖浏览器信赖的同一套证书颁发机构。

对于 Ubuntu，磁盘上有一个列表，外面蕴含了简直所有平台的所有证书。然而，如果你正在构建一组须要互相通信的大型服务，那么就很难为这些域颁发证书。你必须向证书颁发机构证实所有权能力理论取得证书。

我举荐外部 CA 机制。最艰难的局部是——如何保障证书颁发机构的平安? 如何保障证书颁发机构的私钥的平安? 你能够通过应用脱机计算机和非凡管理员来实现这一点，但无论哪种状况，都存在一些挑战。

NGINX 设置了 HTTPS。如何查看它的配置是否正确?

SSL Labs 是人们最喜爱的网站查看工具之一。SSL Labs 是 Qualys 经营的一个网站; 你只有输出你的域名，它就会运行所有类型的浏览器，所有类型的 SSL 连贯，它会通知你哪些设置正确，哪些设置谬误。

在本例中，咱们查看了一个名为 badSSL.com 的网站，它列举了所有可能导致 HTTPS 配置凌乱的不同办法。你能够用 SSL Labs 扫描每一个，它会通知你每一个有什么问题。在本例中，给出的等级是 C，因为它反对 SSL v3.0。

这里还提到了其余一些货色，你们能够批改，但在我如何设置 NGINX 的形容中，如果你这样设置，你基本上会失去 A。这意味着证书协定反对、密钥替换和明码强度都是顶级的。

这对互联网网站十分无效; 如果你有防火墙或 NGINX 前面的服务，CloudFlare 构建了这个叫做 CFSSL 扫描的工具。你能够在外部基础架构中应用它; 它是开源的，在 cloudflare/cfssl: CFSSL: Cloudflare’s PKI and TLS toolkit (github.com) 上。它将做实质上与 SSL Labs 雷同的事件，只是在你的基础设施内。它会通知你什么是对的，什么是错的。

之前提到过失去 A 的办法，那么 A+ 呢? 事实证明，SSL Labs 就会给一个 A+，当你有了一个叫做 HSTS (Hypertext Strict Transport Security，超文本严格传输平安) 的个性。

实质上，这是一个 HTTP 头，你能够增加到你的申请，通知浏览器总是通过 HTTPS 拜访这个站点。即便他们最后是通过 HTTP 拜访的，也总是重定向到 HTTPS。

然而，这实际上有一点危险，因为如果你的 SSL 配置中断或证书过期，那么访问者将无法访问该站点的纯 HTTP 版本。你还能够做一些更高级的事件。就是将你的站点增加到预加载列表中。Chrome 和火狐浏览器都有一个列表，所以如果你注册了，他们就永远不会通过 HTTP 拜访你的网站。

SSL Labs 将给你一个 A+ 如果其余所有正确的。你须要正确地设置 includeSubdomains 的 HSTS(这意味着它实用于所有子域名)，并且它必须有至多 6 个月的有效期，这使得它十分危险。这是因为如果你扭转了你的配置，浏览器将会记住这六个月。所以你必须放弃你的 HTTPS 配置失常工作。

这是一件坏事，因为它能够避免任何人在两头批改它。应用 HSTS，浏览器甚至不会有机会拜访你的 HTTP 端，因而人们不会在这方面烦扰你的站点。所以 HSTS 是一个十分牢靠的办法。

正如我提到的，有几个危险：

阻止人们通过 HTTP 拜访站点
如果 HTTPS 配置异样（比方证书过期），站点就无法访问了

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
    ssl_dhparam /path/to/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds)
    add_header Strict-Transport-Security "max-age=15768000" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    # replace with the IP address of your resolver
    resolver 127.0.0.1;
}

要设置它，只需在 NGINX 的服务器配置中增加一个头文件，下面写着 Strict-Transport-Security，并给它一个最大工夫（max-age）。在本例中，它被设置为 6 个月 (这是预加载列表所需的最低工夫)。你还能够在这里增加其余指令，如:includeSubdomains 和 preload，这意味着能够承受这个指令并将其增加到预加载列表中。这就是失去 A+ 的办法。

这是一些人喜爱应用的另一个附加性能，它实际上能够帮忙放慢连贯速度。

正如我后面提到的，建设一个 TLS 连贯须要有很多来回的。我没有提到的是，这些证书不仅能够过期生效，还能够被撤消。

因而，如果你失落了你的私钥，呈现了破绽，或者有其他人非法领有了你的私钥，那么你必须去你的证书颁发机构并撤销这个密钥。有几种机制能够通知浏览器证书已被撤消; 它们都有点粗略，但最风行的是 OCSP(Online Certificate Status Protocol，在线证书状态协定)。

产生的状况是: 当浏览器收到证书时，它还必须查看它是否被撤消了。于是它分割了证书颁发机构，问「这个证书还无效吗?」他们会答复「是」或「不是」。这自身就是另一组连贯，你须要查找 CA 的 DNS，你须要连贯到 CA，这对你的网站来说是额定的加速。

HTTPS 不只须要三次往返，你还须要 OCSP。因而，OCSP 装订容许服务器获取证书未过期的证实。在后盾，获取这个示意「是的，证书是好的」的 OCSP 响应，而后将它放入握手中。这样客户端就不须要理论接触 CA 并获取它。

残缺 HTTPS 网站拜访过程示例如下：

DNS（1334ms）
TCP 握手（240ms）
SSL 握手（376ms）
跟踪证书链（1011ms）
到 CA 的 DNS 记录（300ms）
到 CA 的 TCP（407ms）
到 CA 的 OCSP 第一次（598 ms）
到 CA 的 TCP 第二次（317ms）
到 CA 的 OCSP 第二次（444ms）
实现 SSL 握手（1270ms）

配置了 OCSP Stapling，上文的 5-9 步能够省略，这能够节俭约 30% 的拜访一个 HTTPS 网站的连接时间。

见上文（4.4 NGINX 配置 HSTS)，用 NGINX 也很容易设置。有一个 OCSP Stapling 的指令。装订验证（Stapling verify）是指在装订证书之后对其进行验证。正如我后面（2.2 受信赖的 CA 的选项）提到的，应用代理，你必须信赖 CA。你能够从 CA 取得一个文件，并通过可信证书局部增加到该文件中。

以上就是配置 NGINX 和 OCSP 装订、HSTS 和 SSL 代理的办法。

正如我提到的，在 2008 年，TLS v1.2 是最新和最好的。近期，他们推出了新版本，TLS v1.3。

HTTPS 是一个一直变动的畛域，咱们的配置及最佳实际可能也须要进行相应调整。

关于nginx:HTTPS基础原理和配置3

一、NGINX 的 HTTPS 配置

1.1 NGINX 配置参数（OpenSSL）

1.2 NGINX 配置证书链和私钥

1.3 额定选项

1.4 NGINX 的协定和明码配置

1.5 其余

1.6 同一证书多域

二、后端 HTTPS

2.1 NGINX 后端配置

2.2 受信赖的 CA 的选项

三、查看配置

3.1 CFSSL 扫描

四、加分项：配置 HSTS

4.1 什么是 HSTS？

4.2 为什么要这么做？

4.3 危险

4.4 NGINX 配置 HSTS

五、又一加分项：配置 OCSP 装订（OCSP Stapling）

5.1 什么是 OCSP Stapling

5.2 会快多少？

5.3 NGINX 配置 OCSP Stapling

总结