3 ms·

What are the mechanics of short-lived certificates? Is there some way to pre-load several months' worth of upcoming certs so that you can rotate them into place

What are the mechanics of short-lived certificates? Is there some way to pre-load several months' worth of upcoming certs so that you can rotate them into place in the nick of time even though the cert issuer went temporarily kaput at the worst possible time?

goalieca 2y ago
The best practice is to fully automate certificate provisioning. Short lived certs force this behavior. The private key should also be minimally exposed so don’t create a bucket of private keys waiting around for some future use. Keep copies to a minimum. The other idea behind short lived certificates is that revocation doesn’t really work. It doesn’t scale, it’s handled poorly by clients, and half the time you don’t even know your cert has been compromised in order to decide to revoke it. Expiration is the only fool-proof way to revoke a cert.
kbolino 2y ago
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_...
closeparen 2y ago
The point of short-lived certificates is that you need the CA to continue affirmatively trusting and authorizing you in order to have a valid certificate.

goalieca 2y ago

The best practice is to fully automate certificate provisioning. Short lived certs force this behavior. The private key should also be minimally exposed so don’t create a bucket of private keys waiting around for some future use. Keep copies to a minimum. The other idea behind short lived certificates is that revocation doesn’t really work. It doesn’t scale, it’s handled poorly by clients, and half the time you don’t even know your cert has been compromised in order to decide to revoke it. Expiration is the only fool-proof way to revoke a cert.

kbolino 2y ago

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

closeparen 2y ago

The point of short-lived certificates is that you need the CA to continue affirmatively trusting and authorizing you in order to have a valid certificate.