GoDaddy has carried out one of the largest certificate revocation events of the year, pulling more than 404,000 SSL/TLS certificates after discovering that a batch of issued certificates did not line up with its own published certificate policies. The cleanup touched both the GoDaddy and Starfield certificate chains and came with an added complication: the company missed the strict deadline certificate authorities are required to meet when fixing this kind of error.

What went wrong

According to GoDaddy’s incident disclosure, an outside researcher flagged inconsistencies between certificates the company had issued and the profiles described in Starfield’s Certificate Policy and Certification Practice Statement (CP/CPS) — the rulebook a certificate authority is supposed to follow every time it issues a certificate. The mismatches centered on policy object identifiers (OIDs) and CPS URI qualifiers, metadata fields that tell browsers and other software which issuance rules a certificate was supposed to follow.

Crucially, GoDaddy has characterized this as a paperwork and process failure rather than evidence that private keys were stolen or that certificates were issued to the wrong parties. Once the report was confirmed, GoDaddy paused new certificate issuance, corrected its documentation, and then resumed operations — but a subsequent audit turned up similar inconsistencies in the older, retired Starfield G2 chain as well.

The scale of the fallout

The overwhelming majority of the affected certificates were domain-validated (DV) — the most common and least rigorously vetted certificate type. Breaking down the numbers:

• Starfield R1 DV certificates: 208,896 affected
• Starfield G2 DV certificates: 187,159 affected
• A smaller remainder spread across organization-validated and extended-validation certificates in both chains

That puts the total above 404,000 certificates needing replacement — a population large enough to include certificates protecting government portals, financial institutions, and healthcare organizations, according to GoDaddy’s own outreach records.

A missed deadline made things worse

Industry rules under the CA/Browser Forum’s TLS Baseline Requirements (Section 4.9.1.1) require a certificate authority to revoke a non-compliant certificate within 24 hours, with an absolute outer limit of five days, using the “superseded” revocation reason. GoDaddy began notifying affected customers on October 14 through email, SMS, and phone calls, but by the time the five-day window closed at 23:45 UTC on October 18, only 170,566 certificates — well under half — had actually been revoked.

The company continued working through the backlog, reaching 227,422 revocations by the early hours of October 19, and says it finished revoking the remaining non-compliant certificates on October 21. Missing the original deadline effectively created a second compliance problem on top of the first, since late revocation is itself a violation of baseline requirements that root certificate programs (run by Google, Apple, Microsoft, and Mozilla) take seriously.

What site owners need to do

For administrators whose certificates were swept into this revocation, the practical risk is straightforward: a revoked certificate that is still being served by a web server will eventually trigger browser security warnings, and in some cases block access outright once revocation checks catch up across different browsers and operating systems. GoDaddy has pushed replacement certificates to affected accounts, but the company explicitly warns that having a new certificate sitting in an account is not the same as having it installed and live on the server.

Site owners should check the SSL certificate section of their GoDaddy account, confirm whether they received a replacement notice, and verify — ideally by inspecting the certificate actually being served on their domain, not just the dashboard — that the new certificate is the one in production.

Part of a pattern

This is not the first time a major certificate authority has had to scramble through a mass revocation tied to a compliance gap rather than a confirmed key compromise; DigiCert went through a comparable episode following a domain-validation error. Episodes like this tend to reignite debate within the CA/Browser Forum over shortening certificate lifetimes and tightening automated validation, on the theory that shorter-lived certificates reduce the blast radius whenever an issuance error like this one surfaces.

For now, the practical takeaway for IT teams is less about the specific OID mismatch and more about certificate hygiene in general: know which certificate authority issued your certificates, monitor for revocation and expiry notices across all of your domains, and treat “replacement available” messages from any CA as something to act on immediately rather than file away.