#certificateauthority

Read Time:3 Minute, 47 Second

eMudhra Limited, an Indian digital trust and certificate authority provider, has announced it will exit the global SSL/TLS certificate business entirely. The move follows the discovery that eight of its intermediate certificate authority certificates were issued using private keys weak enough for an outside researcher to recover almost instantly, a flaw that traces back to a key-generation ceremony eMudhra ran more than a year earlier.

A Key Weakness Fifteen Months in the MakingAccording to eMudhra’s own preliminary account, the problem originated in a key-generation ceremony held on April 30, 2025. A flawed script used during a key wrap and unwrap step generated a second, unintended set of weak keys alongside the correct ones. Because the labels on the weak keys resembled those of the legitimate ones, staff later used the wrong keys when generating certificate signing requests for eight intermediate CAs. The affected keys used the P-384 elliptic curve, but instead of the astronomically large random values P-384 is supposed to produce, the private key values came out under 256, making them trivial to reconstruct from the corresponding public key.

India’s national CERT, CERT-In, was explicit that the flaw sat in how the keys were generated, not in any weakness of the P-384 algorithm itself. Of the eight compromised intermediates, six supported general TLS certificate issuance and two were used for code signing. eMudhra has said none of the affected intermediates directly issued end-entity certificates, the kind that websites and applications actually present to browsers, which somewhat limits the blast radius.

From Discovery to Revocation in HoursThe weakness came to light on October 17, 2026, when a researcher using the handle Wayne demonstrated proof of control over all eight private keys. Mozilla independently reproduced the key recovery, confirming the generation flaw was real and exploitable. Google and Mozilla moved the same day to block the affected TLS keys and began the process of removing trust in the emSign ECC Root CA – G3 to protect browsers and clients that don’t reliably check intermediate certificate revocation status in real time.

eMudhra Chairman V. Srinivasan said the company revoked the affected certificates within 14 hours of the disclosure. CERT-In subsequently stated that, as of its October 21 update, public evidence had not confirmed any actual malicious exploitation of the weak keys, though the window during which a sophisticated attacker could have forged certificates was real regardless of whether anyone is known to have used it.

Why Exit the Business Entirely?eMudhra’s decision to abandon global SSL/TLS issuance rather than simply remediate the incident reflects as much business calculation as security concern. The company says the global certificate segment accounts for roughly 1% of its total revenue, a figure dwarfed by the compliance overhead, data-sovereignty requirements, and intensifying price competition from free certificate authorities that have steadily eroded margins in commercial TLS issuance for years. Srinivasan also pushed back on what he characterized as social media criticism disproportionate to the size of the affected business line, while acknowledging the incident raised legitimate questions about the company’s certificate issuance controls.

The Migration AheadeMudhra estimates approximately 30,000 certificates, separate from the eight compromised intermediates themselves, will need to migrate away from its global SSL/TLS infrastructure as part of the wind-down. The company says it will keep its G1 RSA root certificates operating to serve existing customers during the transition, offer replacement certificates through partners at no additional cost, and maintain revocation and status-checking services until all affected certificates either expire naturally or are replaced.

CERT-In’s advisory, tracked as CIAD-2026-0050, urges administrators not to assume the issue is confined to web browsers. It specifically recommends reviewing certificate bundles embedded in applications, containers, and network appliances, locations where an expired trust relationship can quietly break functionality long after browsers have already adjusted. Chrome’s root-store change affecting the emSign root is expected to reach most devices by October 27, 2026.

What Organizations Relying on eMudhra Certificates Should DoInventory every system, application, container, and network device that references an eMudhra-issued or emSign-rooted certificate, not just public-facing websites.

Replace certificates proactively through eMudhra’s partner migration path rather than waiting for a browser trust change to break production services.

Update browsers and trust stores on managed devices to ensure the upcoming root-store changes are reflected promptly.

Treat this as a reminder to track certificate issuer concentration risk across your infrastructure, since a single CA’s operational failure can cascade into unplanned migration work.

Read Time:3 Minute, 40 Second

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 wrongAccording 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 falloutThe 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 worseIndustry 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 doFor 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 patternThis 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.

Read Time:3 Minute, 12 Second

Browser makers and software maintainers are rapidly withdrawing trust from eight eMudhra intermediate certificate-authority certificates after a researcher demonstrated control of their private signing keys. Because the intermediates connect to roots accepted by major platforms, clients that still trust the affected chains could potentially accept fraudulent certificates as genuine.

The researcher, identified publicly as Wayne, reported the issue to certificate root programs on October 17, 2026. To prove possession without publishing the secrets themselves, the researcher signed a short message with each compromised private key. The corresponding certificates, public keys and signatures were released so independent reviewers could verify the result with standard cryptographic tools.

Why an intermediate CA key mattersA website certificate is usually trusted through a chain: the site certificate is signed by an intermediate authority, which ultimately links to a root embedded in a browser, operating system or application. Possession of an intermediate’s private key may allow an attacker to issue new certificates that vulnerable clients accept under that chain.

That capability does not automatically place an attacker inside a user’s network. But when combined with the ability to intercept or redirect traffic, a forged certificate could support convincing website impersonation and potentially allow encrypted traffic to be read or modified. This is why certificate-authority incidents demand ecosystem-wide action rather than a fix on a single web server.

The public evidence confirms signing capability, not the cause of the exposure. It does not establish that the keys were recovered through a rapid cryptographic break, despite claims circulating online, and it does not prove that forged certificates were used against end users. How the keys became accessible remains publicly unresolved.

Browsers moved quickly to block the chainsMozilla received the report at 20:06 UTC on October 17 and completed a OneCRL blocklist rollout less than three hours later. Standard Firefox configurations could receive that protection without a conventional browser upgrade or restart. Chrome reportedly blocked the certificates the same day, Apple followed on October 19, and Microsoft deployed protection on October 20. eMudhra has revoked the affected intermediates as well.

Mozilla also shipped Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for environments where settings might prevent OneCRL delivery. NSS 3.131.1 removes the associated signing root from the trust list used by other software. Additional fixed trust bundles include Go 1.27.3 and 1.26.10, Python certifi 2026.10.19, and Rust webpki-roots 1.0.10. Updates for some other ecosystems were still pending when the incident response information was reviewed.

Application trust stores are the long tailCertificate revocation alone is not universal protection. Some programs do not check revocation status reliably, cannot receive browser-maintained blocklists, or ship a private copy of trusted roots. A fully updated browser may reject the affected chain while a command-line client, container image, embedded device or older application continues to accept it.

Update browsers and operating systems across managed endpoints.

Inventory runtimes, containers and applications that bundle their own CA files.

Upgrade language-specific trust packages and rebuild images that pin older bundles.

Use the public incident test chains to check important clients for rejection.

Escalate any unexpected acceptance or suspicious certificate observations to the security team.

Manual removal of roots should be reserved for experienced administrators because trust-store changes can break legitimate connections. Where vendors have published supported releases, those updates provide a safer and more auditable remedy.

The incident illustrates a recurring weakness in public-key infrastructure: emergency browser controls can protect mainstream users quickly, while fragmented software dependencies take longer to converge. Organizations need an inventory of certificate bundles just as they need an inventory of vulnerable libraries. Without it, defenders may patch the visible browser fleet and overlook the services that perform sensitive machine-to-machine connections.