Debian GNU/Linux 9.4 Stretch, certbot from stretch-backports version 0.23.0-1~bpo9+1. Also installed python3-certbot and python3-certbot-apache. This is a multiserver ISPConfig setup, but the LE certificate is for mail server and cerbot installed and setup manually. Mail server is a ISPConfig host, and only runs postfix, dovecot. I did not use ISPConfig to create the LE certificate, since the mail host does not run websites. Now the certificate has been running OK but Let's Encrypt Expiry Bot sent me e-mail that renew does not work. Indeed checking logs I see the renew keeps failing, and cerbot runtime errors a lot. After half a day of searching I have learned that - certbot tries to do the renew in standalone mode, which fails because Apache is already running - I tried dry-run on command line, and this does not show any errors: Code: certbot renew --apache --dry-run --cert-name mailhost.companydomain.fi I have not yet figured out how to force cerbot to stop using standalone mode, the instructions I found tell me not to modify the files in /etc/letsencrypt/renewal. But maybe standalone mode should indeed be used, but with pre and post hooks that stop apache before renew and start apache afterwards? I have until 9th July before the certificate expires. I would like to test now the automatic renewal works automatically. If I change cerbot to authenticate with apache plugin, I believe I need to restart apache afterwards to get it to use the new certificate. Same thing for postfix and dovecot. So I need to play with pre and post hooks anyway. After that long preface: How is certbot manual setup to renew generally done? It seems to me the standalone authentication would be better, since apache needs to be restarted anyway, and I can in the same hook add restart for postfix and dovecot.
When it's uncritical to stop apache for a short period and you'll have to restart it anyway, then a pre-hook that stops apache and a post hook that starts it again sound like a neat solution to me. But I haven't used that yet. My mail server still has a comodo cert, but I'll probably replace it with LE as well when it's lifespan ends.
Seems to be working automatically now. I have renewal-hooks like so: Code: root@mailhost:/etc/letsencrypt# ls -lhR renewal-hooks/ renewal-hooks/: yhteensä 12K drwxr-xr-x 2 root root 4,0K kesä 28 10:50 deploy drwxr-xr-x 2 root root 4,0K kesä 28 10:49 post drwxr-xr-x 2 root root 4,0K kesä 28 10:49 pre renewal-hooks/deploy: yhteensä 4,0K -rwx---r-- 1 root root 65 kesä 28 10:50 05-restart-postfix-dovecot.sh renewal-hooks/post: yhteensä 4,0K -rwx---r-- 1 root root 37 kesä 28 10:49 05-start-apache.sh renewal-hooks/pre: yhteensä 4,0K -rwx---r-- 1 root root 36 kesä 28 10:49 05-stop-apache.sh root@mailhost:/etc/letsencrypt# root@mailhost:/etc/letsencrypt# for f in $( ls renewal-hooks/*/*.sh ) ; do echo ; echo $f ; cat $f ; echo ; done renewal-hooks/deploy/05-restart-postfix-dovecot.sh #!/bin/bash systemctl restart postfix systemctl restart dovecot renewal-hooks/post/05-start-apache.sh #!/bin/bash systemctl start apache2 renewal-hooks/pre/05-stop-apache.sh #!/bin/bash systemctl stop apache2 root@mailhost:/etc/letsencrypt# Apache is not stopped every night, only when the certificate is due for renewal.
This is a great stuff. Basically, I think, if you are running this on a webserver, general hooks may stop the webserver most nights if there are a lot of domains on the web server, since the general hooks affect, not only the server domain, but all domains' renewals. As I am trying to understand, the same won't affect non-webserver though. I also think the best solution for a web server could be: to run certbot standalone installer properly, so that the hooks are limited to the server domain, since that way the hooks will be placed inside the server domain renewal file, instead of in the certbot general hooks folders / files. I haven't tested this but I think this could work fine: Code: certbot --authenticator standalone --installer nginx -d server.domain.tld --pre-hook /path/to/pre-script --post-hook /path/to/post-script I will test the above suggestion properly later with the new version of LE4ISPC script. Hopefully it could save us all from a lot of hassle of creating and maintaining LE SSL certs in securing ISPConfig control panel, its other servers and installed services.
I already tested the above with the new version of LE4ISPC script and it went great. Thank you for your sharing that make it possible for me to revise and improvise the original script. Now one will only need to run the code command below at any time after installing ISPConfig server to automatically create Let's Encrypt for the ISPConfig server hostname FQDN if none exists; and secure its control panel and other services; if they are available and installed. Code: cd /etc/ssl wget https://raw.githubusercontent.com/ahrasis/LE4ISPC/master/le4ispc.sh --no-check-certificate chmod +x le4ispc.sh ./le4ispc.sh You can view the code in details at my github/LE4ISPC. Thank you again.
