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.
I used to work at a place where people had to use PIV cards to log into certain work related websites.
What is the threat here? That you will try to bill your care to someone else's insurance?
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.
> Open-source software—with exception of Caddy—never bothered to implement OCSP stapling properly.
Apache with mod_md and Nginx with OpenSSL both do it quite well.
But stapling implementations like that haven't always existed.
Short-lived certificates seem an easier thing to implement than trying to resurrect that ecosystem by now.
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.
[1]: https://www.feistyduck.com/newsletter/issue_120_short-lived_...
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.
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.
Would be happy to discuss this with anyone