Cron Job For Let's Encrypt Renewal


Answer :

Solution 1:


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.



Solution 2:


I recently (October 2017) installed and ran certbot on an Ubuntu 16.04 server and a renewal cron job was created automatically in /etc/cron.d/certbot.


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.




Solution 3:


The certbot documentation recommends running the script twice a day:



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.



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'

In a docker environment (edit 2020-09-18)


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.




Solution 4:


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).



systemd timer



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 /lib/systemd/system/certbot.service



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


and 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


cron job



As others have mentioned, there is also a cron job installed in /etc/cron.d/certbot:



# 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/certbot is an executable file and that /run/systemd/system is not a directory. Only continue to the next bit if this check succeeds.


    • The systemd part of the check effectively means that if systemd is running, don't run certbot from the cron job - leave that to the timer.


  • perl -e 'sleep int(rand(43200))' - sleep a random amount between 0 seconds and 12 hours (43200 = 12 x 60 x 60).

  • certbot -q renew check your certificates and renew any if required. The -q flag 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.




Solution 5:


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.



Comments

Post a Comment

Popular posts from this blog

Converting A String To Int In Groovy

Answer : Use the toInteger() method to convert a String to an Integer , e.g. int value = "99".toInteger() An alternative, which avoids using a deprecated method (see below) is int value = "66" as Integer If you need to check whether the String can be converted before performing the conversion, use String number = "66" if (number.isInteger()) { int value = number as Integer } Deprecation Update In recent versions of Groovy one of the toInteger() methods has been deprecated. The following is taken from org.codehaus.groovy.runtime.StringGroovyMethods in Groovy 2.4.4 /** * Parse a CharSequence into an Integer * * @param self a CharSequence * @return an Integer * @since 1.8.2 */ public static Integer toInteger(CharSequence self) { return Integer.valueOf(self.toString().trim()); } /** * @deprecated Use the CharSequence version * @see #toInteger(CharSequence) */ @Deprecated public static Integer toInteger(String self) { return toInteg
Read more

"Cannot Create Cache Directory /home//.composer/cache/repo/https---packagist.org/, Or Directory Is Not Writable. Proceeding Without Cache"

Answer : if anyone pass through here, this is shorter solution: sudo chown -R $USER $HOME/.composer it seems to me the group information is missing in your command sudo chown -R <user> /home/<user>/.composer/cache/repo/https---packagist.org Shoud be sudo chown -R <user>:<group> /home/<user>/.composer/cache/repo/https---packagist.org But to avoid other permission issues, I would rather advise: sudo chown -R <user>:<group> /home/<user>/.composer/cache (you'll need access to other folders in there) and sudo chown <user>:<group> /home/<user>/.composer To make sure your user has permissions enough on the global composer folder. Mind the missing recursion so the user don't own keys created by root. If you need to find out the group: groups <user>
Read more

Android How Can I Convert A String To A Editable

Answer : As you probably found out, Editable is an interface so you cannot call new Editable() . However an Editable is nothing more than a String with Spannables, so use SpannableStringBuilder: Editable editable = new SpannableStringBuilder("Pass a string here"); If you only want to change the Spannables, never the text itself, you can use a basic SpannableString. Use Editable.Factory.getInstance().newEditable(str) From the android documentation: Returns a new SpannedStringBuilder from the specified CharSequence. You can override this to provide a different kind of Spanned.
Read more