Renew in cronjob, but still expired certificate


#1

My domain is: carsonevans.ca

I ran this command: in a cron

#minute hour    mday    month   wday    who     command

0       6       *       *       *       root    certbot renew --quiet --post-hook "service nginx restart"

It produced this output: I don’t know where cron output goes

My operating system is (include version): Freebsd 10

My web server is (include version): nginx version: nginx/1.10.1

My hosting provider, if applicable, is: Digitalocean

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

So I have the renew running in a cronjob, but my certificate expired today. I thought if you ran the renew command every day it would renew once the certificate had 30 days or less to expire?


#2

Hi @carc1n0gen, the cron job is indeed supposed to do what you expected (renew certificates prior to their expiry). My best guess is that perhaps your cron job isn’t running regularly at all. Do you have a way of checking whether it is running successfully? You said that you don’t know where cron output goes.

One possibility on some systems is that there will be e-mails sent to the user root with the results of cron jobs; do you have a way to log in as root and read e-mail?

One thing that comes to mind for me is that the specification of the user root in the crontab file (that is, the who field) only applies to /etc/crontab and not to other crontab files (at least for vixie-cron; I’m not sure if you’re using something different on FreeBSD). Which crontab file is your command in and how did you install the crontab? Also, how did you install Certbot and how would you normally run it if you weren’t running it from cron? What happens if you run the same command as root from a command line without cron?


#3

Finally, sometimes the PATH for cron jobs is different from the PATH for interactive shells, so that might be something to look at (which directory is certbot in, and is that directory a default part of the search path for cron jobs?).


#4
  1. I can try to read mail, but I have no idea how to. I have root shell access through ssh

  2. I edited the crontab by running crontab -e as the root user

  3. I installed certbot through the package manager of my os, and I run the same command without the --queit and --post-hook when not run from cron and works fine (thats how I fixed my cert issue)

  4. Good point about the PATH cron uses. I’ve now used the which command to see where certbot was and put the full path in the crontab.


#5

So for me on Linux, doing this edits a crontab that should not specify the who field, which only applies to /etc/crontab. So I would expect the appropriate line to be something like

0       6       *       *       *       certbot renew --quiet --post-hook "service nginx restart"

instead of

0       6       *       *       *       root    certbot renew --quiet --post-hook "service nginx restart"

On my Linux vixie-cron, the form you specified would wrongly interpret “root” as part of the command rather than as a username.


#6

I didn’t know about /etc/crontab I opened it up and I don’t see my certbot part. But if I run crontab -e I do see my stuff. I don’t know where my crontab is going then :stuck_out_tongue:


#7

Not all systems have mail facilities installed, but you could try running mail, or else less $MAIL or cat $MAIL to see if you have a mail file at all.


#8

Thanks, I didn’t know a personal crontab had different columns than the system one. Do you think I should continue to use the root user contab and remove the root field, or switch to /etc/crontab?


#9

I think the root user crontab is OK. You could try testing my hypothesis by making the command be

* * * * * root touch /tmp/root-hello
* * * * * touch /tmp/noroot-hello

and then seeing which files get created in /tmp after one minute has gone by.


#10

Your hypothesis is indeed correct. Only the /tmp/noroot-hello was created


#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.