Yes this is a delight compared to the old way of having to hand over $10 or whatever to someone for a certificate that one had to remember to renew in a timely fashion versus just using a cron job now with LE.
Why use a cron job? I have certbot running in one Docker container, the .well-known route directing to the one dedicated Docker host running certbot, and whenever certbot renews the certificate, it writes the cert to the NAS share that is only mounted on the LBs and then triggers a SIGKILL to the haproxy docker containers (which causes haproxy to re-read the cert file and configuration).
Fully automated, no cronjobs to fail. In addition, I have a monitoring on all LBs that verifies the expiration time - it has never hit so far. That cronjob/monitoring is something everyone should have anyway because a well working monitoring system can alert you to so many other possible failure states...
> I have certbot running in one Docker container, the .well-known route directing to the one dedicated Docker host running certbot, and whenever certbot renews the certificate, it writes the cert to the NAS share that is only mounted on the LBs and then triggers a SIGKILL to the haproxy docker containers (which causes haproxy to re-read the cert file and configuration).
Is this really more stable than a simple cronjob? It is far more complicated, for sure, so there should be significant benefits to make up for that.
Well, depending on how you install certbot, it sets up a cron job automatically for you (on Debian, anyway). It's no big deal - it just creates the cron file /etc/cron.d/certbot.
I'm curious as to how you get certbot to renew automatically without a cron job or some sort of script in the Docker container that periodically runs 'certbot renew'.
Or "I won't have to think about this for three years, and everything will keep working during that time, and I don't have to worry about a cron job failing"
I don't mind offering 90 day certificates, but requiring it goes against the offered reason of LE to expand HTTPS.