Hi, piping in late, but I just wanted to say that replacing certbot with acme.sh was a nightmare! I have been upgrading ISPConfig for years now and had no idea that acme.sh was supported at all. It's not obvious at all that 'replacing the SSL certificate' for the ISPConfig virtual host will also switch it from certbot to acme.sh (and possibly vice-versa). In fact, if it weren't for this thread, I would have never figured that out. It really needs to be explained more fully, starting with the message displayed by ispconfig_update.sh, and then moving on to the tutorials as well... Ok, I know, I'm just complaining because it has been a tough experience for me. Here's the kind of trouble I've encountered: the first thing was to uninstall certbot; of course I kept a backup (since I had no idea if ispconfig_update.sh would do it for me or not). Then I installed acme.sh, hoping to get the configuration right: with luck, I could get it running from /etc/letsencrypt and it would 'reuse' the same certificate files. That wasn't the case Then I basically reinstalled ISPConfig over the existing installation (using --force, as suggested), while being careful to answer 'yes' to 'replacing the SSL certificate'. This actually seemed to detect that certbot had left some residual/vestigial configuration (because it apparently created a new backup, I think) but went on to integrate acme.sh with ISPConfig3. So far, I was hopeful that this would actually work! Not by far. The first thing that ISPConfig3 needs to have is a valid SSL certificate for its own virtual host. At that stage, I was unlucky: it seems that I had a custom vhost template that was out of date, and which didn't redirect properly to the ACME directory. Although there was a perfectly valid certificate on disk, obviously it wasn't on the right path; thus, acme.sh had to request a new one, but, because the vhost template was outdated (I thought that the host template for the ISPConfig backend was separate from the others... apparently not... or maybe at this stage the installer still hadn't changed the templates?... I don't know), Let's Encrypt couldn't validate that certificate, and ISPConfig3 proceeded to create a self-signed certificate... which I didn't want to. Ok, so I aborted the installation and tried to get a new certificate via acme.sh — this time, using DNS as the validation mechanism — and now I knew where it was supposed to be installed. It was also the perfect occasion to test out the famous Cloudflare integration! No such luck, though. Something goes wrong when I use my key & email, and acme.sh does not change anything at Cloudflare whatsoever, thus popping up the error that it couldn't find a TXT record on the DNS domain which I'm using... all right, time to do it manually. acme.sh has this humorous switch called --yes-I-know-dns-manual-mode-enough-go-ahead-please which actually makes it behave in the expected way: it starts the whole process, then aborts telling me what should be the content of the TXT record for proper validation, I go over to Cloudflare to promptly add it, and run acme.sh again with the --renew option, as suggested by the script. And, indeed, this worked! For good measure, since I install ISPConfig3 on a subdomain, I thought it would be better to get a certificate for the domain itself as well — going the same route, i.e. manual validation. Success, once again! Now it was just a question of doing a lot of symbolic links — since the old templates (not yet overwritten!) still pointed to certbot's certificate layout, and acme.sh has different names and paths for everything... But at last that meant I could get the site up and running, with valid SSL certificates, and the installation could proceed. There was a nice touch of automatically placing the same certificate on Postfix (yay!) — not a moment too sooner, as I was starting to accumulate error messages from multiple mail servers complaining about the 'wrong' certificate and refusing to deliver mail... Reloading all the services is something that takes a lot of time (I have a huge database for a particular application which is not managed via ISPConifg3... and shutting MariaDB down takes æons), but, eventually, I had everything up again — just all the SSL certificates on the 'wrong' place, that is. As suggested, I next proceeded to do a 'resync' for all websites, hoping to get ISPConfig3 checking for certificates for each one of them, and storing them in the appropriate places. And, indeed, this is what ISPConfig3 tried to do. Unfortunately, it was still using my old, outdated custom template... and that meant that none of the domains could be validated via acme.sh! Arrrgh! With all sites down — and ISPConfig3 painfully plodding along each one of them and trying to get new certificates, and failing... — I then went to the custom template, compared it to the current one, and made all necessary changes, saved it... and crossed my fingers. This seemed to have fixed things... because ISPConfig3 was still going through the list of domains, and now they were being correctly validated. There was probably an issue with the first domains on the list, which I forced a resync by going to the ISPConfig3 and checking the Let's Encrypt checkbox. Fortunately, there weren't many; fortunately, this eventually worked (resync, as explained elsewhere, can take a lot of time to finish); and as far as I can see, ISPConfig3 managed to change all certificates correctly. Whew. There were a few glitches with one or two domains — they had unusual configurations and were to be retired anyway — but it was reasonably easy to get rid of them (this affected the certificates issued for them; they needed to be re-issued, in a different way; but acme.sh seemed to be able to handle all of that). Things seem to be working well now. But you can imagine my state of panic with all sites down for an extended period of time and no 'easy' solution at hand! (well, except restoring everything from the backups, but I'm a stubborn girl and hate to 'go back').