Certbot should not add itself to cron for renewals - should be opt in

Feature Requests
1

Certbot is added to cron to run on the following schedule:
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# 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(3600))' && certbot -q renew

My issue is that i have multiple haproxy servers, one active, one passive. Certbot is installed on both (they are in a heartbeat failover with VRRP), and when this jobs runs on passive it fails miserably b/c it does not own the IP address that the domains point to. In addition, i have wrapped the certbot renew command in a script that if successful, will push the certificates into haproxy’s cert folder, reload haproxy, and then sync the certificates, both in the letsencrypt directory and the haproxy directory to the passive proxy server (which ever is passive at the time).

I think this should be an opt in and not a forced cronjob as the installation is not aware of the server configuration on which it runs. To give a bit more information, i terminate SSL at haproxy and use ALPN to send http 1.1 or 2 down the correct ports to nginx,which does not listen on a secure port, but is within a private network. Renewing only the certs into the letsencrypt directory is not helpful to all.

BTW, i love the software, just disagree with this assumption. I have disabled both the cronjobs on both servers and manage it myself (based on active/passive).

Food for though, hopefully, or perhaps useful information for someone in the same boat. being on AWS its actually possible i could have 4 haproxy instances one day soon as we may run out of two different regions, with only one being active at a time.

Thanks,
Jeff

2

Hi @jeffd,

Our intended design is that you can do this kind of stuff with --pre-hook and --renew-hook, which let you add custom behavior before a renewal is attempted and after it succeeds. In cases where you're getting the certificates on one machine and then pushing them to another, I guess we would not suggest running Certbot on the passive machine.

3

Thanks for the reply @schoen, i agree that it should not run on the passive machine (and my renew script does not), but the passive could become active at any time, the cron jobs were installed automatically at some point, which is my main issue. As an engineer (and dev ops guy) i think this sort of assumption can be dangerous, in this case benign as the passive does not have the correct IP.

Yes, I could use --renew-hook to call my scripts, but i also like the concise reporting i provide for myself and team, by having certbot renew in the middle of the script. I currently manage about 70 domains (not counting the sub-domain portion) and that is very likely going to grow and want to see something work for me, before i install it in cron.

Feature request seemed better than help, but i’m not calling on action exactly, just food for thought imo.

Again, thanks for your reply. Feel free to close this.

4

That cron line (which exits immediately in case systemd is installed) comes along with certbot.service for systemd. So for example on ubuntu 16.04 you should change args in certbot.service, not in /etc/cron.d/certbot.

5

thanks for the heads up @dandelionred, done!