After running getssl with Let's Encrypt over a number of years and domains it is now failing to provide certificates.
I run getssl and it appears to hang after ... copying challenge token to ...
I can access the file .../.well-known/acme-challenge/GP5ZGeJFdrLVymzmcmcljNxF5FOqepP0uotMWWtOoQg
from the web at http://adsysergy.net/.well-known/acme-challenge/GP5ZGeJFdrLVymzmcmcljNxF5FOqepP0uotMWWtOoQg
So the file is accessible and I assume no port/firewall/https/redirect issues.
The access logs do NOT show a request from Let's Encrypt for the token.
The access logs do show any manual attempt by me to access the file, showing a 200 code as expected.
I used LetsDebug.net HTTP-01 and get a All OK! No issues were found with adsynergy.net.
Domain: adsynergy.net
Command: getssl -w /usr/local/getssl adsynergy.net
Response:
Registering account
Verify each domain
Verifying adsynergy.net
copying challenge token to /usr/www/adsynergy.net/.well-known/acme-challenge/GP5ZGeJFdrLVymzmcmcljNxF5FOqepP0uotMWWtOoQg
... and there it sits and hangs here for as long as I wait (1/2 hr)
Web server: apache-tomcat-10.1.48 (only, no Apache httpd )
OS: Fedora 42
Hosting provider: OVH
Root login: Yes
Control panel: No, bash only
Client: getssl V2.49
There is no AAAA record.
I don't think it is a "hang" between the Let's Encrypt server and theirs.
They describe waiting a half-hour but LE would never wait that long before timing out.
My guess is for some reason getssl never posts the challenge. It would be helpful to see a more detailed log. I don't recall offhand how to do that with getssl - it has been too long since I used that one
There may be a typo too. Their domain is adsynergy.net but the HTTP example they show succeeding uses adsysergy.net
My understanding is that getssl does not have a log file and prints everything to the terminal. (Google confirms). If that is true then the response:
Registering account
Verify each domain
Verifying adsynergy.net
copying challenge token to /usr/www/adsynergy.net/.well-known/acme-challenge/GP5ZGeJFdrLVymzmcmcljNxF5FOqepP0uotMWWtOoQg
is all there is.
I ran getssl with --debug and it is at; https://adsynergy.net/getssl-debug.txt
Plenty of output to wade through.
Thanks for your response.
I will try disabling the pre-check (on another domain).
I can do a browser http or a curl request as you suggested and get the expected token. That implies the http is being served OK, although I could be miss-understanding.
In my frustration of trying to get the site certified I tried Certbot using a DNS cert, and did get that to work, so the site now shows https certification. The Certbot/DNS solution worked, but I can't imagine putting up with the "DNS round robin" problem in the long run.
I will continue to try with getssl on another domain (same system, same problem)
I posted my getssl.cfg file(s) at: https://adsynergy.net/getssl.cfg
I set SKIP_HTTP_TOKEN_CHECK="true" and
IT WORKED!
So there is a issue with getssl getting access. I'm starting to understand your comment "Perhaps you have a firewall blocking HTTP outbound requests?"
Many thanks!
The getssl precheck sends an HTTP request to check the token before asking Let's Encrypt to try. It's handy to avoid faulty systems from sending requests to LE. But, can cause problems of its own in certain cases
