Timeout during connect (likely firewall problem)

[web404]

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: test.remotecapture.net

I ran this command: wacs.exe --test --verbose

It produced this output: After setting requested infomation.. Error is During secondary validation: XX.XX.XX.XX: Fetching http://test.remotecapture.net/.well-known/acme-challenge/HoJuiTr0EXefRxnGYh28-eHA5zdoPQ2VkT1XoKZKfPc: Timeout during connect (likely firewall problem)

My web server is (include version):IIS 10

The operating system my web server runs on is (include version): Windows 2022

My hosting provider, if applicable, is:

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): v2.2.8.1635

I have around 70 websites running Let's Encrypt certificates using the wacs client.
My last successful new certificate request was on 2024-03-26.
My first issue started on 2024-03-29.

I have set up a test environment using domain test.remotecapture.net
I am using the staging URL to run multiple tests, but the same error will occur on the production API URL.
The domain validation method is 'http-01'
I have verified that the authorization file does exist and can be accessed.

The client submits 3 pending requests before the API returns
"status": "invalid",
"error": {{"type":"urn:ietf:params:acme:error:connection","detail":"During secondary validation: XX.XX.XX.XX: Fetching http://test.remotecapture.net/.well-known/acme-challenge/HoJuiTr0EXefRxnGYh28-eHA5zdoPQ2VkT1XoKZKfPc: Timeout during connect (likely firewall problem)","status":400,"instance":null}}

Reviewing the web logs, they show 3 requests with status 200.
2024-04-01 11:33:01 xxx.xxx.xxx.xxx GET /.well-known/acme-challenge/HoJuiTr0EXefRxnGYh28-eHA5zdoPQ2VkT1XoKZKfPc - 80 - 18.188.170.43 Mozilla/5.0+(compatible;+Let's+Encrypt+validation+server;++https://www.letsencrypt.org) - 200 0 0 37
2024-04-01 11:33:01 xxx.xxx.xxx.xxx GET /.well-known/acme-challenge/HoJuiTr0EXefRxnGYh28-eHA5zdoPQ2VkT1XoKZKfPc - 80 - 66.133.109.36 Mozilla/5.0+(compatible;+Let's+Encrypt+validation+server;++https://www.letsencrypt.org) - 200 0 0 24
2024-04-01 11:33:12 xxx.xxx.xxx.xxx GET /.well-known/acme-challenge/HoJuiTr0EXefRxnGYh28-eHA5zdoPQ2VkT1XoKZKfPc - 80 - 35.86.156.217 Mozilla/5.0+(compatible;+Let's+Encrypt+validation+server;++https://www.letsencrypt.org) - 200 0 0 58

I see there are other post about the same issue.

[MikeMcQ]

The IP addresses in the log would be helpful to know. Those are the IP of the requester so is not private to you.

But, if I had to guess right now I'd wonder if you had a firewall that blocked by geographic region. Perhaps only allowing US based requesters. Is that possible?

Note the timeout error is probably the most common problem we ever see. The cause of your timeout could easily be something unrelated to any other.

[web404]

Sorry for the masking, but I am stuck with a very restrictive IP discloser policy. Even if that IP can be found by a quick url lookup.
Yes, I am geoblocked with only US IPs allowed.
After reading Osiris responses in other posted about increment to "4 remote validation points" that would seem to match was I am seeing.

[linkp]

If you cannot relax your IP access policy on port 80, you may need to switch to DNS-01 challenges.

[MikeMcQ]

@web404

but I am stuck with a very restrictive IP discloser policy. Even if that IP can be found by a quick url lookup.

But those IPs do not belong to you anyway. They would be the IP for the Let's Encrypt validation server. Anyone else using Let's Encrypt could also see the same ones I won't belabor the point (further) it just seems odd.

Yes, if you do not allow non-US locations that is a problem for HTTP/TLS-ALPN validation. As @linkp notes a DNS Challenge may be your only option.

Or, could you allow inbound HTTP requests from any locale as long as they are just /.well-known/acme-challenge/(token) requests? Either at the firewall itself or by selective code in the server handling port 80.

[web404]

The IP I need to mask is the web server's public IP and the internal IP. I left the Let's Encrypt IP unmasked. I do agree with you; it doesn't make that much sense, but that is what I am stuck with.

I like the idea of allowing the inbound request and will be looking into it. Thank you for the suggestion. @MikeMcQ

And if they will no work DNS... @linkp

[MikeMcQ]

My mistake. I am more used to seeing the requester IP in the first spot. I see now the requester IP later in the log record. And, yes, those are 3 IP in US based server farms.

[Bruce5051]

Maybe look to another Free ACME Certificate Authority as your CA.

[webprofusion]

Note that you can also allow all incoming port 80 requests on the server, but delete any IIS port 80 bindings, that way the only thing that will ever respond to port 80 requests will be the win-acme https challenge listener (which will only run during validation attempts and will only listen for /.well-known/acme-challenge requests). It's the same for most other windows based acme clients.

Your DNS appears to be with GoDaddy, so you should be able to use DNS validation win-acme or if you don't want to update your main DNS zone you can use a CNAME delegation to another zone.

[web404]

I have been able to resolve my issues by using DNS validation. I did not think that would be a viable solution, as I was denied setting up API key login to many of my clients' DNS. I had missed the fact that I could do a CNAME delegation to another zone. Thank you @webprofusion for pointing that out.