Any buffer of pre-issued/post-dated certificates would defeat the purpose of the short lifetime. You are supposed to request each new certificate during the val

Any buffer of pre-issued/post-dated certificates would defeat the purpose of the short lifetime. You are supposed to request each new certificate during the validity period of the previous one. Taking the extreme of 6-day certificates mentioned in the blog, you would basically be requesting a new certificate every day, giving you 5 days of warning time to address infrastructure issues, but giving Let's Encrypt or other CAs even less time to address their issues. If you visit the linked post [1] about them, it's acknowledged that it's probably not practical to deploy such short-lived certificates at scale yet. Personally, I think 15-30 days is more reasonable, as this allows a weekly cadence with more lead time for addressing issues, especially for smaller shops that might only have 1 person (half-)focused on infrastructure. Even with the maximum of 47 days in the upcoming CA/Browser Forum rules, you're going to need to set up automated reissuance attempts and alerts for when they fail (or use managed hosting that does this for you). Importantly, this only applies to HTTPS certificates. Other uses of X.509 are unaffected; e.g., code signing, API authentication, and S/MIME can still use longer-lived certificates. There hasn't been nearly as much work on automated authentication for re-issuance in these areas comparable to ACME and DNS verification for HTTPS, so I doubt those policies will change for the foreseeable future. [1]: https://www.feistyduck.com/newsletter/issue_120_short-lived_certificates_are_coming_in_2025 https://www.feistyduck.com/newsletter/issue_120_short-lived_...