Certbot renew without extra parameters does not work

My domain is:
metalfans.be

I ran this command:
certbot renew

It produced this output:

Simulating renewal of an existing certificate for metalfans.be

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: metalfans.be
  Type:   unauthorized
  Detail: 2a01:4f8:c2c:b6bb::1: Invalid response from http://metalfans.be/.well-known/acme-challenge/uDdjgvmEzQYwdyPNq418b5NwiYAvwE5U8F47xDIpPtY: 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.

Failed to renew certificate metalfans.be with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /pathtocert/metalfans.be/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

My web server is (include version):
nginx/1.22.1
varnish-7.1.1

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

My hosting provider, if applicable, is:

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.8.0


My server is running a nginx that handles the ssl termination for Varnish and sends the request back to the backend. This is a setup that worked for years on my old server, and now when we moved to a new server, where we started with a clean setup, it does not seem to work when running cerbot renew.

Running: certbot renew --dry-run --cert-name metalfans.be --authenticator webroot --webroot-path /var/www/metalfans.be/web works, running certbot renew without the extra parameters does not work.

Relevant part of the Nginx config:

 server {
    listen 78.46.226.218:443 ssl http2;
    listen [::1]:443 ssl http2;
   server_name  www.metalfans.be;
   #ssl                  on;
    ssl_certificate /etc/letsencrypt/live/metalfans.be/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/metalfans.be/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/metalfans.be/chain.pem;
    include  /etc/nginx/ssl/ssl.conf;
    return 301 https://metalfans.be$request_uri;
}






server {
    listen 78.46.226.218:443 ssl http2;
    listen [::1]:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/metalfans.be/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/metalfans.be/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/metalfans.be/chain.pem;
    include  /etc/nginx/ssl/ssl.conf;
    server_name metalfans.be;


########
#limits#
########
#include /etc/nginx/bots.d/blockbots.conf;
#include /etc/nginx/bots.d/ddos.conf;


 location / {
     proxy_set_header   Connection "";
     proxy_http_version 1.1;
     proxy_pass http://127.0.0.1:80;
     proxy_set_header Host $http_host;
     proxy_set_header X-Forwarded-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-Forwarded-Proto https;
     proxy_set_header X-Forwarded-Proto $scheme;
     proxy_set_header HTTPS "on";
     proxy_read_timeout 150;


    }

  }

server {
listen *:8084;
server_name metalfans.be *.metalfans.be;
       root   /var/www/metalfans.be/web;

 # Allow "Well-Known URIs" as per RFC 5785
    location ~* ^/.well-known/ {
        allow all;
    }
<rest of the server block that handles the php requests.>

Contents of the renew config file:

cat metalfans.be.conf
# renew_before_expiry = 30 days
version = 2.8.0
archive_dir = /etc/letsencrypt/archive/metalfans.be
cert = /etc/letsencrypt/live/metalfans.be/cert.pem
privkey = /etc/letsencrypt/live/metalfans.be/privkey.pem
chain = /etc/letsencrypt/live/metalfans.be/chain.pem
fullchain = /etc/letsencrypt/live/metalfans.be/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = ID removed
authenticator = nginx
installer = nginx
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

Your nginx configuration might not be compatible with the nginx authenticator which is configured in your renewal configuration file. Maybe some things were updated since you issued the cert in the beginning, making it incompatible now.

The renewal configuration file isn't updated when using --dry-run, but if you renew once with the extra parameters but without --dry-run, it should store the new webroot authenticator with the webroot path in the renewal conf file. The next renewal in 60 days time should then go without any issue with just certbot renew.

Also, is the listen [::1]:443 correct? Do you want IPv6 to only listen on the localhost IPv6 address?

4 Likes

Side note: here is a list of issued certificates crt.sh | metalfans.be, the latest being 2024-01-30.
However that one is unique in that it only contains the name metalfans.be, all the rest also included the name www.metalfans.be.

4 Likes

Also an interesting side note only the name metalfans.be has an IPv6 address, the
name www.metalfans.be does not have an IPv6 address; the do both have an IPv4 address.

3 Likes

Those are two different IPv6 addresses.

3 Likes

Thanks for the fast reply's. The nginx IPV6 config has been fixed, these kinds of things happen when youre tired and still trying to get it all up and running!

@Bruce5051 Good that you mention it, will have a look at it one of these days.

@Osiris hmm, since the renewal is about 60 days away, the command does just say "No renewals were attempted.". In about 60 days i will have all forgotten about this issue..

3 Likes

There's a reconfigure subcommand to reconfigure the renewal parameters without issuing a new certificate. The reconfigure subcommand uses the staging environment for testing before saving the new renewal configuration file. However, in your version 2.8.0 there still is a bug present where Certbot actually didn't use the staging environment, but the production environment when using the reconfigure subcommand. This should be fixed in the upcoming release 2.9.0.
But as that hasn't been released yet, using reconfigure would issue a real cert, so it's no different to using --force-renewal just this once to force a renewal and saving the new renewal parameters. Once Certbot 2.9.0 has been released, --force-renewal should NOT be used, but the reconfigure subcommand.

2 Likes

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