31 October 2024
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.
Are we ready for forty-five-day certificates? Apple seems to think so. On October 10, 2024, CA/B Forum ballot SC-81 appeared as pull request #553 in the Server Certificate Working Group’s repository. Just like that, without a warning.
Before Apple’s pull request, Google was on record for wanting ninety-day certificates at some point, which is why Apple’s proposed forty-five days (by September 2027, over three yearly milestones) came as a shock. But this very small number is not in itself scary: if you’re going to focus on automation, doing things more frequently is the best way to ensure the automation is smoothly implemented. In this case, with certificate lifetime limited to forty-five days, the idea is to get new certificates monthly, leaving about fifteen days for dealing with problems.
But the real questions are: “Why?” and “Are we ready for it?” The why part is possibly easy to explain. In essence, the reduction of certificate lifetimes became inevitable when browsers stopped checking certificates for revocation. Although we often hear that “revocation is broken” and that “revocation is not reliable,” that’s not accurate; browsers decided to drop revocation, and that’s that.
This created a big security hole for anyone who loses control over their private keys—for example, via a security intrusion. It’s technically possible to evolve certificates that opt into revocation (the so-called must-staple indication), but that’s also not a feature the browsers want to support.
The problem with this answer to “Why?” is that it’s difficult for the affected IT workers to accept. Their life is difficult for reasons that have never been fully explained and communicated to the public. Having some answers would make the conversation easier.
To be clear, there is a very good argument to avoid certificate lifetimes that are too long: doing otherwise would limit the ecosystem’s ability to deprecate weak cryptographic primitives. The SHA1 transition took longer than we wanted. However, going below one year breaks an important psychological boundary and increases manual issuance workloads manifold. Is one year too long? Why?
As for “Are we ready for it?” Well, the truth is that nobody really knows for sure. Looking around, we see that there still are CAs who don’t support automated issuance, as well as many systems that can’t use automation. Even leading web server software such as Nginx and Microsoft’s Internet Information Server do not support ACME natively. Not to mention that there are various hardware appliances and IoT systems that don’t have support and which operate on very long replacement cycles that take years.
So, what’s next? SC-81 is not yet an official ballot. It’s been discussed only briefly so far, with the next discussion planned for October 31. We’ll find out what happens next then. Last time, Apple forced the reduction of certificate lifetimes to 398 days, but the world was ready and most people believed that more than a year is too long anyway. This time, the situation is not as clear.
This subscription is just for the newsletter; we won't send you anything else.
Here are some things that caught our attention since the previous newsletter:
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.