Researcher finds eight weak eMudhra intermediate CA keys belonging to Indian authority as it exits SSL/TLS business

A security researcher found eight easily guessable eMudhra intermediate CA private keys belonging to the Indian certificate authority on Oct. 17, 2026, by scanning publicly available certificate data, and eMudhra’s board decided on Oct. 22, 2026, to exit the global SSL/TLS business.

A critical cryptographic defect during certificate generation compromised eight intermediate CA private keys belonging to Indian certificate authority eMudhra Limited. The defect involved insufficient randomness during key generation. Every one of the eight keys fell below 256, making them trivial to derive almost instantly, and all private keys were zero except the final byte, whose values included 4, 56, 66, 115, 155, 156, 230 or 237. Attackers could derive private keys, issue unauthorized public TLS certificates, and carry out man-in-the-middle interception or session hijacking.

On Oct. 17, 2026, the researcher notified Apple, Google, Microsoft, Mozilla and eMudhra about the weak keys. eMudhra revoked the eight compromised intermediate certificates after the disclosure. Six of the eight were website TLS certificates, and the remaining two were code signing certificates trusted by Microsoft.

Leading browser and operating system providers moved to revoke or untrust the compromised intermediate certificate authorities. Google Chrome will cease trusting emSign ECC Root CA – G3, an eMudhra root, starting the morning of Oct. 27, 2026, Pacific time. On Oct. 20, 2026, Mozilla chose to stop trusting that root within Firefox, and Apple introduced protections on Oct. 22, 2026. Firefox’s OneCRL system blocked the compromised certificates on Oct. 17, 2026, so users needed no browser update or restart, and Google Chrome blocked the six compromised TLS-intermediate certificates the same day.

Chrome counted about 30,800 unexpired certificates tied to that root in public Certificate Transparency logs as of Oct. 21, 2026. InCommon, the certificate service Internet2 created for higher education, issued 99.9% of those certificates. Between April and July 2026, InCommon migrated the service to eMudhra’s CertiNext platform. About 30,000 certificates require migration, and eMudhra estimates that roughly 97% were issued using ACME, the automated protocol servers use to request and renew certificates.

eMudhra’s board decided to withdraw from the global SSL/TLS certificate business on Oct. 22, 2026. The company said roughly one percent of its revenue comes from its global SSL/TLS certificate business, that affected customer certificates will be replaced with free ones from unnamed partners, and that no exit date was provided. eMudhra said none of the eight were used to issue certificates to websites or users, that no breach occurred, and that most affected intermediate certificates saw no production use. Other eMudhra businesses, including digital signature certificates, eSign and CertiNext, will continue, and revocation and status services will remain operational until all SSL/TLS certificates expire or are replaced.

Security agencies have found no evidence that the weak keys were maliciously exploited to issue fraudulent certificates, and there is no confirmed abuse of the compromised keys to date. eMudhra ceased issuing new certificates under the G3 root following the disclosure.

Google told website operators with certificates under that root they “must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store.” Ordinary ACME clients only replace certificates during their renewal window unless they support renewal information or receive manual intervention. Switching from the ECC hierarchy to the RSA hierarchy might require adjustments to client settings.

Cornell advised certificate holders to request RSA certificates rather than ECC ones, saying RSA certificates rely on eMudhra’s unaffected root and should function, and Cornell reports owning more than 300 affected certificates. The University of Michigan says InCommon’s RSA certificates remain unaffected for now, with Let’s Encrypt as its main alternative. Stanford’s InCommon certificates link to that root via an eMudhra CA named emSign Root TLS CA – G1. Mozilla declined to remove trust in emSign Root CA – G1 on Oct. 20, 2026.

On Oct. 20, 2026, eMudhra described G1 as the only alternative available, and on Oct. 21, 2026, it said affected US customers would receive fresh certificates from a separate, independently operated, publicly trusted CA hierarchy.

Six intermediates received invalid CRLs from eMudhra in 2025, and an eMudhra CRL for emSign Root TLS CA – G1 published Oct. 14, 2026, has an invalid signature; eMudhra said it regenerated them using each Intermediate CA’s appropriate private key. eMudhra told Mozilla on Oct. 19, 2026, that the lists were signed with intended keys, then resigned with weak keys after invalid signatures resulted. Chrome’s Oct. 21, 2026, bug report asked which key signed the CRL and whether eMudhra holds multiple key pairs for that CA or its roots, and by 13:31 UTC on Oct. 22, 2026, eMudhra had not publicly answered Chrome’s bug report questions; its last visible comment dated from Oct. 20, 2026.

Go versions 1.27.3 and 1.26.10 address the issue under CVE-2026-111943, according to the Go development team. Mozilla cryptography engineer Dennis Jackson published an incident tracking website listing affected software and security updates, and he warns that macOS’s built-in /usr/bin/curl utility may keep trusting the compromised certificates because its certificate bundle does not check revocation information. Background revocation blocklists let browsers block the affected intermediate CAs, but most software relying on web PKI cannot filter intermediate CAs. ca-certificates packages for Arch, Debian, Gentoo, Fedora and Ubuntu were updated, as were Electron, Go, pip, Python certifi, rustls-webpki, Rust webpki-roots and uv, and Dart version 3.13, released in August 2026, no longer includes an embedded cacerts file.

Removing the root causes collateral damage for legitimate certificates issued by authorities chained to it. Attackers can use forged certificates to impersonate sites and services in man-in-the-middle attacks, or to authenticate to mTLS endpoints trusting web PKI roots. Certificate forgery bypasses DNS CAA records because no forger performs such a check.