Add CERT_PROFILE support, fix DST Root CA X3 renewal loop, and improve ARI renewal scheduling#607
Add CERT_PROFILE support, fix DST Root CA X3 renewal loop, and improve ARI renewal scheduling#607Sausageroll2077 wants to merge 13 commits into
Conversation
There was a problem hiding this comment.
Thanks for opening this pull request! Be sure to follow the pull request template!
|
While testing this on Unraid, I noticed every container restart was looping into a revoke + reissue cycle when CERT_PROFILE=shortlived was set. The cause is the existing legacy check that tries to detect certs still on the expired DST Root CA X3 cross-sign: I changed it to check for the actual bad chain: This way it does not interfere with the new intermediates that shortlived introduces. |
|
Looking at it again I think this checking for this old le root certificate should just be removed can't imagine anyone is still running with that cert. will add it in this pr for now since it causes issues with the new intermediate certificates from le. |
Run certbot renew every 6 hours instead of once daily, as recommended by Let's Encrypt for short-lived certs with ARI support. Randomize the cron minute offset at container start to spread renewal load across instances. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Relocate the renewal cron minute randomization from init-certbot-config to init-renew so the expiry check is logged before the cron schedule. Also remove the hardcoded "overnight (2:08am)" from the log message. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Change certbot renew cron from once to twice daily per Let's Encrypt ARI recommendation - Fix cron randomization sed pattern to match */12 hour field - Update log message to reflect twice daily schedule - Update readme to reflect twice daily cert checks via ARI - Remove outdated reference to Let's Encrypt expiration emails Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Run certbot renew twice daily per Let's Encrypt ARI recommendation - Randomize cron minute offset on startup to spread renewal load - Show next scheduled renewal check time at startup - Update docs to reflect twice daily cert checks via ARI - Remove outdated reference to Let's Encrypt expiration emails Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Changed the pull request to better reflect all changes. |
Description:
1. CERT_PROFILE environment variable
Adds support for the
CERT_PROFILEenvironment variable, allowing users to request a specific Let's Encrypt certificate profile via certbot'spreferred-profileflag. Supported profiles:classictlsservershortlivedtlsclientZeroSSL does not support ACME profiles and the variable is silently ignored when
CERTPROVIDER=zerossl.2. DST Root CA X3 fix
Removed the check for the expired DST Root CA X3 certificate since it wascausing certbot to trigger constant unnecessary certificate renewals at start
3. ARI-aware renewal scheduling
Changes certbot renew from once daily to twice daily (
*/12) per the Let's Encrypt Integration Guide recommendation to check ARI at least twice daily.Additionally randomizes the cron minute offset (0–59) on each container start to spread renewal load across instances, and logs the next scheduled check time at startup.
Updates the readme to reflect twice daily cert checks via ARI and removes the outdated reference to Let's Encrypt expiration notification emails which ended in June 2025.
Benefits of this PR and context:
CERT_PROFILE enables users to adopt shorter-lived certificates today. This is directly relevant to the whole SWAG userbase given Let's Encrypt's announced roadmap:
Lays the groundwork for support for ip certificates which requires 6 day certs.Six-Day and IP Address Certificates Available in Certbot
As certificate lifetimes shorten, ARI renewal windows become proportionally narrower. The twice daily cron change is forward-looking — what currently only matters for shortlived users will affect all SWAG users as default lifetimes decrease.
DST Root CA X3 was causing unnecessary renewal attempts on affected systems.
How Has This Been Tested?
Built the Docker image locally on an Unraid server and tested:
CERT_PROFILE=shortlivedin staging and production mode — received a 6-day certificate both times:grep renewalInfo /config/log/letsencrypt/letsencrypt.logsuggestedWindowresponse showing a ~3 hour window set at the cert's halfway point (day 3 of 6)Source / References: