Greetings! Let's Encrypt isn't able to contact my public hostname/IP despite being accessible from outside my local network (tested with Cloudflare WARP, mobile network, friend's WiFi). Running curl from a VPN returns the expected response on the HTTP port (80).
I have Nginx configured to respond to HTTP-01 challenges (.<account_thumbprint>) and I was able to issue/renew certificates successfully until very recently. (My certs expire April 2026, so I was looking to automate cert renewal when I discovered this issue.)
Let's Debug shows port 443 has no issues but 80 is timing out.
I have tried the following to no avail:
- Shutting down nginx and using socat to respond to ACME challenges -> To rule out problems with my Nginx config
- Using alternative modes (TLS-ALPN-01) -> To see if port 443 works
- Using an alternate CA (ZeroSSL)
Is it possible my ISP is selectively blocking inbound port 80 from Let's Encrypt IPs? My server is exclusively IPv6 (AAAA record only).
I cannot use DNS challenges because I use a free DNS service that forbids records starting with _ or at the apex domain.
I ran this command: acme.sh --issue -d example.com --stateless --server letsencrypt
It produced this output: Timeout during connect (likely firewall problem)
My web server is (include version): nginx/1.29.5
The operating system my web server runs on is (include version): Debian 13
Hi! Welcome to the forum. Could you please provide your real domain name? It will be very hard for us to help you without it.
2 Likes
Sure, it's foxxy.hs.vc (a free domain from FreeDNS). I have a bunch of other domains (like xmpp.foxxy.hs.vc) but all pointing to the same host IP. Thanks for the warm welcome 
2 Likes
That's odd. I do have an AAAA record that resolves to my IPv6. acme.sh also resolves correctly.
dig AAAA foxxy.hs.vc
; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> AAAA foxxy.hs.vc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47549
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;foxxy.hs.vc. IN AAAA
;; ANSWER SECTION:
foxxy.hs.vc. 3502 IN AAAA 2405:201:e023:204b::10
;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Mar 08 18:19:33 UTC 2026
;; MSG SIZE rcvd: 68
Based on this connectivity test, locations outside Europe can't reach your domain Free Website Reachability Check | Semonto.
3 Likes
dig @1.1.1.1 AAAA foxxy.hs.vc also resolves (just to rule out local DNS replies).
1 Like
Yeah, sorry. I misinterpreted an unusual error from my own testing tool. I deleted my post but not soon enough I guess.
4 Likes
I'm guessing this is ISP blocking somewhere?
Most likely, this would make DNS-01 the most likely validation method to work. There's already a script for FreeDNS integration (acme.sh/dnsapi/dns_freedns.sh at master · acmesh-official/acme.sh · GitHub).
2 Likes
The FreeDNS integration can't set TXT records on free domains (likely because _acme-challenge records are forbidden). I remember trying to set them manually, which forced me into using HTTP-01.
if [ "$?" != "0" ]; then
_err "FreeDNS failed to add TXT record for $subdomain bad RC from _post"
return 1
elif ! grep "200 OK" "$HTTP_HEADER" >/dev/null; then
_debug3 "htmlpage: $htmlpage"
_err "FreeDNS failed to add TXT record for $subdomain. Check $HTTP_HEADER file"
return 1
elif _contains "$htmlpage" "security code was incorrect"; then
_debug3 "htmlpage: $htmlpage"
_err "FreeDNS failed to add TXT record for $subdomain as FreeDNS requested security code"
_err "Note that you cannot use automatic DNS validation for FreeDNS public domains"
return 1
fi
Guess I will have to use my paid domains for proper TLS? (renewing them was pricey so I was using FreeDNS as a stable fallback)
It would be nice if LE could work around geo-blocking.
It cannot. Multi-perspective validation is required by the Baseline Requirements for all Certificate Authorities.
That is (probably) why ZeroSSL also failed. These requirements are getting stricter rather than looser.
For further info see: Multi-Perspective Validation & Geoblocking FAQ
3 Likes
Cloudflare is not expensive and has excellent API support (and good docs and a helpful community of its own). Some TLDs are much more expensive than others.
They even have a Dynamic DNS offering if you actually need that too.
2 Likes
I hope I'm not misunderstanding this but wont "multi-perspective validation" verify a server using different IPs - different routes to host? That would effectively solve my problem granted my server appears reachable from Cloudflare IP range and much of the EU.
As for picking a registrar, I will consider Cloudflare. $10 a year is reasonable for some of the domains I looked up. The paid domain I currently have renews at ~$60.
Multi-perspective validation requires multiple successful validations from different locations.
Also, you can use another registrar while using Cloudflare as your DNS service.
2 Likes
Not sure which Cloudflare solution you are describing but LE's Validation servers need to reach the IP address in your public DNS records from its own locations. LE currently has 5 validation centers 4 of which are AWS based. So as long as those HTTP requests from LE reach the server that can reply with the challenge token it should work.
If you are asking about the Cloudflare CDN that offers very different options for you. If Cloudflare is your DNS provider you can (optionally) "proxy" your domain to use their CDN. The CDN will get and manage its own certs for connections between clients (ex: browsers) and the CDN "edge" servers (called "Universal SSL"). You then need a cert for your "Origin" server for HTTPS between the CDN edge and your Origin. Cloudflare's Origin CA cert can be used avoiding a need for your own stand-alone ACME Client to get certs.
There are some restrictions on what ports Cloudflare can "proxy" (like mail) so there's that to consider.
You don't have to use the Cloudflare Origin CA cert for a proxied domain. You could obtain your own. A DNS Challenge is probably easier but an HTTP challenge is possible with proper care routing the HTTP request from the Cloudflare edge server to your Origin server. Often the CDN itself handles routine redirects from HTTP to HTTPS, for example.
Note when your domain is proxied there will be A and AAAA records in the public DNS with IP for the Cloudflare edge servers.
3 Likes
Thanks, understood. I was under the impression multi-perspective validation wouldn't require every connection to succeed (so if certain routes turn out unreliable as in my case, the working ones could still reach consensus proving ownership of domain).
2 Likes
The BR allow only one failure with 5 or fewer validation centers. Two failures if 6 or more.
4 Likes
I was referring to my IP being reachable from Cloudflare's range (routed through WARP). It's a little surprising that my ISP would block AWS IPs, considering AWS services work perfectly from my end.
I did use Cloudflare's Zero Trust for a while but have since moved away. Yes, I'm aware how they proxy TLS with a long-lived origin cert and a publicly trusted cert at their edge (that they manage for you on free plans), among other services they offer. I do not plan on using their CDN at this time.
This feels more like an IP/routing problem considering LE (and ZeroSSL) cannot reach my IP to begin with, so the choice of DNS provider is irrelevant. I'll look into my ISP and hosting provisions. Much thanks.
1 Like
Explains it!
My previous IPv6 prefix was globally routable. Ever since my ISP rotated my prefix delegation, I notice my IP isn't accessible from certain places (in spite of DNS resolving correctly). The new PD might be the cause of my troubles here. Very interesting.
1 Like
While I'm not very familiar with BGP, this might be useful for tracking issues with routing, in particular how the prefix for your IP address is not advertised in the default-free zone. 2405:201:e000::/37 - bgp.tools
Edit: There are other shorter prefixes which cover your IP address and are routed. Search your IP address on the page to find them.
3 Likes