I have managed to reproduce the error on a new test system. It has occured after installing certbot and a certificate
sudo certbot --nginx -d demo.saltalafila.online
Before certbot, I could call:
curl demo.saltalafila.online and get a response. http served up the same content.
After installing the certificate the response would be 301 Moved Permanently nginx/1.18.0 (Ubuntu) as FF was working upon some form of cache via http (forced somehow, but the redirect set with nginx did not work). browser invoking https would return response as expected. But..
curl https://demo.saltalafila.online curl: (60) SSL certificate problem: Invalid certificate chain
I'll place below the default nginx configuration, however I do need to point out that a consistent error popped up (as experienced with the other server) after having confirmed the cert issuance: any changes made to the configuration file would pass the sudo nginx -t test. but sudo service nginx restart would fail because of an error regarding systemctl[I did not capture it, alas]. Reboot becomes necessary. Certbot (certbot 0.40.0) touches something there in an inopportune manner.
How did I get to that? Because I tried to roll back and remove all entries made by cerbot to the conf file. (interestingly, Firefox, even with "http" specified still forced https and thus could not connect. Another browser confirmed the http response)
Following is the conf file for nginx. The first block is the edited default nginx file. Certbot generated a second (and third!) server block, repeating content from the initial block (hello DRY!)
server {
listen 80 default_server;
listen [::]:80 default_server;
root /home/deploy/default;
index index.html;
server_name demo.salalafila.online;
location / {
try_files $uri $uri/ =404;
}
}
server {
root /home/deploy/default;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name demo.saltalafila.online; # managed by Certbot
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
certbot
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/demo.saltalafila.online/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/demo.saltalafila.online/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
server {
if ($host = demo.saltalafila.online) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name demo.saltalafila.online;
return 404; # managed by Certbot
}
It appears one will need to resort to manually editing the file and rebooting.
• The former may be acceptable (proper nginx form suggestions welcome),
• the latter is still an issue, as it will rear its head upon every call to renew via certbot & is certainly a bona fide bug.
Le initial issue with curl remains somehow the protocol call is not connecting to the certificate.
