Renewal failing

Help
1

The other domains hosted here renew with no problems. Any ideas?

My domain is:

goaccess.theo.to

I ran this command:

certbot renew --dry-run --cert-name goaccess.theo.to --nginx-sleep-seconds 10

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/goaccess.theo.to.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for goaccess.theo.to

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: goaccess.theo.to
  Type:   unauthorized
  Detail: 2600:3c03::f03c:94ff:fe01:db93: Invalid response from http://goaccess.theo.to/.well-known/acme-challenge/W-onvmltD-tw2ajhAAxKG0zDhzjSUF0ZPxo8zoJdIlo: 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 goaccess.theo.to with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/goaccess.theo.to/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.24.0 (Ubuntu)

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

Ubuntu 24.04.1

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

2

Do your other domains have an AAAA record for IPv6 ?

Does the nginx server block for this domain have a listen statement for IPv6?

Because the problem is the HTTP request sent to your server is replying with a 404 Not Found. These requests are sent using IPv6 when an AAAA record is present in your DNS. Such as for this domain.

2 Likes
3

All but one of them.

Yes:

server {

   if ($host = www.theo.to) {
   	  return 301 https://theo.to$request_uri;
   }

server_name theo.to www.theo.to;
root /home/tct/www/theo.to;

index index.html index.php;

access_log /var/log/nginx/theo.to-access.log;
error_log /var/log/nginx/theo.to-error.log;

location / {
	include /etc/nginx/snippets/aiblock.conf;

   try_files $uri $uri/ /index.php?$query_string;
 }

   location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
   location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
   location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
   location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 403; }

location ~ \.php$ {
   fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
   fastcgi_split_path_info ^(.+\.php)(/.+)$;
   fastcgi_index index.php;
   include fastcgi_params;
   fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
 }

    listen [::]:443 ssl; # managedby Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/theo.to/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/theo.to/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 = www.theo.to) {
        return 301 https://theo.to$request_uri;
    } # managed by Certbot
4

Would you show the rest of the server block for port 80 please? Because that is the one that initially sees the HTTP challenge request from the Let's Encrypt server.

1 Like
5

Ah yes, indeed, the port 80 server block was not listening for IPV6. Many thanks!

2 Likes
6

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