Create Lets Encrypt SSL Certs via Certbot DNS Validation in Acme v02

As I said you may want to try git-stable version or you can manually edit the renewal file for each websites but the former actually contains workaround for LE via webroot (so I haven't tried it for dns-challenge) while the later is a lot more works compared to custom vhost config which you only need to have just one master for all.

 

Thanks for your continued replies @ahrasis .

Hmm, maybe you're right, and a custom vhost config is the simplest solution.

If I go down that road, what, exactly, would I need to customize?

It looks as though ISPConfig creates symlinks in each website's "ssl" directory, whereas when ISPConfig is not used to manage the Let's Encrypt certificates, I would need to modify the custom vhost config to point to "/etc/letsencrypt/live/domain.tld...", correct?

Of course, I would also want to ensure that the LE files actually exist for a given domain before enabling them, or NGINX won't reload/restart.

Have you tried to do this before?

 

Ahhh! Upgrading to git-stable "just fixed it"! Thank you for that suggestion! Seems like it was indeed some type of bug. And now, I see all types of useful information regarding LE operations in the System Log with Debug-level logging.

Brilliant! I think everything is working to the extent that I need now!

 

Congratulations. I will take note on this as I will attempt some changes on my ISPConfig test server.

I did this actually and it works fine. Since dns-challenge is done manually, I will only add the website after LE certs via dns-challenge for it are issued.

 

I forgot to share that if your dns based LE SSL certs renewal failed, you might want to run "apt install -y python3-pip" and "pip3 install your-dns-plugin" to update your certbot and its plugin, before you can successfully running certbot renew command.

Your dns plugin could vary from certbot-dns-cloudflare, certbot-dns-rfc2136 and so on for example as discussed in post #1 and #2 in this thread.

 

To add to the ongoing dialog, I noticed today that ISPConfig 3.1.15p1 seems to fix additional problems that had occurred in earlier versions when Let's Encrypt certificates already exist for a given domain (i.e., certificates were issued via certbot on CLI) and the "Let's Encrypt SSL" box was checked subsequently in the ISPConfig interface. Excellent!

 

I want to try this; but which Script i need to use?

 

@gOOvER

Here are the notes I made for my own use. Ensure that you are on the latest version of ISPConfig before you attempt this, as there have been several bugs in the past that affect this process.

Prerequisites

Locate the appropriate installation document for the host OS in question, e.g.:

https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx.html

In short:

Code:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot python3-certbot-dns-PLUGIN

where PLUGIN represents one of the supported plugins, a list of which is provided via hyperlink in the above-cited article, e.g.:

https://certbot.eff.org/docs/using.html#dns-plugins

For DigitalOcean, for example, the package name would be python3-certbot-dns-digitalocean.

On Digital Ocean

Follow the links in the above-cited documentation for plugin-specific instructions.

For Digital Ocean:

https://certbot-dns-digitalocean.readthedocs.io/en/stable/

Once the credential file is in-place, obtaining/renewing a certificate as simple as:

Code:

certbot certonly \
  --dns-digitalocean \
  --dns-digitalocean-credentials ~/.secrets/certbot/digitalocean.ini \
  -d example.com

To automate the process and renew all certificates on the system that are sufficiently close to expiry, a cron job with the following does the job:

Code:

certbot renew --dns-digitalocean --dns-digitalocean-credentials ~/.secrets/certbot/digitalocean.ini

ISPConfig Integration

Once all of this is in-place, verify that the configuration files in the /etc/letsencrypt/renewal/ directory contain the DNS plugin information. In particular, each renewal configuration file should contain something like this (to be clear, certbot inserts these directives automatically when called on the CLI; do not add this information manually!):

Code:

# Options used in the renewal process
[renewalparams]
account = ...
dns_digitalocean_credentials = /root/.secrets/certbot/digitalocean.ini
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = dns-digitalocean

Provided the renewal configuration files look correct for the domains in question, the user should, in theory, be able to check the "Let's Encrypt SSL" box in the ISPConfig interface (if it's not already checked) and have DNS-based renewal work correctly. If the box is already checked, the certificates should be renewed automatically and remain up-to-date.

 

Wow, thank you @cbj4074 for this Guide. Now i have a direction

I'm on Debian Buster, but this is no Pproblem. I will do it for my System.

 

You're very welcome, @gOOvER ! Please do let us know how it goes for you!

 

There is some development as what I have coded and tested so far and one of them is as mentioned https://www.howtoforge.com/communit...or-ispconfig-servers.80449/page-3#post-404106

The point is the latest code use a script to ensure the recreation of ispserver.pem file via a new script (letsencrypt_renew_hook.sh) that'll be shipped with later version of ISPConfig and created for that purpose which add (--renew-hook "letsencrypt_renew_hook.sh") when requesting for LE SSL certs.

This will be basically add (renew_hook = letsencrypt_renew_hook.sh) in the server FQDN LE SSL certs renewal conf file which is to run /usr/local/ispconfig/server/scripts/letsencrypt_renew_hook.sh via its symlink in /usr/local/bin/letsencrypt_renew_hook.sh upon each renewal of the same.

As such this is advised to be added when requesting LE SSL certs via DNS validation especially if it meant for an ISPConfig server. However, before ISPConfig merge it, the latest fixed letsencrypt_renew_hook.sh can be obtained from here: https://git.ispconfig.org/ahrasis/ispconfig3/-/raw/patch-3/server/scripts/letsencrypt_renew_hook.sh

If you already obtained the certs, downloaded the above script, add it to /usr/local/bin/ and make it executable, you can also add (renew_hook = letsencrypt_renew_hook.sh) directly your ISPConfig server FQDN LE SSL certs renewal conf file so that it will take care of recreating ispserver.pem when the certs are renewed.

 

For anyone else reading through this thread for notes about LE via DNS-01, see also this project with a DNS-type/authenticator specific to ISP-config. It adds and removes TXT records from the lSPConfig-managed DNS using the API. Good use of API in Python too.

 

I am interested to know how they can actually update DNS records on all of our domains using that certbot-dns-ispconfig.

 

Intereting point but I have to say that certbot-dns-ispconfig should already be good enough for slave servers in an ISPConfig multi server setup.

I also agree that for other user should be limited to login and modify only his own domain(s) txt that is neccesary for the issuance of LE SSL certs but I am however not sure whether that should be fixed / improvised on ISPConfig or the said certbot py script, although I think it should be in the former.

One may use his own customized script as discussed in one thread but proxy script mentioned by @Jesse Norell can also be used.

There is also another thread about updating ip from a remote ISPConfig server that is using dynamic dns, which could also be relevant if one want to modify the code to remotely update txt for a specific domain in ISPConfig dns server using certbot.

That all said about certbot, if I am not mistaken, we can already use acme.sh to issue dns-01 remotely using its dns-ispconfig, but again I am not sure whether it is meant just for admin or also for user(s) or need a proxy limiting its access to user only.

 

Warning, I think the folder permissions are wrong. It should be 700 not 600. The value 600 is used for files.

 

Nope. It should be 600.

 

keeping the permissions at 600 tells me that I can not enter the folder, with 700 instead I enter and work quietly.

Sorry my bad english

 

Make sure you are root because the purpose is to hide it so nobody else without root permission can access it.