Problem with http verification

My domain is: app.zlatni-eracun.hr

I used Win-ACME to renew a certificate (i had 19 successful renews before this happened), but it constantly failed.

It produced this output:

"type": "urn:ietf:params:acme:error:connection",
  "detail": "167.235.166.78: Fetching http://app.zlatni-eracun.hr/.well-known/acme-challenge/e8J_U6yaqE3ZTw_Vp-uvhlF1Ixwou9fg6ek6xo4Lc_k: Timeout during connect (likely firewall problem)",
  "status": 400

My web server is (include version): IIS 10.0

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

My hosting provider, if applicable, is: it is a server hosted in Hetzner datacenter

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

So basically, everything worked fine until today, and i was unable to renew the certificate using the http method (self hosted by win-acme, or hosted by IIS). I checked with the services like GeoPeeker or GeoTargerly, the .well-known/acme-challenge/ is available from all over the world, but LetsEncrypt returns there is a connection problem.

I disabled the firewall, same thing... I was able to validate through DNS, but id like it to work via http...

Any ideas how to diagnose and fix this?

Sadly, no. I can reproduce the timeout using Let's Encrypt production. But, Let's Encrypt staging tests do not timeout. These come from different source IP addresses but they are in the same (large) data center and use largely the same network structure.

Make sure there is not a firewall that is blocking by IP address. You could check with your hosting service to see if any other customers are affected. Or, if they have another layer of blocking of some kind that would affect receiving just some HTTP requests.

We see a production timeout and staging working only very, very rarely. And, there is not much else we can do for debugging.

You've already found a good work-around in using a DNS Challenge.

If you cannot automate the DNS Challenge you should watch for a new dns-persist-01 challenge. It roughly works by adding a TXT record once to your DNS which then persists for repeated renewals. This is currently in LE Staging with hoped for rollout in production this quarter. See: DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt

I'd also suggest looking to replace win-acme with simple-acme. The principal maintainer of win-acme now focuses efforts on simple-acme. It is a drop-in replacement and is more likely to get support for dns-persist more promptly. See: https://simple-acme.com/

Switching to simple-acme will not fix the production HTTP timeout.