Timeout during connect (likely firewall problem)

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: oc6.lt.dacar.by

I ran this command: certbot certonly --webroot -w /var/www/html -d oc6.lt.dacar.by

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Requesting a certificate for oc6.lt.dacar.by
Performing the following challenges:
http-01 challenge for oc6.lt.dacar.by
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Challenge failed for domain oc6.lt.dacar.by
http-01 challenge for oc6.lt.dacar.by

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: oc6.lt.dacar.by
Type: connection
Detail: 2a13:9401:0:1::a424:1: Fetching http://oc6.lt.dacar.by/.well-known/acme-challenge/0Arsm1_gmF4F6JSrCC9Ap1QCI5Y8Gg0myYS51jJ9XYg: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): nginx/1.26.3

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

My hosting provider, if applicable, is: hosteroid.uk

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): certbot 4.0.0

1 Like
2

Welcome @alexmedof

Do you have a firewall that is blocking certain IP ranges or geographic areas?

I can reach your server from my own test server. And, Let's Debug also reaches it from its own test server. But, a request by Let's Debug using the Let's Encrypt staging (test) system fails. And, your request against the production LE system failed with a timeout.

This pattern of failures is usually a selective firewall. There can be other causes but this is first thing to check.

3 Likes
3

iptables has no any rules. ISP tell that he is no any blocking of my server.

root@newdeb:/tmp# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@newdeb:/tmp# ip6tables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@newdeb:/tmp#
4

Something is preventing connections to your IPv6-only destination from the Let's Encrypt servers.

If this is a residential setup check the router for any firewall options. And, check with your ISP.

Otherwise, if hosteroid is your server hosting company check with them. Maybe they block requests from certain IP ranges.

If neither of those is blocking requests you have several options:

One option is to use a DNS Challenge instead of the HTTP Challenge you are using now. However, you would first have to fix a number of problems with your DNS config. See: oc6.lt.dacar.by | DNSViz
Review both the Error and Warning sections. You should fix your DNS config anyway as these problems will likely cause other problems managing your DNS.

The DNS Challenge works best if your DNS system supports API access to allow the ACME Client to add and delete TXT records to prove you control the domain. Your DNS config is too broken for me to suggest more specifics. See: Challenge Types - Let's Encrypt

Another option is to try using a different Certificate Authority. ZeroSSL and Google Trust Services both offer free certs using the ACME protocol and I believe both are supported by Certbot. However, these may have the same problems with the HTTP Challenge as Let's Encrypt is having. It is hard to know until you can better define where the communications failure occurs.

They both require additional registration steps compared to Let's Encrypt. Refer to their respective sites for details.
ZeroSSL: Automate SSL Certificates with ACME Protocol | ZeroSSL
Google Trust Services: Request a certificate using Public CA and an ACME client  |  Certificate Manager  |  Google Cloud Documentation

2 Likes
5

Indeed, I've already opened a ticket with hosteroid, but they seem unsure which LE validation nodes are having trouble reaching my ipv6 address. It would be very helpful to identify the source IP ranges that are failing.
I've tried running tcpdump on my host during the HTTP-01 challenge, and it showed zero incoming packets on port 80. This suggests the traffic is being blocked or misrouted before it even reaches my instance.
As a workaround, I have successfully switched to the DNS-01 challenge, and everything is working fine now. However, the underlying ipv6 connectivity issue remains a mystery.

Thank you for your help.

1 Like
6

If you have the DNS Challenge working automating (via API) that's a perfectly reasonable solution.

LE currently validates from 5 world-wide locations. This failure is from the Primary center in the USA. If it was one of the Secondary centers the error message would say "Secondary". The Secondary centers do not attempt validation if the Primary fails.

LE does not publish the IP for their centers. But, you know your destination so it should be possible to work "upstream" from your location and see where the packet is lost. That is, the hosting service and their carrier could check if anything arrived for your destination IP. If they don't see it go to the next carrier and so on. Yes, it can be exceedingly difficult.

This could be some backbone carrier interconnect problem. And, sometimes these resolve on their own after a few days as those carriers get other trouble reports. For example, there was a recent case of a number of New Zealand hosting services that all started failing validation on the same day. And, some days later they all started working. There was no apparent involvement by LE staff.

I believe the Primary LE center uses a commercial Cloudflare product for their outbound traffic. At least it did at one point but LE doesn't inform of technical changes to their infrastructure. This is partly on purpose to avoid people "over fitting" their own tools to a specific layout. But, it can make certain debug tasks harder.

Not much more I can do.

3 Likes
7

Thank you very much for the detailed explanation. It’s very helpful to know that the failure occurs at the Primary center in the USA and that the validation traffic likely routes through Cloudflare's infrastructure.
Since the issue seems to be at the backbone or interconnect level between carriers, and considering that my DNS-01 challenge is working perfectly through an API-automated script, I will stick with that solution as it completely bypasses these routing mysteries.
I appreciate your time and the insights into how LE validation works behind the scenes.

3 Likes