GoDaddy Revokes 403,643 TLS Certificates: The Starfield CP/CPS Mismatch

GoDaddy revoked 403,643 publicly trusted TLS certificates between 14 and 22 October 2026 because the policy fields in those certificates did not match the profiles in its own Starfield CP/CPS. This was a compliance mis-issuance followed by a delayed revocation, not a key compromise. Any site still serving one of these certificates now fails revocation checks.

No private key leaked. Nobody forged a certificate. The certificates themselves, according to heise security's reading of the incident, carried correct values; the CA's published rulebook described different ones. Under the CA/Browser Forum Baseline Requirements that gap is enough to force revocation within five days, and GoDaddy told Mozilla on 16 October that it would not make that deadline. It finished on 22 October at 22:50 UTC.

This post covers what the two Mozilla Bugzilla reports say, what the public CP/CPS history shows changed, the exact intermediates and fingerprints involved, how to check whether any certificate you run was in scope, how browsers and libraries treat these revocations differently, and what any team can do so that the next mass revocation, from any CA, is a scheduled job instead of an outage.

What happened

A third party told GoDaddy that certificates issued under its GoDaddy and Starfield TLS hierarchies did not conform to the subscriber certificate profiles in the Starfield Technologies Public TLS CP/CPS (Certificate Policy and Certification Practice Statement). The problem sat in the Certificate Policies extension: the CA specific policy OIDs and the CPS URI policy qualifiers. GoDaddy's preliminary report on Bugzilla bug 2082703 says the reporter flagged three profile sections, GoDaddy confirmed the issue, stopped all certificate issuance, found two more mismatched sections itself, corrected and republished the CP/CPS, and resumed issuance.

A further review found the same kind of mismatch in the DV, OV and EV profiles of the older Starfield G2 hierarchy. GoDaddy says that hierarchy has no active issuance, so there was nothing to stop, but its existing certificates were still in scope. GoDaddy then started its Mass Revocation Procedure for all affected certificates, 404,607 at first count.

The Baseline Requirements (section 4.9.1.1, item 12) say a CA "MUST revoke a Certificate within 5 days" once it learns a certificate was not issued in line with its CP or CPS, using CRLReason 4, superseded. GoDaddy filed a second, self reported bug (2083191) on 16 October saying it did not expect to finish by the 18 October 23:45 UTC deadline. It had revoked 170,566 by then. It reported completion on 22 October with a corrected total of 403,643: 378,067 revoked, 25,576 already expired, none left valid.

Not a breach, not a key compromise

It is worth being blunt about this, because headlines about "400,000 revoked certificates" read like a disaster.

• No CA private key was exposed or misused. Neither bug mentions any key, and both are tagged as policy and compliance issues ([ca-compliance], [policy-failure], [dv-misissuance], [ov-misissuance], [ev-misissuance] on 2082703; [ca-compliance], [leaf-revocation-delay] on 2083191).
• No subscriber private key was exposed. Subscribers kept their keys; the CA revoked certificates because of how the CA documented them.
• No domain validation failure has been reported. The issue is in policy identifiers and a URL, not in who was allowed to get a certificate for which name.
• heise security summarised it this way: the certificates have no technical problems, but they do not match their documentation.

The risk to you was availability. If you held one of these certificates and did not replace it before GoDaddy revoked it, clients that check revocation would start refusing your site or API. That is the whole impact, and it is serious enough on its own for anyone whose payment page, login or partner API sat behind one of these certificates.

Timeline

Revocation progress in numbers

The percentages are our arithmetic on GoDaddy's numbers. GoDaddy has not explained why the total fell by 964 certificates between the first count and the corrected one.

Who is affected

Every affected certificate chains to one of three issuing hierarchies. GoDaddy's preliminary report gives this breakdown of the original 404,607:

Grouped by hierarchy, that is 209,933 Starfield R1 certificates, 189,492 Starfield G2 certificates and 5,182 GoDaddy R1 certificates. Domain validated certificates make up about 98 percent of the total. The GoDaddy R1 DV profile (section 10.4.5) is not on the list.

In practice you are likely to be affected if any of these are true:

• You bought a certificate from GoDaddy, or from a hosting brand that resells it, and it was valid in mid October 2026. heise names Host Europe and DomainFactory, both GoDaddy companies, and says GoDaddy had already reissued certificates for all affected customers of those two brands and replaced them automatically where it could.
• A managed hosting plan installed a Starfield certificate for you. Automatic replacement probably covered you, but "probably" is not a check.
• You copied a GoDaddy or Starfield certificate onto infrastructure the hosting provider cannot reach: a load balancer, a CDN, an API gateway, a Kubernetes secret, a Java keystore, an appliance, a mail server, a VPN concentrator or an IoT fleet. These are the copies that break, because nobody replaces them automatically.

Domain owners who never bought a GoDaddy or Starfield certificate are not affected, even if their DNS or registration is at GoDaddy.

How it works

What a CP/CPS is and why a mismatch forces revocation

Every publicly trusted CA publishes a Certificate Policy and a Certification Practice Statement, often combined into one CP/CPS. It is the CA's public promise about how it validates applicants, how it protects keys and, in section 7 and in GoDaddy's case section 10.4, exactly what each certificate it issues will contain. Auditors check the CA against it. Browser root programs hold the CA to it.

The Baseline Requirements treat a certificate that does not match the CA's own CP/CPS the same way they treat one that does not match the Baseline Requirements: as mis-issued. The certificate may be perfectly fine as a piece of cryptography; it was still issued outside the rules the CA promised to follow. The fix for the CA is to correct its process and its documents. The fix for each affected certificate is revocation, with reason code 4 (superseded), within five days.

Mozilla's Root Store Policy section 6.1.3 states that Mozilla "does not grant exceptions to the revocation requirements of the TLS BRs." It also says a CA that expects to miss a deadline must file a separate delayed revocation incident report, and that every delayed revocation incident must appear as a finding in the CA's next audit statement. The CCADB incident reporting guidelines say the same about scoping: a missed revocation deadline gets its own report. That is why there are two bugs.

The Certificate Policies extension

Every publicly trusted TLS certificate carries a Certificate Policies extension. It holds:

1. A CA/Browser Forum reserved policy identifier that says what kind of validation was done: 2.23.140.1.2.1 for DV, 2.23.140.1.2.2 for OV, 2.23.140.1.2.3 for IV and 2.23.140.1.1 for EV. Section 7.1.2.7 of the Baseline Requirements makes these mandatory.
2. Often, a CA specific policy identifier from the CA's own OID arc, which points to the CA's CP/CPS.
3. Optionally, a CPS URI qualifier: a web address where a relying party can read the CP/CPS.

Browsers use the reserved identifier. Almost nothing in the client world reads the CA specific OID or the CPS URI. That is why this incident did not change how any certificate validated. It is also why the error could sit in the document unnoticed.

What the public CP/CPS history shows

GoDaddy publishes its TLS CP/CPS as Markdown in the public godaddy/cp-cps repository on GitHub, and the repository keeps every version. We compared the profile tables in version 6.0 (7 October), version 6.1 (13 October) and version 6.2 (14 October). The changes are small and exact:

In plain words: the Starfield profiles in the document listed the policy OID arc that the GoDaddy branded profiles use (...114413...), while the corrected Starfield profiles use a different arc (...114414...). The Starfield profiles also pointed at a starfield.com repository host, and the corrected text uses starfieldtech.com. The GoDaddy OV and EV profiles pointed their CPS URI at the Starfield host and now point at the GoDaddy one. Version 5.06 from April 2026 already contained the uncorrected values, so the mismatch predates October by months at least. GoDaddy says its full investigation will establish how long the discrepancies existed.

This matches heise's description that the certificates were correct and the CP/CPS was wrong. We did not pull and decode an individual affected leaf certificate, so treat the "certificates carried the corrected values" reading as heise's and the document diff as ours.

The document history in version 6.2 records the fix tersely: version 6.1 "Updated the following sections: 10.4.6, 10.4.7, 10.4.8, 10.4.9, 10.4.10" and version 6.2 updated section 10.4.4. That lines up exactly with the sections named in bug 2082703.

Why revocation ran about four days past the deadline

GoDaddy has not explained the delay in detail yet; heise notes the preliminary reports do not explicitly say why. The bug text points to the shape of it. GoDaddy says it engaged subscribers from 14 October, coordinated with "those with a high number of certificates" and gave priority to "government, financial and health related service providers", and ran dedicated workstreams for outreach, replacement, revocation and tracking, using email, SMS and voice calls. In other words, it tried to get as many replacements installed as possible before pulling the old certificates.

That trade is exactly what the root programs have spent two years pushing back on. Mozilla's policy, in force since 1 September 2025, requires CAs to warn subscribers in advance not to use publicly trusted certificates on systems that cannot tolerate timely revocation, to put cooperation duties into subscriber agreements, and to maintain a tested mass revocation plan under section 5.7.1.2 of the Baseline Requirements. GoDaddy's CP/CPS records that it added mass revocation requirements to its section 5.7.1 in version 5.05 (November 2025), and that section says it tests the plan annually. This incident is that plan running for real, with a CCADB report to follow on how it went.

Technical details

Everything below comes from the two GoDaddy bugs, the GoDaddy CP/CPS on GitHub, or certificates downloaded from crt.sh. Fingerprints and key identifiers were computed from the crt.sh certificates and match the Authority Key Identifiers that the CP/CPS lists for each subscriber profile.

Bugzilla records

Affected issuing CAs

Serials are shown as crt.sh prints them, which can include a leading 00 byte. The intermediates themselves were not revoked; only the subscriber certificates under them were. Nothing here is a reason to distrust these roots or intermediates.

Subject and Authority Key Identifiers

Use these to match a leaf certificate to its issuer without trusting the issuer name string:

Subscriber profile facts from the CP/CPS (version 6.2)

Revocation mechanics

• Reason code. The rule GoDaddy cites requires CRLReason 4, superseded. If you pull a CRL entry for one of your old serials, expect Superseded.
• Where revocations show up. In the issuing CA's CRL, at the URL in each certificate's CRL Distribution Points extension, and in its OCSP responses if the certificate lists an OCSP responder. The CP/CPS profile marks OCSP as present only "if OCSP revocation checking is supported", so do not assume every certificate has one.
• Firefox. Mozilla enabled CRLite for all desktop Firefox users from Firefox 137 and said it would stop OCSP checks for DV certificates in Firefox 142. A blog post tracking eMudhra's revocations notes that CRLite covers every revocation; Firefox refuses certificates revoked in it.
• Chrome. The Chromium project says CRLSets are mainly for emergency blocking and also carry "some number" of non emergency revocations crawled from CRLs, and that Chrome does not generally do online OCSP or CRL checks. The same eMudhra post found none of a batch of 19 October eMudhra revocations in CRLSet version 10856. We have not checked whether GoDaddy's revocations are in a CRLSet, so do not count on Chrome either blocking or allowing a revoked GoDaddy certificate.
• Safari on iOS. That same post reports Safari on iOS only checks OCSP for EV certificates. We could not confirm this from an Apple source.
• Everything else. Server to server clients, Java with revocation checking on, .NET with online revocation mode, Windows applications using the system chain engine, monitoring probes and scanners that read CRLs can all reject a revoked certificate even when Chrome loads the page. A green padlock in Chrome on your laptop proves very little here.

No indicators of compromise

There are none, because there was no compromise. No malicious domains, IP addresses, hashes or user agents are associated with this incident, and none appear in either bug. If someone sends you "IOCs" for the GoDaddy revocation, treat that with suspicion.

What to do now

GoDaddy says nothing affected is still valid, so the job now is to find any copy of a revoked certificate still being served or still stored somewhere it will be served from, and to make the next replacement cheaper.

1. Check what your public endpoints actually serve

# Print issuer, serial, validity and policy OIDs for the certificate a host serves
host=www.example.com
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -issuer -serial -dates -fingerprint -sha256

# OpenSSL 3.x: show the Certificate Policies and AKI directly
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -ext certificatePolicies,authorityKeyIdentifier

# LibreSSL (default on macOS) has no -ext; use -text instead
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -text | grep -A8 -E "Certificate Policies|Authority Key Identifier"

If the issuer is one of the six CAs above and the certificate was issued before GoDaddy corrected its CP/CPS (versions 6.1 and 6.2 are dated 13 and 14 October 2026), check its revocation status next. GoDaddy has not published an exact issuance cutoff, so check anything issued up to 15 October.

2. Check revocation status against the CA's CRL

# Save the leaf, find its CRL URL, and look for its serial
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -outform PEM > leaf.pem
serial=$(openssl x509 -in leaf.pem -noout -serial | cut -d= -f2)
crl_url=$(openssl x509 -in leaf.pem -noout -text \
  | grep -A4 "CRL Distribution Points" | grep -o 'http[^ ]*' | head -1)
curl -s "$crl_url" -o leaf-crl.der
openssl crl -inform DER -in leaf-crl.der -noout -text \
  | grep -i -A3 "$serial"

A match with Superseded as the reason means the certificate was revoked in this event. Some CRLs are partitioned and large; if the grep finds nothing, confirm you fetched the CRL named in that certificate, not a sibling partition.

On Windows, certutil -verify -urlfetch leaf.cer fetches the CRL and any OCSP response and reports the revocation result.

3. Find every certificate issued for your domains

Certificate Transparency logs list every publicly trusted certificate, including ones a contractor or a forgotten hosting plan requested.

# List certificates for a domain from the affected issuers via crt.sh
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | select(.issuer_name | test("Starfield|GoDaddy"))
           | [.id, .serial_number, .not_before, .not_after, .issuer_name, .name_value]
           | @tsv' | sort -u

Every row with a notBefore up to mid October 2026 and a notAfter later than 22 October 2026 is a candidate; most will have been revoked. Match the serials against what your hosts serve.

4. Search the places automation does not reach

# Kubernetes: list TLS secrets and print issuer and serial for each
kubectl get secrets -A --field-selector type=kubernetes.io/tls -o json \
  | jq -r '.items[] | "\(.metadata.namespace)/\(.metadata.name) \(.data["tls.crt"])"' \
  | while read -r name crt; do
      echo "$crt" | base64 -d \
        | openssl x509 -noout -issuer -serial 2>/dev/null \
        | sed "s|^|$name |"
    done | grep -E "Starfield|GoDaddy"

# Java keystores
keytool -list -v -keystore server.jks | grep -E "Owner|Issuer|Serial|Valid"

# Files on disk
grep -rl -- "-----BEGIN CERTIFICATE-----" /etc/ssl /etc/nginx /etc/haproxy 2>/dev/null \
  | xargs -I{} sh -c 'openssl x509 -in {} -noout -issuer -serial 2>/dev/null | sed "s|^|{} |"' \
  | grep -E "Starfield|GoDaddy"

# Windows certificate stores
Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Issuer -match 'Starfield|GoDaddy' } |
  Select-Object Subject, Issuer, SerialNumber, NotBefore, NotAfter, Thumbprint

# AWS Certificate Manager: imported certificates and their issuers
aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn' --output text \
  | tr '\t' '\n' | while read -r arn; do
      aws acm describe-certificate --certificate-arn "$arn" \
        --query 'Certificate.[DomainName,Issuer,Serial,Type,Status,NotAfter]' --output text
    done | grep -E "Starfield|GoDaddy"

Also check CDN and WAF dashboards where you uploaded a custom certificate, appliance admin pages, mail servers (SMTP STARTTLS, IMAP), VPN gateways and any device that took a certificate by manual upload.

5. Replace, then verify from a client that checks revocation

Request a reissue from GoDaddy for anything still on an old serial, install the new certificate and full chain, and test with a client that actually consults revocation data. Firefox, certutil -verify -urlfetch and the CRL check above all do. A quick check in Chrome does not prove the old certificate is gone.

6. Write down what you found

For each affected certificate, record where it lived, who owned it, how you found it and how long replacement took. That list is the beginning of a certificate inventory, and the time it took is your real mass revocation readiness number.

What changed since the first reports

• The count. Bug 2082703 and the first bug 2083191 report said 404,607. The 22 October update gives a corrected total of 403,643. Most news coverage still uses the first figure. The cause of the 964 difference has not been stated.
• The outcome. On 16 October GoDaddy said it did not expect to meet the deadline. On 22 October it reported zero remaining valid certificates.
• The sequence of fixes. The bug says GoDaddy corrected the R1 profiles first and the G2 profile later. The GitHub history agrees: version 6.1 (R1 sections) and then version 6.2 (section 10.4.4) one day apart.
• Who was told when. The delayed revocation bug says outreach began on 14 October. heise says communication with Host Europe and DomainFactory customers began on 16 October. Both can be true for different customer groups; we note the difference rather than resolve it.
• The finish day. Risky Bulletin says revocation finished on Wednesday. GoDaddy's bug gives 22 October 2026 at 22:50 UTC, which was a Thursday. We use GoDaddy's time.
• The framing. Early secondary coverage described "400,000 revoked certificates" without context. The primary record shows a documentation and profile conformance failure, with no key involved.

Open questions

• Root cause and duration. GoDaddy says a full investigation will determine how the CP/CPS, the issuance system configuration and the issued certificates drifted apart, and for how long. The April 2026 CP/CPS already had the uncorrected values. Whether earlier versions did as well is for the full report.
• The third party. The bug does not name the reporter, and we do not guess.
• The 964 certificates. Duplicates, a counting error, or certificates found not to be affected: not yet stated.
• Chrome coverage. Whether Chrome's CRLSet includes these revocations has not been reported for GoDaddy.
• Root program response. Mozilla's policy says delayed revocation incidents must be listed as audit findings. Any further action by root programs is their call and has not been announced.
• Action items. The CCADB guidelines require a delayed revocation report to include action items that reduce future delays. Those will show what GoDaddy changes about subscriber cooperation and automation.

A pattern, not a one off

The same week, eMudhra reported in bug 2082782 that some of its TLS certificates lacked the emSign certificate type policy identifier (1.3.6.1.4.1.50977.1.2.100, .110 or .120) that its own CP/CPS specifies for DV, OV and EV. Also third party reported, also a mismatch between what the CA's document said and what was in the certificates. That is a separate issue from the eMudhra weak key matter covered in our eMudhra explainer.

Two CAs in one week, each caught by an outside reader comparing certificates to the CA's own published profile, tells you where scrutiny is heading. Profile conformance is checkable by anyone with a CT log and a parser. Expect more of these, from more CAs, each with the same five day clock.

For subscribers, the lesson is not about any one CA. Any CA you use can be required to revoke your certificate within five days, sometimes 24 hours, for reasons that have nothing to do with you. The only defence is being able to replace every certificate you own, fast, without a meeting.

What would have helped

Practices any team can use

1. Keep a certificate inventory that includes the copies. One row per certificate per location: hostname, issuer, serial, notAfter, where the private key lives, owner, and how it is renewed. The cert you bought once is often installed in four places, and only one of them gets renewed. Our post on certificate lifecycle inventory, renewal and revocation walks through a working format.
2. Automate issuance and installation with ACME. If a certificate can be replaced by a command or a controller, a five day revocation window is a non event. If it needs a ticket, a purchase order and a change window, five days is short. Use ACME clients or controllers on every endpoint that can run one, and treat manual installs as exceptions with named owners.
3. Use ACME Renewal Information where your CA and client support it. RFC 9773 lets an ACME server tell clients when to renew. A CA facing a mass revocation can use it to ask clients to renew early, which turns a fire drill into ordinary renewals. Check whether your CA and client support it before you need it.
4. Monitor Certificate Transparency for your domains. CT monitoring finds the certificates you did not know about: the marketing microsite, the vendor hosted portal, the old reseller account. See our guide to CT monitoring.
5. Have a second CA ready. Publish CAA records that permit both your primary CA and a backup, keep an account open with the backup, and test issuance from it once a quarter. If your CA is slow, overloaded or distrusted, you can switch without waiting for DNS changes or procurement.
6. Do not pin intermediates or leaf keys. Pinning to a specific intermediate, or shipping a fixed chain file inside an app or device, turns a routine reissue into a release. Pin to nothing, or at most to a set of roots, and let the server send the chain.
7. Keep CA contact details current. GoDaddy contacted subscribers by email, SMS and voice. If the registered contact is an ex employee or an unread mailbox, the warning arrives and nobody reads it. Use a monitored group address and a current on call number on every CA account.
8. Do not put publicly trusted certificates on systems that cannot be changed in days. Mozilla now requires CAs to warn subscribers about exactly this. Devices that take weeks to update, or partners that pin your certificate, should use a private CA you control.
9. Plan for shorter lifetimes. Ballot SC-081 set a falling schedule for maximum certificate validity in the Baseline Requirements: 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, with domain validation reuse falling to 10 days. Teams that automate for 47 days will absorb mass revocations without noticing. Teams that still renew by hand will feel both.
10. Test revocation handling. Find out which of your clients and services check revocation, and how. A staging test with a deliberately revoked certificate tells you which of your systems will fail closed, which will fail open, and which will hang on a network fetch.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. This incident is not a software flaw at all, and CA policy documents and certificate profiles are outside what Zero-Day Discovery examines.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service providing hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses. There is no CVE for this event, so there is nothing to look up in Gold, and no Gold build would have changed whether a GoDaddy certificate was revoked. The habit Gold supports, pulling known good components from a curated source and rebuilding quickly, is the same habit that makes certificate replacement routine: when your images and deployments rebuild in minutes, swapping a mounted certificate does too.

Where Safeguard fits

Safeguard is not a certificate lifecycle manager. It does not inventory TLS certificates, watch CT logs, talk to CAs, renew or rotate certificates, or check revocation status. For this incident, the tools that matter most are your ACME automation, your CT monitor and your inventory.

Where Safeguard can help is with the code and configuration around certificates:

• The Safeguard CLI's assistant edits code and runs commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to search a repository for hardcoded Starfield or GoDaddy chain files, pinned fingerprints or certificate paths, move them to a mounted secret or an ACME issuer, and run the tests, approving each edit and command. safeguard exec runs the same kind of task in CI.
• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image api-gateway:latest, safeguard scan --sbom sbom.json, with JSON results under ./output), plus a platform view of which projects contain a given component and version. That shows you which images ship which TLS libraries and CA bundle packages, which helps when you need to know how a service validates certificates.
• Policies and gates evaluated in the platform, and autonomous remediation that opens fix PRs (off by default), for the vulnerable dependencies you find while you are in those repositories.
• Desktop and phone apps can send work to a computer running the CLI and approve each command, which helps when a CA's revocation notice lands outside working hours.

None of this would have prevented the revocation or replaced a certificate on its own, and we do not claim it would have.

Common mistakes and troubleshooting

• "It works in Chrome, so we are fine." Chrome does not generally do online revocation checks. Test with Firefox, certutil -verify -urlfetch, or the CRL check above.
• Replacing the certificate but not the chain. The new certificate may chain through a different intermediate than the old one. Install the full chain the CA gives you, and do not reuse an old chain file.
• Updating the origin but not the CDN or load balancer. If TLS ends at the edge, the edge serves the certificate. Check what the public hostname returns, not what the origin has on disk.
• Forgetting non web ports. SMTP, IMAP, LDAPS, database TLS, MQTT and VPN endpoints use certificates too. openssl s_client -starttls smtp -connect mail.example.com:25 checks a mail server.
• Grepping a partitioned CRL. Large CAs split CRLs. Fetch the URL listed in the certificate you are checking.
• Trusting the issuer name alone. Match on Authority Key Identifier when it matters; issuer names are similar across GoDaddy and Starfield hierarchies.
• Assuming an expired certificate is harmless. 25,576 certificates expired before revocation. If one is still served, clients reject it anyway, and you need the same replacement.
• Reading this as a security breach. It was not one. Do not rotate private keys or file a breach notice because of this event alone. Replacing the certificate with a new key is good hygiene; it is not required by anything in GoDaddy's reports.
• LibreSSL errors. On macOS, openssl x509 -ext fails with "unknown option". Use -text and grep, or install OpenSSL 3.

FAQ

What happened with GoDaddy's TLS certificates?

GoDaddy revoked 403,643 certificates (corrected from 404,607) issued under its GoDaddy and Starfield TLS hierarchies because the Certificate Policies information in them did not match the profiles in its Starfield CP/CPS. It missed the five day deadline and finished on 22 October 2026 at 22:50 UTC.

Was this a hack or a key compromise?

No. No CA key or subscriber key was compromised, no domain validation failure has been reported, and no attacker was involved. It was a compliance mis-issuance, a mismatch between published policy text and issued certificates, followed by a delayed revocation.

What exactly was wrong?

The CA specific policy OIDs and CPS URI qualifiers. The public CP/CPS history shows the Starfield profiles listing the 2.16.840.1.114413 OID arc and a certificates.starfield.com URL, corrected to 2.16.840.1.114414 and certificates.starfieldtech.com, and the GoDaddy OV and EV profiles switching their CPS URI to certificates.godaddy.com. heise reports the certificates were correct and the document was wrong.

If the certificates were correct, why revoke them?

Because the Baseline Requirements require revocation within five days whenever a certificate was not issued in line with the CA's own CP/CPS. The rule does not ask whether the error was harmless. Root programs enforce it so that a CA's published promises mean something.

How do I know if my certificate was affected?

Check the issuer and serial of what your hosts serve. If the issuer is one of the six CAs listed in the Technical details section, the certificate was issued before GoDaddy corrected its CP/CPS in mid October 2026, and it had not expired by 22 October, it was very likely revoked. Confirm by finding its serial on the CA's CRL with reason Superseded.

Will a revoked certificate break my site?

In Firefox, yes. In Chrome, maybe not, depending on whether the revocation is in a CRLSet. In API clients and services that check CRLs or OCSP, often yes. Replace it regardless; behaviour differs by client and can change without warning.

Did GoDaddy break the rules by missing the deadline?

GoDaddy itself filed a delayed revocation incident, which is how the root programs ask CAs to report a missed deadline. Mozilla's policy says it does not grant exceptions and that delayed revocation incidents must appear as audit findings. What happens next is up to the root programs.

Is this related to the eMudhra incidents?

Not directly. eMudhra filed a similar policy OID conformance bug (2082782) the same week. Its separate weak key issue is a different matter. The common thread is that CAs are being held tightly to their own published profiles.

Should I stop using GoDaddy or Starfield certificates?

That is a business decision we do not make for you. Nothing in this incident suggests the certificates were unsafe. What it does show is that any CA can be forced to revoke on short notice, so the better question is whether you could switch CA in a day if you had to.

What is the structural fix?

Automation and shorter lifetimes. With ACME, a second CA ready through CAA, an inventory and CT monitoring, a mass revocation becomes a batch of early renewals. The SC-081 schedule, reaching 47 day certificates by March 2029, pushes everyone toward that model.

Fix it without waiting for upstream

This incident had no vulnerable package and no upstream patch to wait for, so the section below applies to the dependencies and images in the services that sit behind your certificates, not to the certificates themselves.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows GoDaddy, Starfield or a certificate replacement. Each is a real Safeguard session, and each intro says how the same flow applies to the certificate work above.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this incident, you would open the CLI in the repository that builds your gateway or app image and ask it to find any bundled Starfield or GoDaddy chain files and pinned fingerprints, replace them with a mounted secret path, and run the tests, approving each edit and command as it goes.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick your infrastructure folder, ask for an ACME issuer to replace a manually uploaded certificate in an ingress or load balancer config, and approve or deny each change yourself.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. GoDaddy's outreach went out by email, SMS and voice, often outside working hours; with this flow, the on call engineer who gets that call could approve the redeploy that picks up the new certificate from a phone.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For background, read what a certificate authority is, and for the rest of the month, October 2026 security incidents and what would have helped.

Quick check

Sources

• Mozilla Bugzilla 2082703: GoDaddy: Subscriber Certificate Profiles Did Not Conform to CP/CPS (read via the REST comment endpoint)
• Mozilla Bugzilla 2083191: GoDaddy: Delayed Certificate Revocation (read via the REST comment endpoint and bug metadata)
• Mozilla Bugzilla 2082782: eMudhra emSign TLS certificates missing certificate type policy OID
• GoDaddy certificate repository
• Starfield Technologies Public TLS CP/CPS, version 6.2 (GitHub)
• godaddy/cp-cps commit history for TLS_CPCPS.md
• CA/Browser Forum: TLS Baseline Requirements
• CA/Browser Forum: Ballot SC081v3, schedule of reducing validity and data reuse periods
• Mozilla Root Store Policy (section 6.1.3, Delayed Revocation)
• CCADB Incident Reporting Guidelines
• Mozilla wiki: Responding to an incident
• crt.sh: Starfield TLS Intermediate CA DV R1v1 (ID 21202439413)
• crt.sh: Starfield TLS Intermediate CA OV R1v1 (ID 21135544052)
• crt.sh: Starfield TLS Intermediate CA EV R1v1 (ID 21135544054)
• crt.sh: GoDaddy TLS Intermediate CA OV R1v1 (ID 21135538540)
• crt.sh: GoDaddy TLS Intermediate CA EV R1v1 (ID 21135538539)
• crt.sh: Starfield Secure Certificate Authority G2 (ID 221796)
• The Chromium Projects: CRLSets
• Mozilla Hacks: CRLite in Firefox
• RFC 9773: ACME Renewal Information (ARI) Extension
• heise security: GoDaddy revokes hundreds of thousands of certificates over documentation errors (22 Oct 2026)
• Risky Bulletin, 23 Oct 2026
• captnemo.in: emSign revoked gov.in certificates (23 Oct 2026)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.