Flawed Key-Generation Ceremony at Indian Certificate Authority Forces Global Browser Lockdown

Eight certificates that browsers and operating systems around the world trusted to vouch for the authenticity of websites turned out to carry private keys that anyone could simply guess. Mozilla, Google, Apple and Microsoft spent the past several days racing to block the certificates, issued by the Indian certificate authority eMudhra, after a researcher demonstrated on October 17 that the keys were effectively single-digit numbers rather than the astronomically large random values they were supposed to be.

The flaw sits at the foundation of how the web secures connections. Certificate authorities such as eMudhra issue the digital credentials that let a browser confirm it is really talking to, say, a bank's website rather than an impostor. Anyone who obtained one of the compromised keys could have forged a valid-looking certificate for essentially any domain on the internet, though using it to intercept traffic would still have required controlling or eavesdropping on the victim's network connection. In a post from its security team, Mozilla said the keys were "trivial to exploit" and that it moved to protect Firefox users within hours.

Keys that should have taken the age of the universe to guess

According to the timeline Mozilla engineer Dennis Jackson laid out to other browser makers and operating-system vendors, a researcher identified only as Wayne reported the problem to Apple, Google, Microsoft, Mozilla and eMudhra at 18:05 UTC on October 17, attaching signed proof that he controlled the keys. Jackson's advisory, later shared on the oss-security mailing list, said six of the affected intermediate certificates were used to issue ordinary website certificates and two were used for code signing, all trusted through the Mozilla, Chrome, Apple and Microsoft root programs.

The eight certificates were supposed to rely on NIST P-384 elliptic-curve keys, which should be effectively impossible to guess. Instead, independent researcher Scott Helme found the actual private-key values were tiny integers — 4, 56, 66, 115, 155, 156, 230 and 237 — rather than 384-bit random numbers. "I recovered all of them from their public certificates on my laptop just now, and it took less than a second," Helme said. Mozilla independently recovered the same keys on its own within hours of receiving the report, according to the bug Mozilla opened to track the incident in its public Certificate Authority compliance system.

A ceremony from 2025 comes back to bite

Mozilla's bug tracker entry says eMudhra traced the problem to a key-generation ceremony carried out on April 30, 2025, using the company's hardware security modules. The company's own explanation, relayed in the bug report, points to a code error during an approved deviation in that ceremony, which produced a second, much weaker key pair alongside the correctly generated one — with labels similar enough that the weak pair was mistakenly used to sign the certificate requests eventually sent to the commercial certificate authority Sectigo for cross-signing. eMudhra has said the error did not touch its root certificate authority keys or its other, unaffected intermediates, and that its separate Indian digital-signature and e-signing businesses, which run on different infrastructure, were not implicated.

The company has also said the global TLS certificate business affected by the incident accounts for roughly 1 percent of its revenue, a detail eMudhra gave reporters this week as it works to reassure customers and regulators. It has not announced any change to that business beyond reissuing certificates for affected customers, according to reporting by the Daily Pioneer and by Biometric Update, which covers the digital-identity industry.

The episode is not eMudhra's first brush with certificate-handling trouble this year. Mozilla's bug tracker references an earlier, related bug from 2025 involving invalid signatures on certificate revocation lists tied to the same intermediates — a thread that, in hindsight, suggests the flawed key pair had already been quietly signing revocation data for months before anyone noticed.

Browsers moved in hours, but cleanup will take longer

The response from browser makers was fast by the standards of internet infrastructure. Google's Chrome Root Program pushed a CRLSet update blocking the six affected website-issuing certificates at 19:45 UTC on October 17, roughly 100 minutes after the report arrived. Mozilla finished distributing its own block through Firefox's OneCRL revocation system by 22:59 UTC that same day, reaching essentially all standard Firefox installations without requiring a restart or update. eMudhra itself revoked all eight certificates on October 18, and Sectigo revoked its cross-signed versions on October 19. Apple blocked the certificates in its own root program on October 19, and Microsoft followed on October 20.

Mozilla and Chrome went further than ordinary certificate revocation, moving to withdraw trust entirely from one of the roots involved, emSign ECC Root CA – G3, given the severity of the failure. That decision forces a broader cleanup: by Mozilla's own count, cited in its bug tracker, roughly 30,000 TLS certificates chaining through that root now need to be reissued through other means, the large majority of them through the automated ACME protocol that many hosting providers and content delivery networks use to renew certificates without manual intervention.

Software that does not promptly check whether a certificate has been revoked is the main remaining exposure. The Go programming language's maintainers shipped new releases on October 19 rejecting certificate chains built on the affected keys, while Mozilla's own fix to how Firefox handles its certificate block list is logged in the U.S. National Vulnerability Database as CVE-2026-113470 and was resolved in Firefox 158.0.1 and related releases. Cloudflare, which said it learned of the compromise on October 19, pushed updated versions of its 1.1.1.1 resolver apps, its WARP client and Cloudflare Tunnel as a precaution, reporting no sign that its own services had been exploited.

"This will be a massive cleanup job, bigger than Heartbleed," Go cryptography maintainer Filippo Valsorda said of the incident, invoking the 2014 flaw that forced a comparable scramble across the internet's encryption infrastructure.

Who is exposed, and what happens next

Operators of websites and services that used eMudhra or its emSign brand to issue TLS certificates are the most directly affected, and face reissuing certificates regardless of whether their specific certificate touched one of the eight compromised keys, simply because of the broader root-trust changes. Ordinary website visitors using up-to-date, mainstream browsers were protected within hours and do not need to take any action. The greater, longer-tailed risk lies with software that bundles its own list of trusted root certificates and checks revocation status poorly or not at all — a category that includes some programming-language libraries, embedded devices, older mobile apps and enterprise systems that may take weeks or months to receive updates, as documented in the Mozilla bug thread and in coverage from Biometric Update and the trade newsletter LWN.

Mozilla and Google's root-program teams have since posed roughly a dozen formal questions to eMudhra, seeking a fuller account of the April 2025 ceremony, audit records, whether the hardware security modules involved were operating in a FIPS-validated mode, and the company's plans for migrating customers off the distrusted root, according to the public bug thread. eMudhra has not yet publicly answered all of those questions. Certificate Transparency logs, the public record most browsers use to track every certificate a trusted authority issues, show no sign so far that anyone used the weak keys to forge a fraudulent certificate before revocation, though Mozilla's advisory cautioned that an attack targeting software outside the browser ecosystem might not necessarily show up in those logs.

The incident is likely to sharpen scrutiny of eMudhra's standing in the browser root programs that determine which certificate authorities the internet trusts by default, a status that is reviewed periodically and can be revoked. For now, no browser maker has proposed removing eMudhra entirely, and the company continues to operate its other certificate and digital-identity businesses. The full account of how a cryptographic ceremony went wrong in April 2025 and went undetected for nearly eighteen months remains, by Mozilla's own account, still under investigation.