acme.sh is more stable, that's why all new ISPConfig systems use it. Why replace stable software with a less stable one?
I'd say it's possible but the ISPConfig developers clearly prefers acme.sh over certbot as @till made that clear above and before. You may need to remove acme.sh and all its traces, install certbot via snap and then force update ISPConfig, creating LE certs for the server while updating and later on for the website(s) as well, if you have created any LE certs for it / them before. In my test that worked but it may be best for you to follow their advice on that i.e. simply maintain acme.sh for that ISPConfig server.
Because we get the certificates issued with certbot, but not with acme. The problem I stated in another thread is still there and is not solved.
Then you should take a look into the log files and use the ISPConfig debug mode to find out which mistake you made while setting up your system that causes LE certs to fail. E.g. one reason can be that you left out the step to disable dash shell on Ubuntu and Debian systems, but this is shown by debug mode.
Here are the steps to follow to find out why you don't get LE certs: https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/
We did follow that guide. This is the output of the acme.log Code: [Tue 22 Feb 2022 08:38:13 AM CET] Pending, The CA is processing your order, please just wait. (4/30) [Tue 22 Feb 2022 08:38:13 AM CET] sleep 2 secs to verify again [Tue 22 Feb 2022 08:38:15 AM CET] checking [Tue 22 Feb 2022 08:38:15 AM CET] url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w' [Tue 22 Feb 2022 08:38:15 AM CET] payload [Tue 22 Feb 2022 08:38:15 AM CET] POST [Tue 22 Feb 2022 08:38:15 AM CET] _post_url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w' [Tue 22 Feb 2022 08:38:15 AM CET] _CURL='curl --silent --dump-header /root/.acme.sh/http.header -L -g ' [Tue 22 Feb 2022 08:38:16 AM CET] _ret='0' [Tue 22 Feb 2022 08:38:16 AM CET] code='200' »»»»»»»» [Tue 22 Feb 2022 08:38:16 AM CET] crap.mydomain.com:Verify error:Fetching http://crap.mydomain.com/.well-known/acme-challenge/Iq7cVYS_TUnEdb1IUyTmwXeu8Zfd_fm-6P_TMd6RkY8: Timeout during connect (likely firewall problem) [Tue 22 Feb 2022 08:38:16 AM CET] pid [Tue 22 Feb 2022 08:38:16 AM CET] No need to restore nginx, skip. [Tue 22 Feb 2022 08:38:16 AM CET] _clearupdns [Tue 22 Feb 2022 08:38:16 AM CET] dns_entries [Tue 22 Feb 2022 08:38:16 AM CET] skip dns. [Tue 22 Feb 2022 08:38:16 AM CET] _on_issue_err [Tue 22 Feb 2022 08:38:16 AM CET] Please check log file for more details: /var/log/ispconfig/acme.log [Tue 22 Feb 2022 08:38:16 AM CET] url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w' We disabled the firewall before that.
Looks like access from LE servers to that website does not work. Have you tried yourself in browser from outside your local LAN that same URL?
Like @Taleman mentioned, access from outside your network to the domain crap.mydomain.com on port 80 is blocked. Let's encrypt must be able to access the server to verify the SSL cert.
No. Let's encrypt (no matter if you use certbot or acme.sh) tries to connect from their servers (which are in the public internet) to your system on port 80 on the domain you try to get a cert for. if they can't reach the system on port 80, then issuing of the cert will fail. And it will fail in the exact same way for certbot too, both LE clients do exactly the same procedure.
No, LE must be able to access that website and that file. Hard to say. Try in browser yourself to see what happens.
At the time the cert request was issued, http://crap.mydomain.com/ could not be reached from the internet. This does not has to be a firewall on your system, it can also be a firewall in front of your system or a router in front of your system. Or the domain pointed to a wrong server at that time, might be the case as well.
And just to mention it, you must test that from a system that is not in your network (the network of the server), might just be that you can access it but nobody else incl. LE can access it.
It does seem to be closed. Strange. I tried to access the domain using lynx and it timed out. UFW is enabled again and p80 is opened. Any ideas
The thing is that we have tried with certbot and with that a cert was issued. (long gone installation, we went nuts )
Then it's likely that the domain pointed to a wrong system or a firewall was closed at the time you used acme.sh and this has changed at the time you started using certbot. As I mentioned already, certbot an acme.se do the exact same validation procedure. So there is no reason to switch to certbot as the issue was not acme.sh in your case.
The problem is solved and you were right. This server has two IP addresses and the thing was that one of the was listening to p80, but the other IP was associated with the domain name. hahahaha! Embarrassing! Thank you!
You liked it too fast. Actually it was I who cheered too fast. I was using my own DNS and that I got to work (still the thing with the IP), but when I go back to the org I am helping and their DNS (which also is ClouDNS.net, but a GeoDNS, they should have purchased a DDOS protected), then it doesn't work again. Grrr! So it has to do with the GeoDNS despite that the region is set to Default. Anyone who has some experience with that GeoDNS thingy? Could that cause this?