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