It would be great if optional (advanced) site specific options for letsencrypt could be added. Specifically I would love to be able to change the following two options for certbot per page: --server (https://certbot.eff.org/docs/using.html#changing-the-acme-server) --preferred-chain (https://certbot.eff.org/docs/using.html#certbot-command-line-options) This due to the default acme server and preferred chain not working on certain older Android devices since september 30: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021 My "workaround" for those specific pages are to use another ACME server. Specifically buypass. The certbot command looks exactly the same, just needs to change --server setting from the default "https://acme-v01.api.letsencrypt.org/directory or v02" to "https://api.buypass.com/acme/directory". I had a look in /usr/local/ispconfig/server/lib/classes/letsencrypt.inc.php and this seems like a minor thing to change. Not sure how to implement i GUI, but the letsencrypt certbot file would probably just need a change to look for another thing in IF to set "$acme_version". If anyone else is interested in this I could try to write an implementation myself.
Also, just to add. This somehow looks a bit like the following feature request, but not the same since mine ads --server and is site specific - not installation wide: https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5703
I think you definitely should contribute via ISPConfig git and ask for login access from the developers if you haven't got any yet. Just note that ISPConfig preferred LE client is acme.sh and certbot is kept mainly to cover older servers and migration from them, so any proposal should cover both.
Thank you ahrasis. Will read through acme.sh since I have not done that yet. Until now all my installations have been running certbot unfortunately. Will also ask for login access from developers. Would be great to contribute.
No worries. Even if you are not familiar with acme.sh, do contribute with whatever you can as much as you can. I myself am not familiar with acme.sh but I contributed any way to the best of my knowledge, as the developers will always check all the contributed codes and give their feedback before finally merging the codes with or without changes. What I currently am doing is coding Let's Encrypt DNS challenge support for ISPConfig. For the time being I find that the dns secret access code for acme.sh, while using export command, will be kept inside ISPConfig server which I think is unsafe for the clients as this can be easily accessed by ISPConfig server admins. Except for LE client certbot, I do not find any other way to create and keep this dns secret access code inside the clients' web site root folders for acme.sh yet. I am still trying to figure it out though, but I am not really focus on resolving this as this is not my main priority and I don't think it is ISPConfig main priority either. For now, I think the best is opening this issue in acme.sh github, but I my self personally am not sure whether this is an issue at the first place.
Maybe a dumb question but wouldn't everything be available for a ispconfig / server admin no matter where you try to "hide" it in the setup? Me myself would not see it as an issue in the first place. If was to host my website(s) with someone else I would need to trust that host in the first place. I think the same way for anywhere i host servers.
However, back to the main topic: I installed a new server according to the perfect server guide for Ubuntu 20.04. But i swapped out Apache for nginx and substituted some other things to my likings. So its more or less exactly the same as Perfect server 18.x with nginx. I missed to skip certbot installation, but this did not seem to cause me any problems at all since i installed it manually using snap. I have seen others in the forum getting great headache from trying to swap from certbot to acme.sh. For me it was pretty straight forward. I removed all existing certificated I could find and uninstalled certbot using "snap remove certbot". Thereafter I just ran "ispconfig_update.sh --force" which seems to have installed acme.sh instead. So now I only need to find a way to fix two things on a per site basis: 1) Choose which CA to use when enabling "Letsencrypt" under site settings. 2) Also add the corresponding CAA entry in DNS-settings for that domain. After reading through the "acme.sh"-script (which if very well written btw) it seems to be very simple to achieve at least number 1. I just need to find a way to do it directly in the ispconfig GUI and not only manually in filesystem.
Just writing down my thoughts here for convenience and if anyone has feedback. Another alternative (or a maybe more like a hack?) to doing the GUI changes could be to add a settings file for each site directly under /var/www/clients/client[0-9][0-9]/domain.tld/ssl/.settings. And just write another IF-statement in /usr/local/ispconfig/server/lib/classes/letsencrypt.inc.php to look for this file. If no file is present then it will simply not bother. Such a setting file could look something like: server:https://api.buypass.com/acme/directory days:170 Which in turn just goes straight to the acme.sh command issued by letsencrypt.inc.php. Example for buypass: https://github.com/acmesh-official/acme.sh/wiki/BuyPass.com-CA From what I've gathered so far the crontab acme.sh will remember this for next time it makes the renewal.
By trial and error I found that /root/.acme.sh/domain.tld/domain.tld.conf contains exactly the settings needed. Those settings are written once a certificate is issued. As a temporary fix/test I did change the "Le_NextRenewTime" to the past and also changed "Le_API" to BuyPass CA. This gave me a new certificate and proves that this should be a possibility. If I renew my certificated now, the ispconfig install will fetch (if expired) a certificate from letsencrypt CA whilst my test domain fetches it from buypass. Progress.
It is true in a sense but there are duties imposed to every server admins by laws on data and privacy like GDRP and even in the common laws, therefore, it is safer to be kept in their own web site directory rather than in the server in general. The leak of such dns secret access code could be disastrous.
