Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

> Normally ACME clients renew their certificates when one third of their lifetime is remaining, and don’t contact our servers otherwise.

At least newer versions of Certbot, and I believe some other ACME clients, will also try to discern if the certificate is Revoked when considering it. So if you have a daily cron job running Certbot, and your certificate with 60 days left on it has been revoked since yesterday, Certbot ought to notice that and attempt to replace it as if it had expired.

If you are doing OCSP stapling, and if your stapling implementation is good (sadly last I looked neither Apache nor nginx were) this ought to be enough to make a mass revocation event survivable for you. Your server will notice the latest OCSP answers now say it's revoked and continue to hand out the last GOOD answer it knew, some time later before that OCSP answer expires your Certbot should replace the certificate with a good one. Seamless.

The new ACME feature is welcome, not least because there are a tremendous number of those bad Apache servers out there, but (unless I misunderstand) I think it's already possible to survive this sort of catastrophe without service interruption.

The new ACME feature isn't just about surviving the revocation event itself. Suppose that the new API didn't exist, but every client polled on a daily basis to check to see if their cert was revoked. Then great -- within 24 hours, every server gets the new replacement certificate.

And then 60 days later, every single client tries to renew that certificate. That's another 200 million certs in 24 hours. And that'll repeat every 60 days.

So the ACME draft is also about being able to pro-actively smooth out that renewal spike. Some clients would be told to renew again immediately, less than 24 hours after their replacement. Others would be told to wait the whole 60 days. And then after a couple months of managing that, things would be back to normal.

FWIW Apache has a new stapling implementation that is not suffering from all the major problems the old one did. Can be activated with "MDStapling on".

Thanks, that's good to know. I also read their documentation explaining why they couldn't (or at least didn't) fix the old one. I will try to publicise this rather than simply saying the Apache httpd OCSP stapling is garbage in future.

It explicitly mentions two big flaws with the old one, but not the one most relevant here - out of the box Apache's old OCSP stapling would merrily staple BAD answers simply because they're newer, which makes no sense. I assume that's corrected, but if you know this'd be a good place to say.

Shouldn't that be the default config option then?

Reply on news.ycombinator.com