Is this correct way to set cron for renewal of Let's Encrypt cert in Apache2 ? I use Ubuntu 16.04.
@monthly letsencrypt renew && service apache2 reload
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Monthly is not frequent enough.
This script should run at least weekly, and preferably daily. Remember that certs don't get renewed unless they are near to expiration, and monthly could cause your existing certs to occasionally be expired already before they get renewed.
The name of the program is
certbot, which was renamed from
letsencrypt. If you are still using
letsencrypt, you need to update to the current version.
Aside from those issues, it's about the same as my cron jobs.
43 6 * * * certbot renew --post-hook "systemctl reload nginx"
Note: in 18.04 LTS the
letsencrypt package has been (finally) renamed to
certbot. It now includes a
systemd timer which you can enable to schedule
certbot renewals, with
systemctl enable certbot.timer and
systemctl start certbot.timer. However, Ubuntu did not provide a way to specify hooks. You'll need to set up an override for
certbot.service to override
ExecStart= with your desired command line, until Canonical fixes this.
I recently (October 2017) installed and ran certbot on an Ubuntu 16.04 server and a renewal cron job was created automatically in
Here's the cron job that was created:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
It would be a good idea to check, if this file already exists before creating a crontab entry.
The certbot documentation recommends running the script twice a day:
if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.
As Michael Hampton mentions the name has changed to certbot, but they still provide the -auto option that keeps itself updated. The
certbot-auto command need root priviledges to run, so the line in your cron script should look something like this:
52 0,12 * * * root /full/path/to/certbot-auto renew --quiet
In my own case the
certbot-auto script is placed in the git-user's home directory. The exact command is then
52 0,12 * * * root /home/git/certbot-auto renew --quiet
Note that the example in the documentation corresponds to a relative path, as indicated by the dot which can be confusing:
./path/to/certbot-auto renew --quiet
Be sure to testrun the renew command in a shell beforehand to test the path, if the certificate isn't due for renewal nothing will happen (run this test without the
--quiet flag to see what is happening).
It is not strictly necessary to reload the server when the certificate is renewed in this way, since the path to the live certificate doesn't change if set up correctly.
This is true if you are running apache - for nginx, consider adding a renew hook, such as:
52 0,12 * * * root certbot renew --renew-hook 'service nginx reload'
While the above is still true to the best of my knowledge, if your application is running in a docker environment you can let this proxy network take care of all your certificates - both locally and in a live environment. I'm not affiliated with the project, but I've been using it happily for a few years now and haven't touched cron (for this task) or certbot-scripts since.
It has the added benefit of forcing traffic through port 443 automatically (if you enable it) so you don't have to fiddle with apache or nginx configuration - the container serving the web application just need to serve port 80 and the proxy takes care of the rest.
You shouldn't have to set up anything. Any recent Debian/Ubuntu install of certbot should install a systemd timer and a cron job (and the cron job will only run
certbot if systemd is not active, so you don't get both running).
You can check your systemd timers using command
systemctl list-timers (or
systemctl list-timers --all if you also want to show inactive timers). Something like this:
% sudo systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Fri 2018-08-03 06:17:25 UTC 10h left Thu 2018-08-02 06:27:13 UTC 13h ago apt-daily-upgrade.timer apt-daily-upgrade.service Fri 2018-08-03 11:43:29 UTC 15h left Thu 2018-08-02 16:54:52 UTC 3h 7min ago certbot.timer certbot.service Fri 2018-08-03 12:44:58 UTC 16h left Thu 2018-08-02 19:14:58 UTC 47min ago apt-daily.timer apt-daily.service Fri 2018-08-03 19:43:44 UTC 23h left Thu 2018-08-02 19:43:44 UTC 18min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Mon 2018-08-06 00:00:00 UTC 3 days left Mon 2018-07-30 00:00:09 UTC 3 days ago fstrim.timer fstrim.service
The certbot timer should be here
/lib/systemd/system/certbot.timer and it will execute the command specified in
certbot.timer will execute the `certbot.service at 12 am and 12 pm, after a random delay of up to 12 hours (43200 seconds).
# cat /lib/systemd/system/certbot.timer [Unit] Description=Run certbot twice daily [Timer] OnCalendar=*-*-* 00,12:00:00 RandomizedDelaySec=43200 Persistent=true [Install] WantedBy=timers.target
certbot.service will execute the renew command.
# cat /lib/systemd/system/certbot.service [Unit] Description=Certbot Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html Documentation=https://letsencrypt.readthedocs.io/en/latest/ [Service] Type=oneshot ExecStart=/usr/bin/certbot -q renew PrivateTmp=true
As others have mentioned, there is also a cron job installed in
# Eventually, this will be an opportunity to validate certificates # haven't been revoked, etc. Renewal will only occur if expiration # is within 30 days. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
This is doing:
test -x /usr/bin/certbot -a \! -d /run/systemd/system- check if
/usr/bin/certbotis an executable file and that
/run/systemd/systemis not a directory. Only continue to the next bit if this check succeeds.
perl -e 'sleep int(rand(43200))'- sleep a random amount between 0 seconds and 12 hours (43200 = 12 x 60 x 60).
certbot -q renewcheck your certificates and renew any if required. The
-qflag is "quiet" - don't produce any output unless there is an error.
I was originally confused by the cron job as it wasn't going to run due to systemd, so how would certbot be run? I found the answer in this forum post which is what I based this answer on.
For LetsEncrypt certificate renewal, I generally use getssl. It is a very handy shell wrapper which can even install certificate on other machines via SSH connection.
The cron entry is the following:
01 23 * * * root /root/scripts/getssl/getssl -u -a -q >>/var/log/getssl.log 2>&1 ; /usr/sbin/apache2ctl graceful
As already suggested, you should run it daily or, even better, twice a day.
As already mentioned by glaux:
Note: if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.
So i ended up using this (running is twice a day, at 01:00 and at 13:00 everyday):
6 1,13 * * * certbot renew --post-hook "service apache2 restart"
or even better:
6 1,13 * * * certbot renew --renew-hook "service apache2 restart"
I didn't test but this should work also:
6 1,13 * * * certbot renew --post-hook "/etc/init.d/apache2 restart" 6 1,13 * * * certbot renew --renew-hook "/etc/init.d/apache2 restart"
--pre-hook and --post-hook hooks run before and after every renewal attempt. If you want your hook to run only after a successful renewal, use --renew-hook in a command like this.
This is what I use:
gives output as:
Upgrading certbot-auto 0.8.1 to 0.9.1... Replacing certbot-auto... Creating virtual environment... ... new certificate deployed with reload of apache server; fullchain is /etc/letsencrypt/live/host.simplecoin.cz/fullchain.pem ------------------------------------------------------------------------------- Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/host.simplecoin.cz/fullchain.pem (success)
And its saying that apache is restarted already, so no need to do it over again. If I run it again:
Cert not yet due for renewal
therefore it's not problem to renew certificate daily, my cron is then:
I use script to tweak logging to separate file, so here is my cronautorenew.sh:
#!/usr/bin/env bash printf "\nattempt to renew certificates" >>/var/log/letsencrypt_cron.log 2>&1 date >>/var/log/letsencrypt_cron.log 2>&1 /opt/letsencrypt/letsencrypt-auto renew >>/var/log/letsencrypt_cron.log 2>&1 printf "renew finished\n" >>/var/log/letsencrypt_cron.log 2>&1
If your Certbot certificate was obtained using the
standalone plugin then you might need to stop your web server in order for the renewal to succeed. This can be done in cron using the
--post-hook operators: Certbot documentation.
According to EFF certbot guide
Many Linux distributions provide automated renewal when you use the packages installed through their system package manager.
If you are not sure whether or not your system has this already automated, check your system’s crontab (typically in
$ crontab -l and systemd timers
$ systemctl list-timers.