I seem to be having an issue with running the ssl renew command when using cron.
I am near 100% certain that I have the right configuration in my crontab -e(I have it set to renew once a month). Im running ubuntu OS.
I will post the command when I am done with my commute but wanted to see if this ticket might get any traction in the mean time. The command I run works to renew the cert when I simply run it myself.
Is this not how the auto renew should be done? I am assuming someone has encountered this before me.
Thanks in advance!
First off, this is not the recommended way to set up cron. Best practice is to run renewal twice a day. Certbot will only attempt to renew certs within 30 days of expiration by default.
However, as to the reason cron isn't renewing, we're going to need some more information as there could be dozens of reasons. Seeing the cron job itself, as well as the logs after the scheduled job runs would be the first steps.
As there are no specific details I can only guess the answer is NO.
And that you are doing something different between when you successfully "run it myself" and fail "when using cron".
Well. Figured out what was wrong. Someone messed up the A record on the hosting which was causing the insecure messages when visiting the site.
I will definitely update it to renew after the second month! thanks for the info all.
If you’re using Certbot, you can literally run
certbot renew every day (we’ve even suggested twice per day). It looks at the expiry time of each certificate, so it means “renew anything that’s a month from expiring”, not “renew everything”.
…Alright changing it back to 1 month now. Ha. thanks all.
If you do run it that infrequently, I hope you have a very reliable way that it can notify you if it fails (for example, due to an intermittent CA service outage).
Any recommendations or basic bash to parse response?
We would usually suggest running it every day with
50 2 * * * certbot renew or whatever in
Ubuntu ppa package https://launchpad.net/~certbot/+archive/ubuntu/certbot sets up renewing logic for you via
- cron task under
/etc/cron.d/ (it exits immediately on systemd systems)
- systemd service+timer
Both ways it runs renewal twice a day. I use the ppa on ubuntu 16.04.
In case you need to tune agruments for certbot (by default it runs
/usr/bin/certbot -q renew) on a systemd system run
systemctl edit certbot.service
set your args like
ExecStart=/usr/bin/certbot renew -q --pre-hook /my/pre/hook --post-hook /my/post/hook
save and exit the editor. Done.
I followed this DO guide to configure LetsEncrypt for my server: http://livemnc.com/ssl-certificates/
The guide worked great, however the auto-renew cron job does not seem to fire on my server. I keep having to go in and manually run the update command to get my certs renewed.
I followed the guide carefully and placed the following in my crontab ( sudo crontab -e )
30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log
35 2 * * 1 /etc/init.d/nginx reload
here is a dump from the le-renew.log file… I’m not a backend guy so I may have missed something but I did not notice anything fishy. https://gist.github.com/tconroy/81187d31badd09cc0e2b468997cf1549
wonder if there’s any extra configuration I need to do to get auto-renew working?
I think you gave us the wrong link because that’s not a DO guide.
I’m a little confused by why there is no output in that log file other than the OS package update information, but I’ll point out that you aren’t using
renew as we intended it to be used. The default behavior of
certbot renew is to check each installed certificate’s expiration date and renew it if it’s less than 30 days away from expiry.
Because of that,
certbot renew can be run very frequently—we recommend running it twice per day. It will almost always look at the local certificates and decide that no action is necessary yet.
Although I don’t know why you don’t see messages to this effect in your logs, I’m guessing that the
renew script decided that no action was necessary and therefore didn’t take any action.
There is a form
--force-renewal where every certificate is forced to be renewed immediately, regardless of how close to expiry it is, but for various reasons we don’t recommend using that from
cron. If you do want the certificate to be renewed sooner than 30 days before expiry, you can edit the renewal configuration files in
/etc/letsencrypt/renewal and set
renew_before_expiry to a higher value than the default
30 days (bearing in mind that if you choose a value higher than 82 days or if you have multiple certificates for subdomains of the same domain, you might run into rate limits from the certificate authority side).
For comparison, you could check what happens when you simply run
/opt/letsencrypt/letsencrypt-auto renew yourself on the command line. Hopefully it will say something to the effect that it checked your local certificates and found that none of them were due for renewal yet.
Also, depending on what plugin you used, you may not need to reload nginx explicitly from your cron job. (With
--nginx you probably don’t, while with
--webroot you probably do.) Rather than always reloading nginx after running the renewal script, we have a form called
--deploy-hook where you can say
--deploy-hook "service nginx reload" or similar, in which case Certbot itself will run this command after obtaining new certificates.
0 18 * * * /usr/local/sbin/certbot-auto renew --quiet --no-self-upgrade
Im not understanding – what would deploy hook be in nginx or certbot?
We might have caused some unnecessary confusion by having a new person come into your thread and ask a possibly unrelated question. (Maybe I should have split it out into a new topic!) My recollection was that we thought your setup was OK… did you see something that made you think otherwise?
Just trying to understand the part of --deploy-hook in the process of renewing. Would I need to implement that for my nginx running?
If you got the certificate with
--nginx, then no. If you got the certificate with
certonly --webroot, then probably yes.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.