The author writes "It is possible that OCSP will remain in use for specialist use cases—for example, in private environments where both sides of a communication are under the control of the same party."
This is for example the case in German health care. The insured people (and not only them) are given physical smart cards with certificates on them. I believe OCSP is used, among other uses, to detect expired cards (for example when the insured person switches to another insurer) when they are used at a doctors' office.
I really wish physical devices were more common for critical things. They are harder to steal, and people understand how tokeep physical things secure.
The thing that always bugged me about OCSP stapling is how poorly nginx handled it. I don't remember the specifics at the moment, but when the server would start up cold it would not have some necessary information cached, which resulted in the first couple of HTTPS connections to each vhost missing some OCSP data.
When combined with a certificate configuration that used Must-Staple, this resulted in the first couple of requests showing a "required feature missing" error (at least in Firefox) until the nginx cache warmed up.
When Let's Encrypt started talking about dropping some support for it, it prompted me to reexamine my configurations and conclude that I actually did not care about it. Like, at all. I removed OSCP from the sites I run back in July 2024.
I wanted to point out that this is specific to certain perspectives.
The perspective within the US government, where there continues to be a robust investment in a fully deployed system of OCSP Responders, repeaters and caching systems providing both OCSP AND CRLs is different.
This system has greater performance and greater security than an equivalent "CRL-only" type of system.
It is true that certain PKIs have negative economies around services, and have underinvested in the infrastructure they need to provide.
PKI standards in general were not written for the modern threat environment which includes grave privacy risks.
For forward deployed use-cases, and expeditionary forces, OCSP provides valuable tradeoffs in conjunction with CRLs, particularly when used to maximize each's benefit for particular use-cases.
OCSP stapling has always felt like more work than short-lived certificates. You still need to replace your certificates, but now you have a second process that refreshes the staple.
At that moment you might as well refresh the certificate.
Then there is the issue that of stolen certificates. Imagine a key and staple is stolen, the company detects it and revokes the cert.
You still have until the end of the stolen key & staple's lifetime in which they are valid, and the consumer would never know.
At least with OCSP live checking that timeframe is reduced to mere seconds, at the cost of loss of privacy.
With CRLs you have to pull more data, but you can at least reduce the vulnerable time to seconds, without privacy implications.
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?
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.
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.
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.
This is for example the case in German health care. The insured people (and not only them) are given physical smart cards with certificates on them. I believe OCSP is used, among other uses, to detect expired cards (for example when the insured person switches to another insurer) when they are used at a doctors' office.