I have installed an application "load balancer", on a Ubuntu 14.04 LTS server with nginx 1.4 (the version handled in this Ubuntu release). Now we are in the process of emergency update of the servers with versions already without updates, outdated.
The problem happens with a vhost in nginx, its configuration works fine in nginx 1.4/trusty but ... the same fails in nginx 1.14/bionic, the problem is with https requests.
the vhost configuration is as follows:
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;
}
}
and, I repeat, it works fine on the old Trusty server, but when I put the new Bionic server in the same role, this vhost fails. Let's Encrypt based certificates (via certbot) is discarded as the cause of the problem, the certificates are the same but if I "force-install" Trusty's nginx-common/nginx-core *.deb files on the new server in Bionic (trick using dpkg -i . ..) and I launch the service, the access to vhost by https works, that makes me suppose that it is a configuration problem that before was accepted by ngninx 1.4 but now it is not by nginx 1.14.
curl access fails with the following error:
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.
on the current server at Trusty, and when I force-install the nginx packages from Trusty to the new server with Bionic, it works:
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"}}
