Can not issue LE certificates for domains pointing to Anycast network

Help
1

Hello, what is the reason we can't issue LE certificates for domains pointing to anycast network 195.13.54.0/23?

We tried this on several domains, but see no requests for HTTP-01 challenge coming to 195.13.54.0/23. Changing the IP to a different network solves the issue.

IPs from 195.13.54.0/23 are perfectly accessible from the internet, including LetsDebug.

Example domain: booiij42g6.com pointing to 195.13.54.4.

The error received is the following: Issuing details:

Let's Encrypt validation failed with error - connection :: The server could not connect to the client to verify the domain :: 195.13.54.4: Fetching http://booiij42g6.com/.well-known/acme-challenge/N68lVnPNFfzarT-50bxC1zcmdTlGwYO8LEQtuY1EYDQ: Timeout during connect (likely firewall problem)||connection :: The server could not connect to the client to verify the domain :: 195.13.54.4: Fetching http://www.booiij42g6.com/.well-known/acme-challenge/WEnxbA3zpmjUPGc_cGu8NTfDEZtFt7cCH2x29FuQxHs: Timeout during connect (likely firewall problem).

nc -vz 195.13.54.4 80 Connection to 195.13.54.4 port 80 [tcp/http] succeeded!

Currently redirection from HTTP to HTTPS is enabled, but with this option disabled, it was not succesfull as well.

2

Has HTTP domain validation worked for you before? In general if you are consistently answering the http challenges and are allowing http from any country then it should work.

Your current error suggests that whatever should be responding to the (external) incoming http request isn't.

So first, confirm that an http request from any country reaches your server(s), not just an http request inside your network.

1 Like
3

Based on your HTTP response headers it looks like you are using a CDN. You say there are no HTTP Challenge requests arriving. But, does that mean not arriving at your origin server or the CDN itself does not see it?

curl -i http://booiij42g6.com/.well-known/acme-challenge/Test404
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 08 Dec 2025 14:05:19 GMT
X-ID-FE: dc3-hw-edge-gc10
traceparent: 00-7944bba2de5072eda96ba4fedd268132-4c958af05965f90a-01
Location: https://booiij42g6.com/.well-known/acme-challenge/Test404
4 Likes
4

Thank you for the reply. Correct, we are using CDN. The CDN itself doesn't see it. Please view for domain icm43388.cdn.gc.onl which points to 195.13.54.25.

For some reason, we see no http-01 challanges on our CDN's anycasted IPs from 195.13.54.0/23.

5

When you say a different network was successful does that also go to this same CDN?

Are you the CDN operator?

I can reproduce your problem that the Let's Encrypt Staging validation successfully reaches icm43388.cdn.gc.onl. But, a request for Let's Encrypt production cert times out.

If you are the CDN operator are you sure you don't somehow block the requests from the LE production IP? Do you know the MTU configuration?

I'll explain more about this ... The primary LE validation center must succeed and then multiple LE secondary centers also validate. The primary is failing so we don't know if the secondary would also fail. The primary center uses a commercial Cloudflare network but the secondary centers are AWS. These may change but this is how it is today.

2 Likes
6

Yes, we are the CDN operator, and we do not block access to 195.13.54.0/23. Could someone please help check from Let's Encrypt primary Cloudflare setup, why it couldn't reach 195.13.54.25?

Any sample troubleshooting data from CloudFlare i.e. ping/traceroute/mtr showing you cannot reach us could be helpful. Thank you.

7

The Staging and Production primary validation servers are in the same locations and use the same network paths. I'm not aware of any reason that Staging would be able to connect to an IP while Production cannot.

3 Likes
8

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