nginx 配置https

参考文档：nginx 文档 -- nginx官网|nginx下载安装|nginx配置|nginx教程

配置 HTTPS 服务器

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

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

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.2 TLSv1.3;
    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.2 TLSv1.3” 和”ssl_ciphers HIGH:!aNULL:!MD5”, 因此，通常不需要显式配置它们。请注意，这些指令的默认值已更改多次。

HTTPS 服务器优化

SSL作会消耗额外的 CPU 资源。在多处理器系统上，应该运行多个工作进程，不少于可用 CPU 内核数。 CPU 最密集的作是 SSL 握手。有两种方法可以最大程度地减少每个客户端的这些作数：第一种是通过启用 keepalive 连接来发送多个请求通过一个连接，第二个连接是重用 SSL 会话参数来避免并行和后续连接的 SSL 握手。会话存储在 worker 之间共享的 SSL 会话缓存中并由 ssl_session_cache 指令配置。 1 MB 的缓存包含大约 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.2 TLSv1.3;
        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;
    ...
}

如果服务器证书和捆绑包在错误的 order 时，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 由颁发者签名（“i”），它本身就是证书 #1 的主题，它由颁发者签名，该颁发者本身就是证书 #2 的使用者，它由知名颁发者 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 指令为整个服务器启用使得无法设置单个 HTTP/HTTPS 服务器。这 ssl listen 指令的参数已添加以解决该问题。 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 证书

还有其他方法允许共享单个 IP 地址在多个 HTTPS 服务器之间。但是，它们都有其缺点。一种方法是使用具有多个名称的证书 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;
    ...
}

服务器名称指示

在单个 HTTPS 服务器上运行多个 HTTPS 服务器的更通用的解决方案 IP 地址为 TLS 服务器名称指示扩展（SNI、RFC 6066）、它允许浏览器在 SSL 握手期间传递请求的服务器名称因此，服务器将知道它应该使用哪个证书对于连接。 SNI 目前大多数现代浏览器都支持，但某些旧客户端或特殊客户端可能不支持 SNI。

SNI 中只能传递域名，但是，某些浏览器可能会错误地传递服务器的 IP 地址作为其名称（如果请求包含文本 IP 地址）。我们不应该依赖这个。

为了在 nginx 中使用 SNI，它必须在构建 nginx 二进制文件时使用的 OpenSSL 库以及在运行时动态链接到的库。如果 OpenSSL 是使用配置选项 “--enable-tlsext” 构建的，则从 0.9.8f 版本开始支持 SNI。从 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

兼容性

SNI 支持状态已由“-V”开关显示自 0.8.21 和 0.7.62 起。
这ssl从 0.7.14 开始支持 listen 指令的参数。在 0.8.21 之前，它只能与default参数。
从 0.5.23 开始支持 SNI。
从 0.5.6 开始支持共享 SSL 会话缓存。

版本 1.27.3 及更高版本：默认 SSL 协议为 TLSv1.2 和 TLSv1.3（如果 OpenSSL 库支持）。否则，当使用 OpenSSL 1.0.0 或更早版本时，默认 SSL 协议为 TLSv1 和 TLSv1.1。
版本 1.23.4 及更高版本：默认 SSL 协议为 TLSv1， TLSv1.1、TLSv1.2 和 TLSv1.3（如果 OpenSSL 库支持）。
版本 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”.

参考文档：nginx 文档 -- nginx官网|nginx下载安装|nginx配置|nginx教程