Not able to renew as letsencrypt doesn't retry challenges

Help
1

My domain is: {ampd, atlas, dev, head, elm, m}.koparo.com

I detailed the issue in this github ticket which includes the information the post template asks for additionally with my nginx configuration, letsencrypt configuration and a log from renewal attempts and nginx logs.

In summary, I can’t renew a certificate as letsencrypt is not retrying accessing the well-known challenge files. I made sure those files are created when certbot runs and I checked that I can access them remotely.

I believe the issue might be related to the fact that previously I was only serving https for well-known and did a 301 on all attempts to access it via http (301 to https).

Did anyone hit this issue before? Is there a way to renew the certificate or somehow diagnose why the challenges are not retried?

2

Some of those hostnames have AAAA records, but HTTP and HTTPS connections to that IPv6 address time out.

$ mhost -cS dev.koparo.com.
dev.koparo.com.  (unsigned)  86400  A     80.85.86.247
dev.koparo.com.  (unsigned)  86400  AAAA  2a01:7e00::f03c:91ff:fe50:9f76
$ mhost -cS head.koparo.com.
head.koparo.com.  (unsigned)  86400  A     80.85.86.247
head.koparo.com.  (unsigned)  86400  AAAA  2a01:7e00::f03c:91ff:fe50:9f76
$ nc -6vz dev.koparo.com 80
nc: connect to dev.koparo.com port 80 (tcp) failed: Connection timed out
$ nc -6vz dev.koparo.com 443
nc: connect to dev.koparo.com port 443 (tcp) failed: Connection timed out

You should make sure that IPv6 is enabled, your firewall isn’t blocking it, etc.

Additionally, the Nginx server blocks in the GitHub issue are only configured to listen on IPv4. You need to add “listen [::]:80;”, to them, and the equivalent for port 443 in your HTTPS blocks.

Alternately, you can remove the AAAA records, but that would be sad.

2 Likes
3

Thank you @mnordhoff you were spot on.

I do wonder if defaulting to IPv6 was something that letsencrypt does since recently as previous
renewal went through even with the misconfigured IPv6 on my side.

Regardless, I configured nginx to listen on IPv6 and fixed the AAAA records that still pointed to an old set of machines that were decommissioned - sigh that was good to spot…

certbot renew worked flawlessly as soon as the DNS changed propagated. My problem is solved. Thanks!

4

It is in fact a relatively recent change

1 Like
5

This is causing us issues as well. We have 350 clients and some have an IPV6 address that will not work for renewal of certificate whereas the IPV4 will (because the IPV4 A record points to our server).

Please can we have the dialler process in boulder try the IPV4 address if it fails the renewal process via IPV6?

6

This is an invalid setup. If the IPv6 address fails to connect at all, it is supposed to fallback to IPv4. However, if IPv6 responds in any way, it sticks with that response even if it’s incorrect.

Your clients either need to set up their servers to properly respond to IPv6 requests, or remove their invalid AAAA records.

7

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