The story everyone knows about a certificate authority dying is the DigiNotar story. In 2011 the Dutch CA was breached, an attacker minted fraudulent certificates for Google and used them to intercept traffic in Iran, and within weeks the company was declared bankrupt and its roots were yanked out of every browser. It’s a good story because it has a villain, a break-in, and a fast, total collapse. It’s also almost nothing like how CAs actually die.
Entrust died a different way, and a more instructive one. There was no breach. No stolen key, no forged certificate for anyone’s bank. What killed Entrust as a public TLS certificate authority was paperwork — a slow accumulation of missed deadlines and late filings until the people who decide which CAs browsers trust simply stopped believing it would get better.
The trust model runs on an audit trail, not on cryptography
Here’s the thing people get wrong about the CA system. They think being a certificate authority is fundamentally a cryptography job — guard the private keys, sign things correctly, use strong algorithms. That part matters, but it’s the easy part, and it’s not what browser root programs actually spend their time policing.
What they police is process. A public CA operates under the CA/Browser Forum’s Baseline Requirements, a long document that specifies, in unglamorous detail, how you must behave. When a certificate needs to be revoked because it was mis-issued or its key was compromised, you have to do it inside a hard deadline — as little as 24 hours for key compromise, five days for other problems. When you have an incident, you have to disclose it publicly, promptly, and completely, in a bug tracker the whole ecosystem can read. When you say you’ll fix something, you’re expected to actually fix it by the date you named.
None of that is cryptography. It’s operational discipline, and it’s boring, and it’s exactly what a CA is really being trusted to do. A CA that signs certificates with perfect math but revokes them three weeks late is not a strong CA with rough edges. It’s a CA that has told the ecosystem, repeatedly, that its promises don’t bind it.
What Entrust actually did wrong
That’s the frame you need to read the Entrust distrust correctly, because if you go looking for the smoking gun — the breach, the leaked key — you won’t find one.
What you’ll find instead is a pattern. Starting in early 2024, a series of Entrust compliance incidents piled up in the public Mozilla bug tracker: certificates that violated the rules and had to be revoked, revocations that missed their deadlines, and — the part that actually did the damage — commitments to improve that came and went without the improvement. Mozilla later counted 22 separate incidents involving Entrust in a single stretch between March and May of 2024. Not one catastrophe. Twenty-two ordinary failures, and a running theme of the CA explaining why it hadn’t fixed things rather than fixing them.
In June 2024, Google’s Chrome Security team published a post with a bureaucratic title — “Sustaining Digital Certificate Security” — and a blunt verdict inside it. Over the preceding several years, they wrote, they had observed a pattern of compliance failures, unmet improvement commitments, and a lack of progress on publicly disclosed problems. Their conclusion wasn’t that any single Entrust certificate was unsafe. It was about the organization: they no longer had confidence that Entrust’s certificates would reliably be issued and managed the way the rules require. That loss of confidence, not any technical defect, was the whole basis for the decision.
Sit with how different that is from DigiNotar. DigiNotar was the system reacting to a catastrophe after the keys had already leaked. Entrust was the system reacting to drift — pulling trust proactively, on process grounds, before anything blew up. The second kind of death is healthier and historically much rarer, and it’s a sign the ecosystem got better at policing itself.
The mechanism: a distrust-after date
Browsers didn’t flip a switch and break the internet. They used a scalpel called a distrust-after date, and it’s worth understanding because it tells you what the punishment actually is.
Chrome’s rule, shipping in version 127 around November 1, 2024, was this: TLS server certificates issued after October 31, 2024, chaining to Entrust’s or AffirmTrust’s roots would no longer be trusted. Certificates issued before that date kept working normally until they expired. Mozilla did the same thing with its own cutoff, distrusting Entrust certificates issued after November 30, 2024. Apple followed as well. (Chrome on iOS was the odd exception — on iOS, Chrome uses Apple’s platform trust store rather than the Chrome Root Store, so the Chrome Root Program’s decision didn’t reach it.)
The graceful part is real: nobody’s already-deployed certificate suddenly threw an error. Website operators had a runway to migrate. But look at what the date-based cutoff does to the CA itself. If no browser will trust any certificate you issue from tomorrow forward, you can still honor your existing certificates as they wind down — but you cannot sell a new one that works. A CA that can’t issue a trusted certificate isn’t a CA anymore. It’s a company running out the clock on its own inventory.
The quiet ending
That’s exactly how it played out. In January 2025, Entrust announced it was selling its public certificate business to Sectigo; the transition finished that September, with Entrust’s certificate customers migrated onto a CA the browsers still trusted. Entrust framed the move as sharpening its focus on identity and post-quantum cryptography, which is the kind of thing a press release says. The plain reading is that once the root programs stopped trusting new Entrust certificates, there was no public-TLS business left to run, so it sold the customers to someone who could serve them and walked away from the line.
Nobody got hacked. No key leaked. A decades-old certificate authority exited the public TLS market because it kept filing its incident reports late and missing the deadlines it set for itself.
The lesson worth keeping
The uncomfortable, clarifying truth under all of this is where the power actually sits. The security of TLS doesn’t rest on 150 certificate authorities so much as on the handful of root programs — Chrome, Mozilla, Apple, Microsoft — that decide which of those 150 get to matter. They don’t need a court, a breach, or even a single provable act of harm to remove a CA. A sustained pattern of sloppiness is enough. That’s a lot of concentrated power, and it’s worth being honest that it exists. But it’s also the mechanism that let the ecosystem eject a drifting CA before it became the next DigiNotar, instead of after. On balance I’ll take the version where trust gets pulled for missing deadlines over the version where we wait for the keys to leak.
If you run infrastructure, the takeaway is smaller and more practical: your certificate authority is a dependency whose real risk isn’t that it gets hacked. It’s that it stops being trusted while you’re not looking. The certificate on your server can be cryptographically perfect and still turn into a browser warning overnight, not because anything about your setup changed, but because the organization that vouched for it lost the room. Certificate lifetimes are shrinking toward weeks, automated issuance is the norm, and the CA underneath it all is one you should be able to swap without a fire drill. Entrust is the reminder of why that portability matters — and of the least dramatic, most modern way for a trusted institution to die: not with a break-in, but with a backlog.