我在装有 nginx 1.4（此 Ubuntu 版本中处理的版本）的 Ubuntu 14.04 LTS 服务器上安装了应用程序“负载平衡器”。现在我们正在对服务器进行紧急更新，这些服务器的版本已经过时，没有更新。
问题发生在 nginx 中的 vhost 上，其配置在 nginx 1.4/trusty 中运行良好，但是……在 nginx 1.14/bionic 中同样失败，问题在于https要求。
vhost配置如下：
upstream webservices {
server services;
}
server {
listen 80;
listen 443 ssl;
server_name abc.services.domain.com def.services.domain.com *.services.domain.com;
ssl_certificate /etc/letsencrypt/live/services.domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/services.domain.com/privkey.pem;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_prefer_server_ciphers on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA';
ssl_dhparam /etc/ssl/lp/services.domain.com/dhparams.pem;
access_log /var/log/nginx/services_log;
error_log /var/log/nginx/services_error_log;
location / {
proxy_pass http://webservices;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 600;
}
}
我再说一遍，它在旧的 Trusty 服务器上运行良好，但当我将新的 Bionic 服务器置于相同角色时，此虚拟主机就会失败。基于 Let's Encrypt 的证书（通过 certbot）被丢弃，这是导致问题的原因，证书是相同的，但如果我在 Bionic 中的新服务器上“强制安装”Trusty 的 nginx-common/nginx-core *.deb 文件（使用 dpkg -i 技巧...）并启动服务，则可以通过 https 访问虚拟主机，这让我认为这是一个配置问题，之前 ngninx 1.4 可以接受，但现在 nginx 1.14 不能接受。
curl访问失败并出现以下错误：
curl -v "https://api.services.domain.com/cron/taskrun/fast?limit=10&orderBy=id&orderType=DESC&page=1"
* Trying XX.XX.XX.XX...
* Connected to api.services.domain.com (XX.XX.XX.XX) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
在 Trusty 的当前服务器上，当我使用 Bionic 将 Trusty 中的 nginx 包强制安装到新服务器时，它可以正常工作：
curl -v "https://api.services.domain.com/cron/taskrun/fast?limit=10&orderBy=id&orderType=DESC&page=1"
* Connected to api.services.littlepassports.com (XX.XX.XX.XX) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: CN=*.services.littlepassports.com
* start date: 2020-05-19 21:07:19 GMT
* expire date: 2020-08-17 21:07:19 GMT
* subjectAltName: api.services.littlepassports.com matched
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /cron/taskrun/fast?limit=10&orderBy=id&orderType=DESC&page=1 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: api.services.domain.com
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
* Server nginx/1.4.6 (Ubuntu) is not blacklisted
< Server: nginx/1.4.6 (Ubuntu)
< Date: Fri, 07 Aug 2020 20:53:15 GMT
< Content-Type: application/json
< Content-Length: 60
< Connection: keep-alive
< Access-Control-Allow-Methods: GET, PUT, POST, PATCH, DELETE, OPTIONS
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: origin, content-type, accept, Authorization
< Access-Control-Allow-Credentials: true
<
* Connection #0 to host api.services.domain.com left intact
{"data":{"message":"Invalid token.","code":"token.invalid"}}