I'm getting a persistent "Timeout during connect" error during secondary
validation when trying to issue a certificate via win-acme (WACS 2.1.18.1119)
using http-01 validation, both with the SelfHosting and FileSystem plugins.
DNS resolves consistently and correctly to 34.72.42.51 from ~45 global
locations (check-host.net) and locally.
No AAAA record exists.
Port 80 is reachable from nearly every global location tested (check-host.net
TCP + HTTP checks), only failing from Iran (national filtering, expected)
and a couple of isolated node blips.
A direct HTTP GET to the exact challenge path
(Takwene Lab) returns 200 OK
from ~45 global locations while the challenge file is live.
win-acme's own "preliminary validation" (local check) passes every time ā
only the remote/secondary ACME validation step fails.
This has failed identically on multiple separate attempts, both with
SelfHosting and FileSystem validation plugins in win-acme.
The domain is hosted on Google Cloud (Compute Engine / IIS on Windows),
DNS is on Google Cloud DNS.
Given every external diagnostic I can run shows the domain and challenge
path are reachable, I'd appreciate help understanding what secondary
validation might be seeing that these external checks aren't catching.
Happy to provide the win-acme log file or run further diagnostics as needed.
There are currently 4 secondary validation centers around the world. You already did some of the usual checks.
Is there some kind of firewall that might block multiple simultaneous HTTP queries from different global points?
Are you able to check your IIS access log and show any of the challenge requests that arrive. You will see at least one 200 status from the primary center. You may see other 200 (or other) responses from your server for the 4 other secondary. Knowing these would be helpful. We know at least one secondary is missing because of the "timeout" error but some of the others may have come through.
Thanks for the pointer ā I checked the IIS access log (W3SVC69, site logging is enabled at the default path) for both recent attempts.
For each attempt, I searched for the actual challenge token requested and any "Let's Encrypt"/validation-server user agent, and found only one request logged per attempt:
Attempt 1 (token eJyDPyh3URLpewBQS8R3zIS5PjuphwqgXQiAWCad_Hs): one request at 14:53:45 from 23.178.112.107, response 200.
Attempt 2 (token TI2pSisdXzXUSuYHPz8SGiTjR4yp1UYiQchFi1PmvTs): one request at 15:16:35 from 23.178.112.105, response 200.
No other requests for either token appear anywhere else in the log ā before, after, or around those timestamps. If there are 4 secondary validators plus 1 primary, only one request (presumably the primary) ever reached IIS; the other four never show up at all, not even as a rejected/errored entry. Since they're completely absent rather than logged-and-failed, it looks like they're being dropped somewhere upstream of IIS (firewall, load balancer, or security group), before the request ever gets to the web server.
This is on Google Cloud (Compute Engine + IIS behind what looks like a GCP load balancer setup, given the 10.128.0.2-style internal IP in the log and the DNS pointing at 34.72.42.51). I'll check the VPC firewall rules and load balancer backend config for anything that might be restricting inbound port 80 traffic by source IP/region rather than allowing it broadly ā but if there's a way to tell from your side which specific validator IPs/regions failed for these two attempts, that would help me confirm exactly where to look.
Separately, unrelated to this: I also noticed a request to /.well-known/acme-challenge/Test404 returned 200 instead of 404 ā worth me fixing on my end, but doesn't seem to be related since the real tokens were served correctly with matching content when they existed.
Yes, correct. Given that all 4 secondary centers failed to reach you that points strongly to something on your end.
That was likely me. I often use Test404 in such URLs. I ran some tests to see if the user-agent string changed the result. It did not or at least not from the US based servers I used. I probably used a default curl agent and agent strings that look like Let's Encrypt validation servers.
Two of the secondaries are in the US and two outside of the US (currently). It's unusual to not see any apart from the primary which is also in the US. I don't have any good suggestions for debug at the moment apart from what you already plan.
You might want to switch to simple-acme. The principal maintainer of win-acme now focuses on this drop-in replacement. It has no bearing on these failures. But since this is a new setup you might want one that, um, may have better support: https://simple-acme.com/
UPDATE:
Oh,
Are there actually two or more IIS instances running behind a load balancer? If so are you checking all their related logs? And, if actually multiple IIS an HTTP Challenge will be tricky to get working well.
