Running IPv4 and IPv6 with no problems on e-mail exchange.
Perhaps you can tell how to use dehydrated with IPv4?
Perhaps using DNS instead of http-01 may solve the issue?
running both devrijegeest.nl and cloudzeeland.com on the same server.
apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 is a NameVirtualHost
default server www.devrijegeest.nl (/apache/Includes/devrijegeest.conf:5)
port 80 namevhost www.devrijegeest.nl (/apache/Includes/devrijegeest.conf:5)
alias devrijegeest.nl
port 80 namevhost www.cloudzeeland.com (/apache/Includes/devrijegeest.conf:34)
alias cloudzeeland.com
*:443 is a NameVirtualHost
default server www.devrijegeest.nl (/apache/Includes/devrijegeest.conf:15)
port 443 namevhost www.devrijegeest.nl (/apache/Includes/devrijegeest.conf:15)
alias devrijegeest.nl
port 443 namevhost www.cloudzeeland.com (/apache/Includes/devrijegeest.conf:43)
alias cloudzeeland.com
Dehydrated doesn't satisfy the challenges (and thus doesn't care about IPv4 vs. IPv6); it deploys challenge files so that your web server can satisfy them. The problem is that your web server isn't responding to the challenge request, most likely (as the error message tells you) as a result of some kind of firewall issue. It responds on port 80, redirecting the request to HTTPS on port 443, but it isn't responding on port 443 via IPv6. It does respond via IPv4, but Let's Encrypt prefers to use IPv6 when available.
That would not help. As Dan pointed out the problem is not from dehydrated sending something outbound. It is that Let's Encrypt server needs to be able to send to any of the IP addresses you publish in your DNS. You have an AAAA record for IPV 6 so you should make sure that works. See: Let's Debug
I have been investigating and cannot point out what is issue is overhere.
What I am planning to do for now: remove my DNS's IPv6 related records, renew the certificate and add them back again.
Thanks guys for your help - will keep you posted once I found the issue.
Why would you put them back up again? Your server is unresponsive via HTTPS over IPv6. Until you fix that, putting those records back up seems counterproductive.
I think you misunderstand. But, first, I'll reenforce what Dan said. Your IPv6 address is not accepting HTTP or HTTPS connections from the public internet. That affects anyone trying to use IPv6 to you not just Let's Encrypt. You should fix that to have a working site.
As for "fall back to IPv4" ... dehydrated is not performing the challenge. Let's Encrypt does that. And, the link I provided explains why your challenge fails. Let me explain ...
An HTTP request on IPv6 from the Let's Encrypt server to you fails with a timeout
Let's Encrypt retries with IPv4. That succeeds but you redirect that HTTP request to HTTPS
Let's Encrypt follows that redirect and starts, again, with IPv6
This request again times out but Let's Encrypt does not perform fallback after being redirected. That was explained in the link I provided in my previous post but perhaps this more detailed explanation will help
You can see this same failure from the Let's Debug site or many other testing tools that would use IPv6. It is not unique to Let's Encrypt's servers.
That raised my learning curve. Didn't know that. The last 5 years had no issues with this uptill know.
Indeed I should have written " if no connect on IPv6, Letsencrypt should fall back to IPv4, which obviously it doesn't anymore." Sorry for that.
Have no clue to solve the issue at this moment, thanks for your support so far.
You could reconfigure your Apache so that it does not redirect the HTTP challenge to HTTPS. Then when Let's Encrypt retried with IPv4 your server would provide the proper response without redirecting to HTTPS.
That doesn't help other people wanting to connect on IPv6 so that's still something to sort out. Interestingly, from my own test server in the US I initially got failures using IPv6 to you (IPv4 worked fine). But, now both IPv4 and v6 are working. Yet, an https://letsdebug.net test still fails with timeout for IPv6. Do you have a firewall that treats these differently?
In any case, testing IPv6 takes care because some dual-stack clients implement "happy eyeballs" so may report success only because IPv4 worked.
Interestingly, the IPv6 timeout is easily reproduced but is erratic. It affects HTTP requests for your "home" page as well as ones formatted like an HTTP Challenge from Let's Encrypt.
I can sometimes make several requests in a row that succeed but then get a timeout. It then sometimes gets "stuck" issuing timeouts until I try a different URL which then works.
This "feels like" something going wrong in a firewall. I don't have any problems using IPv4 to you. In one sequence to your home page it worked, timed out, worked several times in a row then timed out several times in a row.
# Sample HTTP Challenge to IPv6 times out
# I see this same timeout even for your home page so not unique to this
curl -i6 -m8 http://devrijegeest.nl/.well-known/acme-challenge/Test404
curl: (28) Operation timed out after 8001 milliseconds with 0 bytes received
# Repeating it immediately after works
curl -i6 -m8 http://devrijegeest.nl/.well-known/acme-challenge/Test404
HTTP/1.1 302 Found
Date: Sat, 01 Aug 2026 17:41:35 GMT
Server: Apache/2.4.68 (FreeBSD) OpenSSL/3.5.6 PHP/8.4.23
X-Content-Type-Options: nosniff
Location: https://devrijegeest.nl/.well-known/acme-challenge/Test404
Content-Length: 282
Content-Type: text/html; charset=iso-8859-1
It appears that connections with a source flow label greater than or equal to 0x80000 fail. This could indicate some form of equal cost multiple path routing is occurring or there might be a sign conversion issue somewhere.
Edit: Flow labels are a 20 bit field in the IPv6 packet header and are included so that packets in the same connection use the same route reducing reordering.
After doing multiple tracepaths, there doesn't appear to be ECMP routing. Accounting for the fact that the three way handshake was successful and there doesn't appear to be any large packets, this appears to be a firewall bug.
I'm not sure how many times you need to hear this, but this has nothing at all to do with dehydrated; it's a matter of how Let's Encrypt's servers operate. And if you have published AAAA records, LE will try to connect on those IP addresses. If it can't reach your server on those addresses, validation will fail. I guess we could have a discussion of whether that's good practice or bad (I think it's good), but good or bad, it's how LE works. Not dehydrated. Let's Encrypt.
If your server doesn't reliably respond on its IPv6 address, you shouldn't be publishing AAAA records.
The firewall might be a Linux system with net.ipv6.flowlabel_state_ranges=1 (IP Sysctl — The Linux Kernel documentation). That makes it so that getting the flow label fails with -ERANGE if the flow label is at or above 0x80000 in addition to using the range 0x80000-0xFFFFF for stateless flow labels.
Edit: This theory is highly speculative and I can't find any code using this functionality.
I'm not sure how many times you need to hear this but my system is running IPv6 perfectly. The only issue is the challenge with Letsencrypt. That bothers me as much it bothers you that I cannot get understanding what is going on.
It would be really usefull if Letsencrypt just uses IPv4 if there is a problem with connecting to IPv6. Overhere people suggested to get rid of IPv6 because they met also issues with it. I believe in staying with it because at the end we will succeed. It is great to have your comments, but let's think in solutions.
Mike, I run Proxmox with FreeBSD 15 in a VM, hosting the domain.
Can you tell which ip you used during you test? So that I can check my logfiles regarding the time out?
Web server IPv6 connectivity
Trying to get http://www.devrijegeest.nl from 2a10:3781:44a3:1:0:0:0:54...
500 read timeout
Trying to get http://www.devrijegeest.nl from 188.213.94.112...
302 Found
Secure web server IPv6 connectivity
Trying to get https://www.devrijegeest.nl from 2a10:3781:44a3:1:0:0:0:54...
500 Can't connect to www.devrijegeest.nl:443
Trying to get https://www.devrijegeest.nl from 188.213.94.112...
200 OK
Any specifics on where OP would look to diagnose / correct that ?