I am experiencing the exact same issue with a couple of certs of mine. I did packet captures and validated from 2 different VPS sites that access to the HTTP challenge is working 100% but I am met with a similar message:
Timeout during connect (likely firewall problem)
My apache/nginx logs show me 200s, my packet captures are replying back to sources properly, and my VPS test curls while the certbot was running for the challenge to be verified worked(I was able to hit the exact URL and get the challenge from my EC2 instance and VPS instance).
At this point I am starting to believe that there is some issue with the Lets Encrypt servers.
Your belief is incorrect. Please open your own topic in the Help category and complete the template so that you may receive individual attention for your issue.
Hello @certdude, welcome to the Let's Encrypt community.
As already stated, 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):
The server could not connect to the client to verify the domain :: During secondary validation:
My firewall does geo block a bunch of countries, is there a list a full list of CIDRs/servers that Let's Encrypt auths from? The three I see are all from AWS.
That is an interesting log because those 3 are an http 200 which is a successful reponse by your server. Given the cert request failed it means one or more of those replies did not reach the Let's Encrypt server. This is not likely an inbound firewall failure. It is perhaps an outbound firewall or, more likely, some kind of comms routing problem. But, at least your server wanted to reply correctly.
The LE servers only need "enough" responses to determine success or failure. At the moment 3 successes is enough (likely to be 4 fairly soon).
@MikeMcQ Currently 4 remote validation points are in situ, if you include the primary there are 5 requests. If only 1 remote validation point is allowed to fail, 3 requests, 1 from the primary and 2 from remote locations, would fail the challenge.
So I'm not sure if this is an outbound problem, especially if OP says there's geoblocking in play.
It was stated there were only a few days between steps, and the increment to 4 remote validation points was 5 days ago already. While I'm not sure of course, chances are the quorum has been increased already.
The HTTP challenge quorum change will definitely catch a lot of people off guard, there are tons of orgs out there that run firewalls which block specific countries. My suggestion to Let's Encrypt team would be to publish a whitelist of subnets(at minimum) to keep folks functional in their renewal mechanism.
I can likely work with my firewall to try and catch which IP addresses are being blocked during the HTTP challenge phase, to create my own whitelist, but I doubt many will have the patience or willingness to go that far.
