The largest revocation event of the year was not a crypto break — it was a compliance failure wearing one. Primary source: GoDaddy's own incident statement on Mozilla Bugzilla, bug 2083191.
GoDaddy's certificate authorities — primarily Starfield — had a paperwork problem, and that paperwork problem turned into the largest certificate revocation of the year: roughly 404,000 TLS certificates revoked across two weeks in October.
A third party reported that GoDaddy's issuance practices didn't match its published Certification Practice Statement — mismatches in certificate OIDs and CPS URIs across eight certificate hierarchies, the kind of divergence the CA/Browser Forum Baseline Requirements treat as disqualifying: non-compliant certificates must be revoked within five days. Not a key compromise. Not broken math. The certificates negotiated handshakes perfectly the whole time. But if your actual behavior doesn't match the promises in your CPS, you are out of compliance, and the remedy is mass revocation.
The timeline is classic compliance triage: subscriber outreach began October 14, with a revocation deadline of October 18. GoDaddy missed its own deadline with only about 170,000 revoked — which triggered a second incident for non-compliance during the extension window. The job finished October 22: 378,067 revoked, 25,576 already expired, zero remaining.
And while site owners scrambled, phishers rode the wave — cloning the revocation notification emails to catch people who were, for once, primed to act urgently on a certificate email.
Hype vs. reality
The headline everywhere was "mass certificate breakage." Reality: almost nothing hard-crashed on day one — and the reason is structural, not luck. Browsers don't hard-fail on revocation by default: Chrome checks through asynchronously-updated CRLSets and Firefox through CRLite, both of which tolerate revoked certificates until their aggregated lists refresh. Unless something on your network explicitly tests OCSP or CRL endpoints, clients could keep negotiating TLS with "revoked" certificates for days. Revocation on this scale is a deadline-driven operational fire drill, not an instantaneous kill switch — and the smart move was to reissue from a different CA on your own schedule.
The genuinely dangerous part wasn't the revocation at all. It was the phishing wave wearing the revocation's clothes. Users are conditioned to ignore certificate-expiration spam — but a genuine, widely-reported emergency makes the fraudulent mirror lethal. "Verify this notice at our secure portal" catches exactly the people trying to do the right thing.
The deeper reality is the one worth keeping: your TLS did not break because mathematics failed. It broke because a company's documentation didn't match its behavior. Trust infrastructure is only as good as the least honest statement in the compliance chain.
Estate Verdict
Zero GoDaddy certificates here — the house runs its own internal CA for private names and Let's Encrypt on the public edges, which meant this event was a spectator sport. But it stamps in a rule I'd defend for anyone:
If you can't list, from memory, which CAs issued the certificates your money-making endpoints depend on, you don't have a certificate inventory. You have a surprise waiting for a calendar date. And the next time a mass-revocation email arrives: verify it against the CA's own website, typed by hand. The phishers have learned that the most believable urgent email is the one whose real version already exists.