CA Mis-Issuance and Mass Revocation
A certificate authority can fail its subscribers without losing a single key. Mis-issuance — certificates issued in a form that does not conform to the CA’s own Certificate Policy / Certification Practice Statement (CP/CPS) — is a compliance failure rather than a compromise, but the remedy machinery is the same: revoke at scale, on a clock. The CA/Browser Forum Baseline Requirements, §4.9.1.1, give the timeline once a CA learns a certificate “was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement”: SHOULD revoke within 24 hours, MUST within 5 days, with CRLReason #4 (“superseded”). The GoDaddy/Starfield incident of October 2026 is the largest worked example to date, and it missed that deadline. 1
The GoDaddy/Starfield incident (October 2026)
A third party reported that certificates under the GoDaddy and Starfield TLS hierarchies carried Certificate Policy information — CA-specific policy OIDs and CPS URI qualifiers — that did not match the subscriber certificate profiles documented in Starfield’s CP/CPS (§§10.4.4–10.4.10). No keys were stolen; the certificates themselves were wrong. GoDaddy confirmed the report, halted all issuance, found further discrepancies in its own review (including the dormant Starfield G2 chain), corrected and republished the CP/CPS, and resumed issuance. 2
The affected population — 404,607 certificates initially, later corrected to 403,643 — was overwhelmingly domain-validated:
| Certificate population | Affected |
|---|---|
| Starfield R1 DV | 208,896 |
| Starfield G2 DV | 187,159 |
| GoDaddy R1 OV | 4,041 |
| Starfield G2 OV | 2,134 |
| GoDaddy R1 EV | 1,141 |
| Starfield R1 OV | 928 |
| Starfield G2 EV | 199 |
| Starfield R1 EV | 109 |
| Total (initial) | 404,607 |
Revocation against the clock
GoDaddy activated its Mass Revocation Plan and began engaging subscribers on October 14, prioritizing holders of large certificate inventories and government, financial, and health service providers. The BR 4.9.1.1 deadline for this incident fell on October 18, 23:45 UTC — and passed with 170,566 certificates revoked. By October 19, 05:29 UTC the count reached 227,422. Revocation of the corrected 403,643 population completed on October 22, 22:50 UTC: 378,067 revoked, 25,576 expired on their own, zero still-valid certificates remaining. The delay is itself a reported compliance incident — filed as a separate bug on October 16 under the same BR section. 4
The gap between “revocation is a CRL entry” and “revocation is finished” is operational: each affected subscriber has to be reached, reissue, and install the replacement before the old certificate can be retired without breaking their service. Email, SMS, and voice-call outreach across ~400K certificates is the actual work — which is why revocation deadlines at this scale are measured in days even when the CA is acting in good faith.
How this differs from key compromise
ca-key-compromise-response covers the case where the keys escape — eMudhra’s factorable intermediates, where the remedy was hash-targeted distrust (CRLSet/OneCRL) and root removal because revocation alone could not bound the attacker. Mis-issuance is the opposite posture: the CA controls its own issuance systems, the defective certificates are a known, finite set, and revocation under BR 4.9.1.1 is the whole remedy. Both cases stress the same weak joint — revocation checking that clients perform unreliably — but only one needed browser-level distrust to stop an ongoing threat.
Related
- ca-key-compromise-response — the key-compromise sibling: same revocation machinery, distrust layered on top
- certificate-path-building — where revoked and expired certificates stop building paths
- weak-entropy-key-generation — a third way certificates fail their subscribers, at generation time
Sources
- 2026 — GoDaddy: Subscriber Certificate Profiles Did Not Conform to CP/CPS
- 2026 — GoDaddy: Delayed Certificate Revocation