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: *.mindtrek.dnsalias.net (several hostnames)
lego client always worked and no longer works
switched to acme.sh and have same exact behavior
What happens (with lego client 4.22 or earlier Linux or Windows, or acme.sh):
- with csr or single domain specified same result
- authentication tokens are probably written and then deleted in /.well-known/acme-challenge (all permissions in place for the client)
- after a few retries the client exits with a "timeout" error message (Invalid status. Verification . . .: Fetching http://about.mindtrek.dnsalias.net/.well-known/acme-challenge/gsEF_ffwmUbW7NX_WuWLRxd4UGSsJ_siq22unNe27Fo: Timeout during connect (likely firewall problem))
- !!! as mentioned there was no GET coming from the letsencrypt server and there
- but a tcpdump trace and the nginx logs sdhow no connection attempt
- creating the same token with vi in the acme-challenge folder and accessing it (e.g.) at http://about.mindtrek.dnsalias.net/.well-known/acme-challenge/ works fine from curl or a browser
I ran this command:
lego client (single domain not even with csr)
./lego --email="contact@mindtrek.dnsalias.net" --domains="www.mindtrek.dnsalias.net" --http --http.webroot=/var/www/html/4lego_mindtrek.dnsalias.net --accept-tos --http-timeout=300 run
acme.sh:
./acme.sh --log --server letsencrypt --issue --signcsr --csr ./mindtrek_all_any.csr -w /var/www/html/4lego_mindtrek.dnsalias.net | tee acme_sh.log
It produced this output:
[Tue Mar 11 02:32:00 UTC 2025] about.mindtrek.dnsalias.net: Invalid status. Verification error details: 37.27.253.25: Fetching http://about.mindtrek.dnsalias.net/.well-known/acme-challenge/gsEF_ffwmUbW7NX_WuWLRxd4UGSsJ_siq22unNe27Fo: Timeout during connect (likely firewall problem)
[Tue Mar 11 02:32:00 UTC 2025] Please check log file for more details: /root/.acme.sh/acme.sh.log
My web server is (include version):
nginx 1.26.2 or apache 2.4 same behavior
The operating system my web server runs on is (include version):
Ubunto 24 x64
My hosting provider, if applicable, is:
N/A
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, strait cli
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
It is not certbot - lego 4.22 and acme.sh latest
In the acme.sh log (more verbose than lego) can see
[Tue Mar 11 00:31:14 UTC 2025] Verifying: about.mindtrek.dnsalias.net
[Tue Mar 11 00:31:14 UTC 2025] d='about.mindtrek.dnsalias.net'
[Tue Mar 11 00:31:14 UTC 2025] keyauthorization='QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE.VkgCNKsVKO3HpNJWf8DiOxczHYP7SysLgb2knGwYoSk'
[Tue Mar 11 00:31:14 UTC 2025] uri='https://acme-v02.api.letsencrypt.org/acme/chall/2274296956/487869013746/tVZI0w'
[Tue Mar 11 00:31:14 UTC 2025] _authz_url='https://acme-v02.api.letsencrypt.org/acme/authz/2274296956/487869013746'
[Tue Mar 11 00:31:14 UTC 2025] _currentRoot='/var/www/html/4lego_mindtrek.dnsalias.net'
[Tue Mar 11 00:31:14 UTC 2025] wellknown_path='/var/www/html/4lego_mindtrek.dnsalias.net/.well-known/acme-challenge'
[Tue Mar 11 00:31:14 UTC 2025] Writing token: QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE to /var/www/html/4lego_mindtrek.dnsalias.net/.well-known/acme-challenge/QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE
[Tue Mar 11 00:31:14 UTC 2025] Trigger domain validation.
[Tue Mar 11 00:31:14 UTC 2025] _t_url='https://acme-v02.api.letsencrypt.org/acme/chall/2274296956/487869013746/tVZI0w'
[Tue Mar 11 00:31:14 UTC 2025] _t_key_authz='QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE.VkgCNKsVKO3HpNJWf8DiOxczHYP7SysLgb2knGwYoSk'
[Tue Mar 11 00:31:14 UTC 2025] _t_vtype='http-01'
[Tue Mar 11 00:31:14 UTC 2025] =======Sending Signed Request=======
[Tue Mar 11 00:31:14 UTC 2025] url='https://acme-v02.api.letsencrypt.org/acme/chall/2274296956/487869013746/tVZI0w'
[Tue Mar 11 00:31:14 UTC 2025] payload='{}'
. . .
[Tue Mar 11 00:31:26 UTC 2025] code='200'
[Tue Mar 11 00:31:26 UTC 2025] original='{
"identifier": {
"type": "dns",
"value": "about.mindtrek.dnsalias.net"
},
"status": "invalid",
"expires": "2025-03-18T00:31:05Z",
"challenges": [
{
"type": "http-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/2274296956/487869013746/tVZI0w",
"status": "invalid",
"validated": "2025-03-11T00:31:14Z",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "37.27.253.25: Fetching http://about.mindtrek.dnsalias.net/.well-known/acme-challenge/QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE: Timeout during connect (likely firewall problem)",
"status": 400
},
"token": "QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE",
"validationRecord": [
{
"url": "http://about.mindtrek.dnsalias.net/.well-known/acme-challenge/QJ8fNDLE_bi9hRHFlpirUBbPDtM578oedjedCzTn1XE",
"hostname": "about.mindtrek.dnsalias.net",
"port": "80",
"addressesResolved": [
"37.27.253.25"
],
"addressUsed": "37.27.253.25"
}
]
}
]
}'
