Looking at a few docs, probably not many. In any case there isn't (?) an in-band way to tell the clients that the cert is going to be revoked before it is revoked, so there would be some disruption.
And this is one reason why I keep advocating for certificate automation to be built into services/apps, rather than patched on the outside with duck tape.
I look forward to the day when cert lifetimes are regularly about as short as OCSP responses. Then we can possibly do away with OCSP entirely.*
(* I am of the opinion that revocation is fundamentally broken for Web PKI and it should be phased out in favor of short cert lifetimes. You may disagree and that's fine, but I'm happy to discuss why if you're interested.)
Instead of running certbot on every server, I wrote a custom ACME client that runs on a master server and is responsible for requesting/renewing all certificates that I use. It also automatically deploys each cert to the correct server.
It is a single point of failure but it makes tracking certificate expiry, renewal and revocation so much easier.
(And depending on the storage backend, it's no longer a single point of failure. And even if storage is the failure, it's just storage, if it's down your servers will keep running.)
The bulk of the work was already done for me as there was already an ACME library for my language.
I'll probably open source it once I have a chance to clean everything up.
And that’s okay.
I call it "The Prometheus monitoring I already needed to make sure my servers are up and serving the websites they're supposed to"
Absolutely. Especially with the advent of protocols like ACME it just makes sense.
Here's a nice blogpost from smallstep (not affiliated) on this topic: https://smallstep.com/blog/passive-revocation/
Why do you think the maximum lifetime was reduced from two years to one?
Does it make a lick of difference if you’re man-in-the-middled for just one year instead of two? What kind of argument is that!?
“Oh, they got every active user credential and form that was submitted ages ago, but no worries! This won’t go on for another year! Just months to go now…”
No, obviously the CA cartel just wanted to extract 2x the rent.
The whole thing is just absurd on its face and needs to stop, but there are billions of dollars worth of rent seekers that say…
“No.”
The reduction to 398 days was imposed by Apple, unilaterally, although in practice the ecosystem went along with it. It actually took a few weeks to get clarity on exactly what Apple intended, they just basically blurted it out at a meeting.
- One year instead of two? Yep
- 3 months instead of 1 year? Yep.
- 1 week instead of 3 months? Yep.
The reason certificates have traditionally been so long is because it was a manual process. Using ACME it is possible to expire certificates every hour if you wanted to do that.
Now it seems that revocation is supposed to help the CA covering up mistakes made by the CA.
Maybe we actually need a better CA.
Go for it. Start one and tell us how it went.
So okay, maybe you don't have certs revoked and you don't need to restart your Traefik but are you really sure everything is okay?
1. Supposedly more secure challenge types such as TLS-ALPN-01 are far from stable, as the current incident shows. Your cert can be revoked at any time through no fault of your own. After being burned by TLS-SNI-01 the last time, now I refuse to use anything other than plain old HTTP-01 and DNS-01.
2. As soon as the version of the Linux distro I was using (not in my power to change!) reached EOL, certbot suddenly refused to renew, despite the fact that I'd been using more or less the same version of Python and certbot for a number of years and the HTTP-01 challenge requires nothing fancy at all. Why does everyone these days insist on making ops decisions for other people?
3. On a server with existing nginx virtual hosts, certbot injects configuration directives including stuff the nginx team officially recommends against, such as `if` statements. It frequently breaks existing configuration such as rewrites and redirects. After seeing this a number of times, the only conclusion I can make is that certbot has no idea how to manipulate nginx config files.
4. If I have multiple domains pointing at the same application, and remove one of them at a later time, certbot is oblivious and repeatedly fails trying to renew the certificate that now contains an invalid domain. Again, certbot doesn't know how to work with nginx.
Maybe 3 and 4 can be improved if ACME was integrated as a proper nginx module instead of certbot trying to change things from the outside. My experience as a whole, however, makes me feel that the LE/certbot teams are rather cavalier about the commitment to stability they need to make if they really want to become an essential part of the world's internet infrastructure. If you want to be paternalistic about managing TLS for people who don't know how to do it, at least try to do it properly!
If you don't like how the nginx plugin works, then fork it.
Wrapping "certbot renew && nginx -s HUP" into a systemd service doesn't seem to be a very complex thing to do.
The fact that there are alternatives, though, doesn't mean that the crappy "official" client isn't doing the LE ecosystem a disservice.
All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists.
If you somehow don't have to worry about MITM you don't need anything remotely close to the complexity of TLS.
Certificate revocation is mostly security theater.
You can imagine the DDOS-ransomers licking their lips at this possibility.
No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.
That's not correct. OCSP stamps exist to prevent that kind of a problem.
Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...
Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing.
HN is doing its silly "slow down" nonsense, so I will reply to the reply below by editing here.
The implementation quirks of one particular CA (LE) are not features of these protocols; they are features of that particular CA's policies.
To @mhils: CAs could easily stand up simple servers that let you ask for the most recent certificate (if any) issued to a given domain and public key.
They don't want to do this because it's a burden. The only reason they run OCSP servers is that they're under pressure from insurers, regulators, and auditors to participate in the whole revocation theater game. Saying "we don't do revocation" would cause people to freak out, and setting up an OCSP server takes effort, but less effort than explaining to the insurers/regulators/auditors that revocation doesn't actually work.
As for CT, the log could simply include an extra (issuer-signed) field which amounts to "I will auto-renew this certificate until $DATE" and omit all the additional certificates issued to that same public key and domain name between the log entry and $DATE. Of course the browser would need to understand this field in order to validate the CT log entry.
I'm not sure super-short expiration is really preferable; it makes the Web even more fragile than it already is. Frankly I think Web PKI is sort of a big mess at this point. Most of it only makes sense when viewed through the lens of "(a) governments will always control DNS for the the two-letter TLDs, (b) Google cannot get all governments to supplicate to Google, therefore (c) we must conjure up an extra layer of entities (the CAs) that can be bullied around by manipulation of browser engine code". This is basically the only reason why DANE (or a modernized revision of it) isn't used.
Regardless, even if "functionally equivalent", there is a practical difference: LE does not allow me to issue a certificate every minute, but does allow the OCSP Must-Staple extension.
Of course it is revocation, it allows you to revoke a certificate before its normal expiration (90 days for LE).
I could make this argument in reverse: "very short lifetimes are functionally equivalent to OCSP Must-Staple, and thus is a form of revocation". Of course, this is ridiculous both ways: being similar or even 'functionally equivalent' does not make two things the same.
If you compare (1) a short-lived certificate and (2) a long-lived certificate with Must-Staple and short-lived OCSP responses, the benefits, security properties and failure modes of both are exactly the same*. You're just putting the timestamp into different fields.
(* Or almost: Some notable practical differences are described in the sibling comments - but those are mostly a property of LE's current policies, not the protocol itself)
Without revocation, a compromised cert remains useful to an attacker for the entire validity period of the cert, it they can MITM you.
With revocation, they must MITM you constantly to prevent you from acquiring the revocation list. This substantially adds to cost and complexity of such an attack, and means that many, if not all clients will be protected.
So it's not perfect, but ask what the world looks like without it.