Auto and Manual Cert renewal failed

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: openhab.beatrixlay.com

I ran this command: sudo certbot renew --dry-run -v

It produced this output:`Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/openhab.beatrixlay.com.conf


Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Simulating renewal of an existing certificate for openhab.beatrixlay.com
Performing the following challenges:
http-01 challenge for openhab.beatrixlay.com
Using the webroot path /var/www/openhab.beatrixlay.com for all unmatched domains.
Waiting for verification...
Challenge failed for domain openhab.beatrixlay.com
http-01 challenge for openhab.beatrixlay.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: openhab.beatrixlay.com
Type: connection
Detail: 96.245.54.64: Fetching http://openhab.beatrixlay.com/.well-known/acme-challenge/b7yL5oTpHwH3mC9bH2D16VPye24ZCX3-Epo2gx4Yo54: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

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


All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/openhab.beatrixlay.com/fullchain.pem (failure)


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

My web server is (include version): nginx

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

My hosting provider, if applicable, is: self

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

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

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

Welcome @brianlay

A couple things ... the main one is something is blocking HTTP (port 80) requests to your domain. Those worked on Nov14 when you last got a cert so something changed since then.

This is a good test site to check changes you make: Let's Debug

The other thing is your nginx server is not using the most recent cert you got on Nov14. It is using the cert you got on Nov6 which expires very soon. See: SSL Checker

That can be caused by something as simple as not reloading nginx after getting a new cert. Or, you did something different on Nov14 to get that cert that your nginx config does not know about.

1 Like

Thanks for the quick response.

Let me provide a little context for what I'm doing.

I'm using nginx as a reverse proxy for my home automation server on my home network.. both are on separate machines.

currently only port 443 is open to the nginx server.

so yes port 80 is blocked, but maybe it wasn't when I originally set everything up.

Can I get the renewal to come thorough 443, or do I need to open up port 80 for that purpose.?

Yes, you will

2 Likes

I opened up port 80 on my router but still no joy.

Here is my nginx configuration

server {
        listen 80;
        server_name         openhab.beatrixlay.com;
}
server {
        listen               443 ssl;
        server_name          openhab.beatrixlay.com;

        #Cross-Origin Resource Sharing
        add_header  'Access-Control-Allow-Origin' '*' always;
        add_header  'Access-Control-Allow_Credentials'  'true' always;
        add_header  'Access-Control-Allow-Headers' 'Authorization,Accept.Origin,DNT,X-CustomHeader,Keep-Alive,User=Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range, Range' always;
        add_header  'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH' always;
        add_header  Set-Cookie X-OPENHAB-AUTH-HEADER=1;

        ssl_certificate        /etc/letsencrypt/live/openhab.beatrixlay.com/fullchain.pem;
        ssl_certificate_key    /etc/letsencrypt/live/openhab.beatrixlay.com/privkey.pem;
        add_header             Strict-Transport-Security "max-age=31536000";

        location / {
            proxy_pass                          http://192.168.1.153:8080;
            proxy_set_header Host               $http_host;
            proxy_set_header X-Real-IP          $remote_addr;
            proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwared-Proto   $scheme;
            proxy_read_timeout                  3600;
            auth_basic                          "Username and Password Required";
            auth_basic_user_file                /etc/nginx/.htpasswd;
            proxy_set_header Authorization      "";
}
        # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                #try_files $uri $uri/ =404;
        location /.well-known/acme-challenge/ {
          root                               /var/www/openhab.beatrixlay.com;

        }
    }


So maybe I need to revise the config?

got it working by revising the nginx configuration.
Added to the listen 80 section

server {
        listen 80;
        server_name         openhab.beatrixlay.com;
        return 301          https://$server_name$request_uri;
}
server {
        listen               443 ssl;
        server_name          openhab.beatrixlay.com;

return 301 https://$server_name$request_uri;

hopefully this might help someone with a similar issue

Well, glad it is working but that wasn't how I would recommend doing it.

The reason that worked is you have a root statement in your port 443 server block that matches the webroot path you used to get the cert.

Had you just added the same root statement to your port 80 server block you'd have gotten it too and more efficiently.

We usually have people setup two location blocks to process the challenge in port 80 and redirect all others to https(port 443). I don't have an example on this machine now and since you're working that's fine.

2 Likes

Here is an nginx sample for Certbot --webroot. Setup a port 80 (HTTP) server block like:

server {
    listen 80;
    listen [::]:80;     # if using IPv6
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/certbot;       # make/use folder as you prefer
    }
    location / {
       return 301 https://$host$request_uri;
    }
}
1 Like

thanks and I still needed to open port 80 on the router?

Yes, the comms "channel" needs to be open to whatever is handling port 80 (nginx in your case)

2 Likes

thanks for the detailed explanation!

3 Likes

Even though I successfully renewed the cert, it appears the server is not using it.
When I try to connect I get a warning.

of course it would have helped to restart the server...

2 Likes

Yes :slight_smile: You can add a --deploy-hook so that Certbot reloads nginx each time it gets a fresh cert.

If you just have the one cert, or all of them use --webroot and nginx, do this command to add it to that cert's renewal profile

sudo certbot renew --deploy-hook X

Where X is the quoted command to reload nginx. Probably something like:

"systemctl reload nginx"
2 Likes