Content

Introductory

A Let's Encrypt free of charge SSL certification that the websites we operate are secure HTTPS protocol.

In this tutorial we will install Let's Encrypt Certbot system one ISPConfig3 server environment. Once the installation is complete, our system is ready to be managed on the server domain to obtain and automatically configure and automatically renew free SSL certificates of names so that we can switch any of the websites we manage to HTTPS with a few clicks.

Purchase a Certbot

We'll need Certbot to get started ACME (Automated Certificate Management Environment) client, which will automatically ask us for the latest SSL certificate from the Let's Encrypt CA or renew it when needed.

In this tutorial I will describe two ways to get Certbot: Using Package Manager and downloading and running the certbot-auto script. Both have their own roles, and I go into more detail on the logic on the fly.

Obtaining a certbot using the package manager

I recently installed this on my Debian 8 server and it works nicely on the site a few days ago with SSL enabled.

First, you need to enable the Debian Package repository in the Debian package storage list, where packages are placed sooner than in the stable.

Open as root APT package manager source list:

nano /etc/apt/sources.list

And let's add the line corresponding to our Debian version:

Debian 9 (Stretch) system:

deb http://ftp.debian.org/debian stretch-backports main

Debian 8 (Jessie) if you still want to install with this:

deb http://ftp.debian.org/debian jessie-backports main

Save and refresh the container with apt-get command:

apt-get update

Then install the certbot package (for Apache):

Debian 9 (Stretch)-I:

apt-get install python-certbot-apache -t stretch-backports

Here is the official version of the package 0.28.0-1 9 + ~ bpo1

Debian 8 (Jessie) for:

apt-get install python-certbot-apache -t jessie-backports

Here is the version of the package: 0.10.2-1 8 + ~ bpo1

So this is a much older package here, so it is understandable that the Certbot-auto method for Debian 8 is suggested below. Perhaps sometime later, Debian's 8 backport will include the newer package, and they will recommend it again.

(For Nginx, the python-apache-certbot instead of a nginx-python-certbot install package.)

We have nothing else to do here, the rest ISPConfig performs. So don't run Certbot commands manually.

After installing the Certbot package, create a cron file: /etc/cron.d/certbot, where you put the following:

[...]
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

This cron entry runs 12 every hour on the Certbot validator, which checks the validity of domain certificates twice daily and requests a new SSL certificate if it is less than 30 days for any web page.

Removing obsolete packages (optional)

Since I also belong to this group, I will now delete the old certbot package and install the certbot-auto script instead, which will provide the latest program version.

Even though the old certbot has been running smoothly so far, I am replacing it just to be able to speak credibly about its operation.

apt-get remove certbot

This is not written in the official description, but I even delete the dependency packages left (as suggested by the output of the APT command above) and then re-install whatever is needed in the certbot-auto script:

apt-get autoremove

With that, he downloaded a lot of python packages.

This is also not mentioned in the official description, that after deleting the packages the old cron entry is retained, which runs the same way every 12 hours. Also delete or comment this, otherwise the cron system will report an error because the old certbot startup file has been deleted, so the / Usr / bin / certbot path.

rm /etc/cron.d/certbot

So we've got everything out of the old certbot, ready to use the new certbot-auto script for accessibility.

Get certbot by downloading the certbot-auto script

This method is only recommended when installing on Debian 8, since as we have seen above, packages in Debian 9 are already fresh enough to be installed from the package manager.

Download and make the certbot-auto script executable a chmod command:

mkdir /opt/certbot
cd /opt/certbot
wget https://dl.eff.org/certbot-auto
chmod a+x ./certbot-auto

The certbot-auto script works with the same switches as the previous version and updates itself when executed. This will run the latest version each time you scan.

Launch the program in Apache mode (or --apache without a switch in Nginx mode) to initialize the system itself:

./certbot-auto --apache

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: linuxportal.info
2: www.linuxportal.info
[...]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Lists the domain names you find on the server and asks which one we want HTTPS connection to.

Do not select anything here as this would extend the Virtual hosting files, which is not recommended in the ISPConfigos server environment. Therefore, press ct here and then enter.

In the log file (/var/log/letsencrypt/letsencrypt.log) there are some errors that the script did not finish properly (because we quit), but we do not need to address this.

Enable Let's Encrypt SSL in ISPConfig3

If you've got one of these methods, here's the more convenient part: Activate Let's Encrypt SSL on a web page.

Log in to the ISPConfig system as an Admin and then sites From the main menu, select the webpage you want, click on it, and in your form (the default Domain tab) check the SSL and Let's Encrypt checkboxes below.

Luckily, I just have a website on hand, which doesn’t hurt if I get an SSL. So now I can get excited live to make things go well. :)

When you save the form, the usual red circle appears above, indicating that your ISPConfig cron will update your changes within 1 minute. In the meantime, you can look in the log file at a terminal to see what's happening:

cat /var/log/letsencrypt/letsencrypt.log

When you run it a couple of times, the process just starts and the first log entries arrive with lots of information, including key, pem files, parameters in JSON arrays and what you saved to. In the end, the point is:

2018-12-03 21:08:17,160:DEBUG:certbot.reporter:Reporting to user: Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/xxxx.hu/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/xxxx.hu/privkey.pem
Your cert will expire on 2019-03-03. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew *all* of your certificates, run "letsencrypt-auto renew"
2018-12-03 21:08:17,161:DEBUG:certbot.reporter:Reporting to user: If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

So in the end, the certbot-auto script successfully retrieved the SSL certificates and tells us what to do when it comes to renewal, which is obviously not covered because ISPConfig will do it for you.

Yeah, and I had an alias domain redirected to the site, of course, it requested certificates with and without www.

Finally, if everything works fine and we have prepared the web page to use HTTPS, then in ISPConfig you can turn on the web page settings Redirecting Go to the tab "Rewrite HTTP to HTTPS". This redirects all HTTP requests with an 301 header redirection to the appropriate HTTPS address, which is completely SEO friendly solution.

Troubleshooting

Luckily for me, I haven't had any problems with Let's Encrypt's debian packages yet, and the transition to the current certbot-auto script has been smooth, so here I can only provide clues as to where to look around in case of an error. In general, the easiest way to identify and fix errors is to beetle log files. That’s why I’ve just put together a few helpful tips to make it easier to detect and resolve any errors that might arise.

Let's Encrypt log file

View Let's Encrypt log file:

cat /var/log/letsencrypt/letsencrypt.log

ISPConfig cron log file

For updates, see the ISPConfg cron log file:

cat /var/log/ispconfig/cron.log | grep certbot -C 20

Here we search for the word certbot, and display the line 20-20 before and after the line found, to see what's happening with the certbot.

Debugging ISPConfig's Let's Encrypt cronjob

Run the following in the terminal as root to see the output of the Let's Encrypt cron task executed by ISPConfig:

php -q /usr/local/ispconfig/server/cron_debug.php --cronjob=900-letsencrypt.inc.php

This comes in handy for certificate renewal errors.

ISPConfig Let's Encrypt cronjob file overview

The following php file is run by ISPConfig when executing the cron job above. So, if there is something tangled, it is worth looking into whether there is something wrong with the different paths, etc.:

nano /usr/local/ispconfig/server/lib/classes/cron.d/900-letsencrypt.inc.php

Of course, do not modify the file in any way, it should be a good starting point to detect any errors.

View Let's Encrypt renewal configuration files

Go to the following directory:

cd /etc/letsencrypt/renewal

And there are .conf files per domain. This way, you can also find useful information in the config file of the webpage in question, such as acme subdirectories point to the right place, etc.

Conclusion

Thus, SSLs on web pages now work on ISPConfig.

This description was mostly for those who walk in similar shoes as I did: The previously installed perfect server configuration didn't include Let's Encrypt SSL at the beginning, so I had to install it on the fly or replace the old version again. But I hope others will find it useful as well.