Working certificate renewal fails without changes to web server

Ok, tearing my hair out after trying to troubleshoot this issue. I rarely ask on forums but this is too hard for me. You might like the challenge if you're into this sort of thing.

Server unchanged for months, certificate renewal spontaneously stops working without any configuration changes. Yes, this worked plenty, yes, I did not touch the server, yes, this fails now (????)

Fails for dry-run and for "real".

Anyway, the details:

My domain is:

I ran this command:

sudo certbot renew

The command is in a crontab with --quiet flag, inteded to fetch a new certificate once a month and it worked just fine before more than once as you can see here:

The have 6 logs from 3 different dates

Now, without any changes to the server, it's configuration, or the application, renewal no longer works and it produced this output -v for verbose (I assume):

$ sudo certbot renew -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate for
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Challenge failed for domain
http-01 challenge for

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Type: unauthorized
Detail: 2600:3c00::f03c:92ff:fedf:7aae: Invalid response from 404

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Cleaning up challenges
Failed to renew certificate with error: Some challenges have failed.

1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

nginx version: nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version):

Ubuntu 20.04.6 LTS

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):


I'm using a control panel to manage my site (no, or provide the name and version of the control panel):


The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 2.8.0

You might find the nginx config intestesting too:

server {

location /static {
    alias /path/redacted;
} # the static folder 

location / {
    proxy_pass http://localhost:6969;
    include /etc/nginx/proxy_params;
    proxy_redirect off;
} # the python app 

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/; # 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 = {
return 301 https://$host$request_uri;
} # managed by Certbot

listen 80;
return 404; # managed by Certbot


This should just work as it has before:

Finally, the obvious solution is that nginx is down, but that's not the case. Nginx and my site are up, I confiremd that by pasting the url for the challenge ...](

... into my broswer and I am greeted by the nginx error screen, so no server is off issue.

So... Yeah?!?? Cheers

Your IPv4 and IPv6 react differently. And also it looks like the HTTP -> HTTPS redirect which is visible in your config snippet isn't working.

IPv4 HTTP: 404 file not found
IPv6 HTTP: nginx welcome page
IPv4 HTTPS: huge "Net Net App" HTML page
IPv6 HTTPS: Connection refused error

Please show the entire output of sudo nginx -T


Are you saying it's my nginx config? I've got another website running for a customer on the same server, that one renews fine but I think you're right, there could be a misconfiguration. I'll investigate and post will post the output later

That would be my first suspect, yes.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.