"Validation failed: "Failed: Fetching http://test-1.valk.sh/.well-known/acme-challenge/xHpAbhkBu-Jo1t0sUnhkBZUk9rhYZIcYMZPj74exzo: Timeout after connect (your server may be slow or overloaded)"",
I'm using the Rust Acme-Micro library to automate getting certificates for users of my service. LetsEncrypt fails to verify my domain, saying the web server didn't respond, however when i use cURL on the address output by the error on a completely different network, i get the token of the challenge. My service is not proxied, though adding a proxy doesn't fix matters.
Welcome to the community @randomairborne
I also get a timeout trying that URL as does Let's Debug
Could you have some geographic based firewall perhaps? The Let's Encrypt servers that make the requests are in the US and Germany (can change any time). Let's Debug uses similar servers to test. (and I was testing from the US)
Server is in testing mode- it's off right now. Let me turn it back on.
That Let's Debug result is odd. Every time I try it I get a failure related to http response 500 Internal Server Error. Which is the same error I get from my test server doing
curl -i http://test-1.valk.sh/.well-known/acme-challenge/ForumTest
The data returned from your server is "No ACME token found" which is fair. But, it should be an http 404 Not Found. That does not explain a timeout when requesting an actual token but should be better.
The Let's Encrypt servers will make (currently) 4 identical requests from different parts of the world. Does your system maybe block repeated attempts thinking they are ddos attacks?
No, it's a fairly standard axum rust library server.
Also, it should be a 404. Let me fix that. (fixed)
I am not familiar with axum rust.
Could a firewall, router, or your hosting service be blocking such requests? Frankly, that's Let's Debug responds different points to some network interference as it always uses a token which won't be found.
This server is three Routers, two of which have the same url structure, one for http and the other for https. The http one is used for these requests. New certificates are triggered by a POST request to a different URL.
Curl can externally get in, so i doubt it's being blocked? I can also use Certbot on the same device.
Does the original request still fail? Perhaps it was temporary.
Could your server be blocking or pausing other inbound requests while it is handling the POST?
I don't have many good guesses left and will soon sign off for the night. Maybe another volunteer will pickup and have other ideas.
And, thanks for fixing the 500. I now routinely get 404 as expected and Let's Debug responds better to that too.
EDIT: Can you get a cert running certbot by hand?
Apparently being able to get root was a fluke. that's the issue, sorry for the time
I've tried a couple times on both staging and prod.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.