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.
I can login to a root shell on my machine (yes or no, or I don't know): 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): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Not sure - the file is wacs.exe - I think certbot is a Linux thing?
Certbot is not just a linux thing but it is not the best for IIS on Windows (which is you). So, wacs or another ACME client designed for Windows is best then.
What is your version of wacs? (run wacs --version)
I see the 404 failure but I also see you got a cert yesterday for that domain. What is different about your request today compared to yesterday?
Software version 2.1.22.1289 (release, trimmed, standalone, 64-bit)
I assume this is right as it comes at the top of the window when running
I think your observation may have highlighted an issue which may mean this is embarrassingly all our fault. I will discuss this with my colleague when he is free and come back to you if the problem continues Thanks so much for your reply
OK - so that domain turned out to have been moved to another server. However, here is the result if I work manually with this domain which is due to renew tomorrow, and I assume won't
Whatever we try to do on this server we hit the timeout problem, and I assume that tomorrow's auto-renew on this domain will have the same problem. If you have any ideas, I would be delighted to hear them!
My best guess is you have a firewall that is blocking IP addresses used by the Let's Encrypt servers. And, no, these are not published. See here.
I can reach your server just fine from my own test server. I also probed for problems related to Palo Alto Networks brand firewalls and did not see those problems. But, the most telling clue comes from the Let's Debug test site.
Look at this test result and you'll see an initial test to your server got a 404. The 404 is expected since you don't have that file on your server but it proves connectivity.
Yet, the test request using the Let's Encrypt staging servers right after failed with a timeout. This is almost certainly a firewall blocking certain IP's.
For the record, this is now fixed. It wasn't us at all! Despite our hosting people saying that no firewall rules had been changed. Still don't know what they actually did but clearly something as it is now working fine again. Thank you so much @MikeMcQ for your input, which helped us toward the right solution.