Renewal of Let's encrypt cert failed

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: dh4dai.dyndns.org

I ran this command: sudo certbot renew

It produced this output:

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

Processing /etc/letsencrypt/renewal/dh4dai.dyndns.org.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer apache
Renewing an existing certificate for dh4dai.dyndns.org
Performing the following challenges:
http-01 challenge for dh4dai.dyndns.org
Using the webroot path /var/www/htdocs for all unmatched domains.
Waiting for verification...
Challenge failed for domain dh4dai.dyndns.org
http-01 challenge for dh4dai.dyndns.org
Cleaning up challenges
Failed to renew certificate dh4dai.dyndns.org with error: Some challenges have failed.

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/dh4dai.dyndns.org/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: dh4dai.dyndns.org
    Type: connection
    Detail: 79.206.202.232: Fetching
    https://dh4dai.dyndns.org/.well-known/acme-challenge/79Yw33zyqna9s7f9dcahQyQypVKMfZVQx-a7AbkCp6c:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

Log-Entry in apache access log:

outbound1a.letsencrypt.org - - [07/Dec/2024:14:02:39 +0100] "GET /.well-known/acme-challenge/79Yw33zyqna9s7f9dcahQyQypVKMfZVQx-a7AbkCp6c HTTP/1.1" 301 683 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

My web server is (include version):

Server version: Apache/2.4.62 (Debian)
Server built: 2024-10-04T15:21:08

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

Debian Linux V 11.11

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): 1.12.0

2

There are multiple connectivity issues to your website if I run a Let's Debug on it. Please see:

Please make sure the listed IP addresses are actually correct (IPv6 as wel as IPv4) and make sure your website is operating properly and anyone from all around the world can connect to it.

3 Likes
3

Hi,

Thank you very much for this very quick response! Honestly, I do not understand this issue. The IP is correct, and I have checked at least for IPv4 that a connection could be established from outside.

By running tcpdump on the network interface of the web server, I can see that even letsencrypt (outbound1e.letsencrypt.org) is able to establish a connection to my web server. Here is an extraction from the tcpdump output. cube is the name of the linux server apache is running on.

14:49:13.480715 IP (tos 0x0, ttl 50, id 47465, offset 0, flags [DF], proto TCP (6), length 60)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [S], cksum 0x9503 (correct), seq 3805123405, win 64240, options [mss 1436,sackOK,TS val 1361371768 ecr 0,nop,wscale 7], length 0

14:49:13.481431 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    cube.80 > outbound1e.letsencrypt.org.50319: Flags [S.], cksum 0x8983 (correct), seq 2658567572, ack 3805123406, win 65160, options [mss 1460,sackOK,TS val 4154125336 ecr 1361371768,nop,wscale 7], length 0

14:49:13.651464 IP (tos 0x0, ttl 50, id 47466, offset 0, flags [DF], proto TCP (6), length 52)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [.], cksum 0xb437 (correct), seq 1, ack 1, win 502, options [nop,nop,TS val 1361371939 ecr 4154125336], length 0

14:49:13.651590 IP (tos 0x0, ttl 50, id 47467, offset 0, flags [DF], proto TCP (6), length 321)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [P.], cksum 0x0fc7 (correct), seq 1:270, ack 1, win 502, options [nop,nop,TS val 1361371939 ecr 4154125336], length 269: HTTP, length: 269
	GET /.well-known/acme-challenge/69HggCkHVcEJNZe5_XFMOc2zu9CGJK_IGVDDdyf1IL0 HTTP/1.1
	Host: dh4dai.dyndns.org
	User-Agent: Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)
	Accept: */*
	Accept-Encoding: gzip
	Connection: close
	

14:49:13.651775 IP (tos 0x0, ttl 64, id 32587, offset 0, flags [DF], proto TCP (6), length 52)
    cube.80 > outbound1e.letsencrypt.org.50319: Flags [.], cksum 0xb27b (correct), seq 1, ack 270, win 507, options [nop,nop,TS val 4154125506 ecr 1361371939], length 0

14:49:13.652055 IP (tos 0x0, ttl 64, id 32588, offset 0, flags [DF], proto TCP (6), length 735)
    cube.80 > outbound1e.letsencrypt.org.50319: Flags [P.], cksum 0x3f7b (correct), seq 1:684, ack 270, win 507, options [nop,nop,TS val 4154125507 ecr 1361371939], length 683: HTTP, length: 683
	HTTP/1.1 301 Moved Permanently
	Date: Sat, 07 Dec 2024 13:49:13 GMT
	Server: Apache/2.4.62 (Debian)
	Location: https://dh4dai.dyndns.org/.well-known/acme-challenge/69HggCkHVcEJNZe5_XFMOc2zu9CGJK_IGVDDdyf1IL0
	Content-Length: 387
	Connection: close
	Content-Type: text/html; charset=iso-8859-1
	
	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
	<html><head>
	<title>301 Moved Permanently</title>
	</head><body>
	<h1>Moved Permanently</h1>
	<p>The document has moved <a href="https://dh4dai.dyndns.org/.well-known/acme-challenge/69HggCkHVcEJNZe5_XFMOc2zu9CGJK_IGVDDdyf1IL0">here</a>.</p>
	<hr>
	<address>Apache/2.4.62 (Debian) Server at dh4dai.dyndns.org Port 80</address>
	</body></html>

14:49:13.654524 IP (tos 0x0, ttl 64, id 32589, offset 0, flags [DF], proto TCP (6), length 52)
    cube.80 > outbound1e.letsencrypt.org.50319: Flags [F.], cksum 0xafcc (correct), seq 684, ack 270, win 507, options [nop,nop,TS val 4154125509 ecr 1361371939], length 0

14:49:13.821001 IP (tos 0x0, ttl 50, id 47468, offset 0, flags [DF], proto TCP (6), length 52)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [.], cksum 0xaf2b (correct), seq 270, ack 684, win 501, options [nop,nop,TS val 1361372109 ecr 4154125507], length 0

14:49:13.866308 IP (tos 0x0, ttl 50, id 47469, offset 0, flags [DF], proto TCP (6), length 52)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [.], cksum 0xaefa (correct), seq 270, ack 685, win 501, options [nop,nop,TS val 1361372155 ecr 4154125509], length 0

14:49:13.916185 IP (tos 0x0, ttl 50, id 47470, offset 0, flags [DF], proto TCP (6), length 52)
    outbound1e.letsencrypt.org.50319 > cube.80: Flags [F.], cksum 0xaec8 (correct), seq 270, ack 685, win 501, options [nop,nop,TS val 1361372204 ecr 4154125509], length 0

14:49:13.916304 IP (tos 0x0, ttl 64, id 32590, offset 0, flags [DF], proto TCP (6), length 52)
    cube.80 > outbound1e.letsencrypt.org.50319: Flags [.], cksum 0xadbc (correct), seq 685, ack 271, win 507, options [nop,nop,TS val 4154125771 ecr 1361372204], length 0

14:49:14.039897 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    cube.dh4dai.wat.de.ampr.org.80 > 124.160.107.77.27493: Flags [S.], cksum 0x7d8f (correct), seq 586344334, ack 1, win 64240, options [mss 1460], length 0

Obviously, my web server responds to the request of outbound1e.letsencrypt.org on port 80 with a status code "301 Moved Permanently" and relegates to https://dh4dai.dyndns.org/...
So I do not understand the error message of your checks "no route to host" .

best regards,

Holger

4

Hi,

I just tried to remove the redirection to https from the apache configuration temporarily and afterwards the cert renewal worked! So indeed the redirection to https was the problem.

best regards,

Holger

5

That points to a problem with your IPv6 connection. Let's Encrypt tries IPv6 first. If that times out it will try your IPv4 address. After the redirect to HTTPS LE again tries the IPv6. That again will timeout but LE does not retry with IPv4 after a redirect. (details here: IPv6 Support - Let's Encrypt)

The IPv4 addresses in your log also indicate the IPv6 requests are failing.

The Let's Debug tests are still failing. Both IPv4 and v6 so I don't think you have resolved all your connectivity problems. I can't reach you from my own test server in the US either.

3 Likes
6

The IPv6 address 2003:e6:c7ff:70c:7eff:4dff:fecb:37e0 responds with a "Code: 1 (Administratively prohibited)" ICMP reply when trying to connect to it using TCP port 80 or 443.

Probably a firewall or perhaps incorrect IPv6 address.

2 Likes
7

In fact, IPv6 is not set up correctly in my local network. So I will check why there is an AAAA entry in the DNS during the next days. However, I could complete the renewal due to this work around, and I will try to correct my IPv6 configuration before the next renewal.

Best regards, Holger

1 Like
8

Anyone trying to use IPv6 will be affected. Not just Let's Encrypt

It is best if you can get it working and have a way to reliably test it. If you can't do that you may just want to remove the AAAA record.

3 Likes
9

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