Nothing like waiting until the last minute.
I’ve been getting increasingly frequent “renew your Let’s Encrypt cert” emails but the task kept getting postponed because I didn’t have the command(s) memorized and wanted to create a cron job for it but whenever I thought of it, I didn’t have the time or whatever to look it up or do it.
That’s my excuse.
Yesterday, I received the “your cert expires in 0 days” email and promised myself I’d renew it yesterday.
This morning, I got up and had a faint hope that it expired at an exact time and not just the date. I checked that last email and the gods were merciful. I had a few hours left. Just renewed it and saw this in bright red amidst the bright green:
Encountered vhost ambiguity when trying to find a vhost for but was unable to ask for user guidance in non-interactive mode. Certbot may need vhosts to be explicitly labelled [sic] with ServerName or ServerAlias directives. Falling back to default vhost *:443 ...
I was concerned, especially because it was a particularly important subdomain, but below that I also saw (in the normal bright green):
Congratulations, all renewals succeeded.
I do want to check into that though. I’ll probably be as quick about that as I was about renewing …
I did, however, create the cron job so I wouldn’t have to stress or worry about it in the future. Things to note:
- Let’s Encrypt certs expire after 90 days
- In their tutorial for Let’s Encrypt renewal with cron jobs DigitalOcean recommends renewing every 60 days to account for a margin of error
- There is neither a @bimonthly nor @quarterly shortcut for cron jobs
That tute states, “The certbot Let’s Encrypt client has a
renew command that automatically checks the currently installed certificates and tries to renew them if they are less than 30 days away from the expiration date.” DO shows a cron task that tries the renew command every single day so if the cert is within 30 days of expiration, it gets renewed.
I know it’s a tiny little command, but I hate the idea of something happening every single day that doesn’t have to. I think running the command bi-monthly is best (“best” meaning it makes me feel like I’m beating the system) so I thought using * * 31 * * would be super-nifty. I thought months with 31 days are pretty much every other month so it would be perfect and I’m so brilliant.
When I drew it on the whiteboard I saw
- It would have worked for today (Nov 24) because Oct 31
- It would work for the next renewal in 90 days on Feb 24 because Jan 31
- Before it hits another two consecutive renewals successfully (Aug and Nov 2018) it would totally miss May 2018 because April has only 30 days.
This concept could still work if I could get it to attempt renewal on the first day of a month following any month with 31 days.
TIL: You can use
If statements in UNIX shell scripts.
For now, so that I can complete this task, we’ll just go with the first day of every month.
I’ll update this post once I write the shell script.
sudo ctrontab -e and saw what looked like an empty file. That command is what I usually see in cron tutorials. I wonder what it does …?
So, while I file that question away in a drawer I may never check, I’ll just edit the crontab file like I did in My First Cron Job post … as I suspected and hoped, my other command is, indeed, there with my new job now beneath it.
But there are still at least a couple things I want to know.
- In my first cron job, I indicated a user because one (just one) tute said to and the directions in the file have a column for that. Do I need that? I didn’t put one for my new cron job so we’ll see.
- In the first job, there’s a command to change directories which makes sense for the file and the scripts in that file. DigitalOcean’s tutorial that inspired my second job/line of code includes
/usr/bin/certbot renewbut, knowing that I can run certbot from any location, I’m going to see if I can omit that path. The script should run in a few days and I’ll also have a couple more months during which I can experiment.
- That second command in the job writes the output of renew in a file located at
/var/log/le-renew.logbut that log file didn’t exist and I haven’t created it. I’m thinking that the command creates the file if it doesn’t already exist. We’ll see in a few days.
I wish I’d noticed where the renew command I did earlier stored any output. The tute states output should have included a line saving debug info to
/var/log/letsencrypt/letsencrypt.log and I had already check in that letsencrypt folder to see if le-renew.log was in there. Trying to
cd into it as me got me
Permission denied and trying as root got me
No such file or directory!
So, as I said, we’ll see …