Fail to renew NGINX cert

Help
1

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: Let's Encrypt Community Support

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

It produced this output:

root@pyGuacamol:~# certbot --dry-run renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/guac.pocpia.ovh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for guac.pocpia.ovh

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: guac.pocpia.ovh
  Type:   connection
  Detail: 51.38.138.115: Fetching http://guac.pocpia.ovh/.well-known/acme-challenge/6Y2fPCi83qV2oWR9wdMB6ZX2TMQ5GBfUhQFFY8qPm60: Timeout during connect (likely firewall problem)

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 guac.pocpia.ovh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/guac.pocpia.ovh/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 version: nginx/1.26.3

The operating system my web server runs on is (include version):
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.5
ID=debian

My hosting provider, if applicable, is:
NONE

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 4.0.0

nginx config file:

server {
	server_name guac.pocpia.ovh;

	access_log  /var/log/nginx/guac_access.log;
	error_log  /var/log/nginx/guac_error.log;

	location / {
		    proxy_pass http://localhost:8080/guacamole/;
		    proxy_buffering off;
		    proxy_http_version 1.1;
		    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		    proxy_set_header Upgrade $http_upgrade;
		    proxy_set_header Connection $http_connection;
		    proxy_cookie_path /guacamole/ /;
	}


    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/guac.pocpia.ovh/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/guac.pocpia.ovh/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 {
	listen 80;
	server_name guac.pocpia.ovh;
	root /var/www/html;
	include /etc/nginx/mime.types;
	default_type text/html;
	location ~ /.well-known/acme-challenge/ {
	     allow all;
	}
}

I tryed to start a whatch ls -la /var/www/html/.well-known/acme-challenge/ and no file are created (perhaps it's normal...)
I put a file index.nginx-debian.html in /var/www/html/.well-known/acme-challenge/ and it respond at this url:
http://guac.pocpia.ovh/.well-known/acme-challenge/index.nginx-debian.html

2

I can't connect to your server, have you allowed/forwarded TCP port 80 in your firewall?

3

Arf... My apologize, firewall issue. We add the test source IP in trusted list and forgot to add let's encrypt servers. Do you know where I can find list of IP or domain I can trust?

4

Let's Encrypt validate you domain from multiple locations and they don't advertise the IP addresses they use, especially because it could change at any time.

5

For log purpose, I put the link to the doc about that: Multi-Perspective Validation & Geoblocking FAQ

6

Thank you very much!

7

It is normal. The --nginx option inserts temp code into your server block(s) for that domain. This involves a location block and a return statement with the full response needed to satisfy the challenge without a file. Example provided below. Certbot reloads nginx after adding that code and before requesting the cert to apply those changes. After that it removes those temp lines and reloads nginx again.

Because of that the below location block has no affect on --nginx operation.

Sample temp changes to a server block. Note an equal sign location block takes precedence over all others. You can see the exact code used in Certbot's logs in /var/log/letsencrypt.

server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot

    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/html;

location = /.well-known/acme-challenge/MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg {default_type text/plain;return 200 MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg.AwQwgwgwzwgwJwgw4wew3wrwxwiw-wpwvwqwxwBwswT;} # managed by Certbot

}