We're having trouble issuing a certificate for the domain cerb00apps.onesoft.es (IP: 185.31.23.208). The process consistently fails due to a timeout error during the HTTP-01 challenge.
We’ve already run diagnostics using Let’s Debug, and it successfully reaches our server, indicating that connectivity from external systems (including Let’s Encrypt test tools) appears to be working.
However, during actual certificate issuance attempts, we don’t see any incoming connection attempts from Let’s Encrypt’s validation servers on our WAN interface. This is in contrast to traffic we do observe when using Let’s Debug. This makes us suspect the issue might not be on our side (e.g., firewall or local network), especially since:
Other domains hosted on the same infrastructure are issuing certificates without issues.
Our domain and IP are not listed in any public DNS-based blacklists.
We’re trying to determine if our domain or IP might be blocked, rate-limited, or otherwise restricted on Let’s Encrypt’s end.
Any guidance, similar experiences, or help from the community would be greatly appreciated!
your domain is unreachable from my side, and as LE uses multi-perspective validation points, challenge would fail if you are using Geoblocking firewall.
You're right — we usually keep port 80 closed and only open it temporarily when issuing certificates. I’ve now opened it to avoid confusion and allow for proper testing from different locations.
Working from here (Europe), but initially very slow. Maybe too slow for a relatively short timeout?
Also:
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it (and make our life a lot harder). In any case, all the answers to this questionnaire are required:
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:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Port 80 was previously closed, but it’s now open and accessible.
It’s true that we have some IP-based access restrictions in place, but those do not seem to affect other servers on our infrastructure — they’re issuing certificates without any problem. We’ll continue investigating on our side, but if there’s anything specific you’re seeing that might help pinpoint the issue, we’d really appreciate the input.
From our side, the server responds fairly quickly — around 200ms on average. Could you share what kind of response times you're seeing on your end? That might help us understand if there's any regional latency or routing issue affecting the validation process.
Other servers behind the same firewall are working correctly, and this VM doesn’t have any special rules applied. So, as far as we can tell, there shouldn’t be any blocking specific to Let’s Encrypt’s validation IPs — but we’ll double-check just in case.
To help clarify the situation, I'm attaching two Wireshark captures taken from the WAN interface, before any local filtering or firewall rules are applied.
Both captures are the result of running Let’s Debug tests:
Capture 1 shows a successful inbound request from Let's Debug to one of our VMs that can successfully issue certificates.
Capture 2 shows traffic to the problematic VM (cerb00apps.onesoft.es), where no incoming request from Let's Debug is observed at all.
Have you kept port 80 open? It's still looking like nothing can connect to me:
If you're looking in logs, whenever you ask Let's Encrypt to validate your challenge (whether directly, or Let's Debug asking the Let's Encrypt staging system), you should be seeing at least 5 requests coming in. If you're not seeing them, then something is blocking them. If it's not on the server you're looking at, maybe it's a firewall or network further upstream.
You mention that you do intentionally block some IPs, so here's some information on blocking in general and how Let's Encrypt needs to check from multiple places around the world, in case that's helpful to your understanding of how the process works:
Yes, as mentioned earlier, we're using the afosto/yaac library, which is a PHP ACME client that builds on top of Guzzle for HTTP requests. So while Guzzle appears in the logs, it's just the underlying HTTP client — not something we’re using directly to interact with the ACME server.
Apologies — our system is configured to open port 80 only during the certificate request process, and it closes it immediately afterward. I've now opened it again and will keep it open to avoid further issues.
As I mentioned earlier, we’ve captured all incoming traffic directed to the server before any firewall rules are applied, and we’re not seeing any requests coming from Let’s Encrypt during validation attempts. In contrast, we do see requests coming in when using Let’s Debug.
This makes us think the requests from Let’s Encrypt’s validation servers are not even reaching our infrastructure, possibly being blocked or dropped upstream — but we’re still investigating.
So running this same test now that you've opened it up, it seems that some locations have trouble, though not always the same ones each time I try. I'm guessing there might be some sort of rate limiting or intermittent connectivity involved.
But I don't have a more concrete suggestion for you.
That’s what’s puzzling — those same IPs are also blocked on our other domains, yet they’re issuing certificates without any issues.
What’s even stranger is that this particular domain has been consistently failing since March, despite daily attempts. The issue doesn’t seem intermittent from our side — it’s been persistently failing while others on the same infrastructure succeed.
We’re definitely open to any suggestions on what could cause this specific behavior.
