CertKit
Abstract
For twenty years, Certificate Authorities ran the perfect protection racket.
Nice website you got there. Shame if it was “Not Secure.” That’ll be $300 a year.
The CAs had a beautiful monopoly. Browsers needed them to keep users safe. Websites needed them to look legitimate. Everyone paid up, nobody asked too many questions. Then the cryptography of most certificates (SHA-1) got shattered, and the browsers realized they’d been played.
This is the story of how certificate lifetimes went from 3 years to 47 days, why the CAs fought every second of it, and what it means for your certificates.
How server certificates work
It’s called the WebPKI: the Public Key Infrastructure. Companies called “Certificate Authorities” (CA) create a Root Certificate. From that root, they sell you a certificate that proves you are who you are, and you use it to secure your website.
For that to work, the Root Certificate needs to be included with Chrome, Firefox, Safari, and all the other browsers and certificate consumers out there. Here’s how it works:
- Joe opens mysite.com in Firefox
- mysite.com says, “ExampleCA said I’m cool”
- Firefox has the ExampleCA Root Certificate, so shows Joe that mysite.com is indeed cool
For Firefox to trust the ExampleCA Root Certificate, they needs to meet a set of security and operational standards called the Baseline Requirements. This is the common rulebook that CAs are audited against for compliance.
The Baseline Requirements are created and maintained by the CA/Browser Forum, a self-regulating organization of CAs and Browser vendors that try to improve the security of the internet through consensus votes on changes to the Baseline Requirements.
But here’s where it gets interesting: Each browser also maintains its own Root Program with additional requirements beyond the Baseline Requirements. Chrome has one. Apple has one. Mozilla has one. If a CA wants their root certificate trusted, they need to follow both the Baseline Requirements AND each browser’s specific rules.
For years, this system worked. CAs issued certificates that lasted up to three years. If something went wrong, there was supposedly a certificate revocation system (CRL), but everyone knew it was broken. Too slow, too unreliable, too privacy-invasive. Chrome doesn’t even check revocation lists. So if a certificate was compromised, you just waited for it to expire. In three years.
This delicate balance held until SHA-1 showed everyone what “waiting” really cost.
The SHA-1 Betrayal
Each certificate is based on a cryptographic algorithm, and one of the most popular algorithms was SHA-1, developed by the NSA.
But in 2005, the first attack was published against SHA-1, showing that it could be cracked open, however it would require over $100,000 in processing power to do it.
The CA’s weren’t worried. “It’s only theoretical,” they said. “Too expensive to be practical.” The protection money kept flowing.
In 2015, the severity of the problem escalated when researchers proved that SHA-1 could be cracked in a few minutes with a $2,000 video card in an event named “The SHAppening”.
The response from CAs was predictable: “Our customers aren’t ready. The migration is too expensive. We need more time.”
Microsoft disagreed, and in one of the first major challenges to the CAB forum, unilaterally said that SHA-1 certificates could not be created after 2016. No votes. No discussion. It was insecure for their users and they weren’t going to allow it anymore.
But because certificates were valid for 3 years, that meant that SHA-1 certificates could still be floating around until 2019, nearly 15 years after the algorithm had first been cracked.
Consensus is where progress goes to die
Over the next few years, various people and browser vendors tried to address the underlying problems of long certificate lifetimes, only to be met with stonewalling and frustration.
Ballot 185: Google’s attempt to prevent the next SHA-1 (2017)
Fresh off the SHA-1 disaster, Google’s Ryan Sleevi proposed reducing certificate lifetimes from three years to 398 days (13 months).
The logic was straightforward:
- Broken certificates naturally expire faster
- Annual renewals align with existing IT maintenance cycles
- Problems like SHA-1 can be fixed in one year instead of three
- Since revocation doesn’t work, expiration is our only reliable tool
The CAs protected their turf. Only 8% of Entrust’s customers had automation—that meant 92% were still paying for manual processes and support. DigiCert worried about enterprise customers with complex approval processes. Smaller CAs argued it would drive customers to the big players who could afford automation infrastructure.
When the vote came, the measure had failed due to overwhelming opposition from the CA’s.
Ryan’s frustration boiled over on Twitter:
Carefully consider the commitment to security of any CA who votes No [to Ballot 185].
He was calling out the racket directly. The CAs weren’t protecting users—they were protecting revenue.
Ballot SC22: The alliance of browsers (2019)
Two years later, Google returned with Apple and Let’s Encrypt backing them. They had new evidence:
- Between certificate lifetime and domain validation re-use, stale certificates could persist for up to 4.5 years!
- Domains change hands frequently, but old certificates remain valid
- Support tickets proved customers literally forgot their renewal procedures after two years
The CAs demanded evidence of real-world harm, not theoretical problems. “Show us actual incidents,” the CAs said.
The browsers pointed to SHA-1. That was theoretical until it wasn’t.
The vote split exactly as before. Browsers: unanimous yes. CAs: overwhelming no.
The committee had failed twice.
Apple changes the game (2020)
At the February 2020 CA/Browser Forum meeting in Bratislava, Apple made an announcement that changed everything:
Effective September 1, 2020, certificates valid for more than 398 days will not be trusted in Apple products.
No vote. No consensus. Just a unilateral change to their Root Program requirements. They cited the forum’s failures to pass Ballot 185 and SC22 as reasons they needed to act alone.
The CAs were stunned. Chris from Entrust captured their sentiment: “The Forum was created to set these policies together. This undermines the entire process.”
But Mozilla and Microsoft countered: “We saw the same resistance with SHA-1. After the ballot failed, CAs didn’t move. Sometimes we have to act to protect users.”
Within days, Mozilla and Google signaled they would follow Apple’s lead. The 398-day limit was happening whether CAs liked it or not.
Ballot SC31: Browser Alignment (Late 2020)
The Baseline Requirements were, at this point, very different than the practical rules of the browsers’ Root Programs. To make them useful again, the browsers wanted to update the Baseline Requirements to reflect what was already happening: Apple’s 398-day limit that others were adopting, amongst other things.
This vote became existential. If the Forum couldn’t even update its requirements to match reality, why does the forum exist?
Ryan Sleevi laid out the stakes: If CAs blocked this, browsers may as well abandon the Forum entirely. Instead of one shared audit against Baseline Requirements, each browser could require its own separate audit. The cost multiplication to CAs would be devastating.
Faced with this reality, SC31 passed. But the power dynamic had permanently shifted. Browsers could now make unilateral changes and force the Forum to catch up.
Risks of stale certificates mount
By 2024, there was mounting evidence of the dangers posed by even 398-day certificates. Certificates only represent validation at the moment they’re issued. But that validation was being cached for up to a year, and certificates issued from that cached validation lived even longer.
Ian Foster and Dylan Ayrey coined this “stale certificate” problem as BygoneSSL. Their research showed a simple but devastating issue: domains change hands constantly (companies switch vendors, contracts end, or subsidiaries get sold) but the certificates remain valid. A fired vendor could have legitimate certificates for your subdomain for over a year after you terminated their access.
Then, Zane Ma from Oregon State University presented research at the October 2024 CA/Browser Forum meeting that quantified exactly how bad this was. His paper found that 7% of all certificates were stale, and that shortening certificate lifetimes to 45 days would reduce the impact of domain takeover attacks by 95%. The difference between 398 days and 45 days wasn’t incremental improvement, it was the difference between massive vulnerability and relative safety.
The Market proved short-term certificates work (2024)
But the final nail in the coffin was market data. Let’s Encrypt grew from 0.1% market share in 2020 to 59% in 2024.
Let’s Encrypt is a non-profit CA launched in 2016, backed by Mozilla, the EFF, and other tech giants who were tired of certificates being a barrier to HTTPS adoption. Their radical idea: give away certificates for free, make the process completely automated, and only issue 90-day certificates. No upsells. No extended validation. No manual processes.
CAs said it would never work. Enterprises couldn’t handle 90-day certificates. The automation was too complex. Customers needed phone support. But 8 years later, Let’s Encrypt issues certificates for the majority of the encrypted web. They process millions of renewals daily. All automated. All 90-day lifetimes. And users don’t know or care about the difference between a free, short-lived cert from Let’s Encrypt and an expensive, year-long cert from Digicert.
The road to 47 days (2025)
Spurred and shamed by Zane Ma’s research and the success of Let’s Encrypt, in January 2025, Apple, Google, and Mozilla introduced Ballot SC081 with a shocking timeline to reduce certificate lifetimes:
- March 2026: 200 days maximum
- March 2027: 100 days maximum
- March 2029: 47 days maximum
The CAs tried to protect their turf: Enterprise customers have change freezes. Government systems require extensive approvals. Legacy applications can’t automate. Please, keep 100 days as the minimum.
But unexpected support came from the customers themselves. Netflix joined the CAB as an “Interested Party” to share: “We need these deadlines to justify automation investment internally. Approval of this ballot is justification enough to resource this work.”
Even Cisco, representing the enterprise perspective, admitted that while five years would be ideal for implementation, the direction was inevitable.
The most telling objection came from a CA: “This proposal seems anti-competitive, giving advantage to companies with better certificate lifecycle management.” They were right, and that was exactly the point. It’s time to automate or get out of the way.
The vote didn’t really matter. If it didn’t pass, Apple or Google or Mozilla was going to do it anyway. But the CAs agreed and 47 day certs became reality.
What happens next
47 Day certificates are happening. The real question is whether your infrastructure will be ready.
Some companies are already there. They’ve been using Let’s Encrypt for years, renewing every 60-90 days automatically. Dropping to 47 days is just a configuration change.
Others are scrambling. They’re evaluating ACME clients, testing automation workflows, and discovering just how many random systems need certificates: that ancient Java application, network appliance, or vendor system that only accepts manual certificate uploads.
And many are just now realizing what’s coming. They’re still on manual processes, still treating certificate renewal as a quarterly maintenance task. They’re about to have a very bad time.
The new certificate business
The same CAs that insisted automation was impossible for their customers are now selling automation platforms: DigiCert CertCentral, Entrust Certificate Hub, Sectigo Certificate Manager. How much extra are they charging for these tools? Contact sales to find out, of course.
The irony is rich. For years, CAs said enterprises couldn’t handle 90-day certificates. Now they’re selling those same enterprises “solutions” to handle 47-day certificates. The certificates themselves? Basically free, thanks to Let’s Encrypt. The management platforms? That’s where the real money is now.
Instead, lots of folks build the automation themselves based on CertBot and bash scripting. But you quickly find that all the features of a Certificate Management System are difficult to debug and maintain when you have a thousand other responsibilities.
The CAs will charge you enterprise prices to manage the complexity they helped create. Or you can build your own solution and discover why certificate management is everyone’s least favorite infrastructure project.
That’s a crappy choice, and it’s why we built CertKit. Because we don’t have conflicting interests. We don’t sell certificates. We just want certificate management to not be your problem anymore.
CertKit is certificate management software built for the 47-day future. Currently in beta for teams who’d rather automate now than panic in 2029.