An Indian Certificate Authority's Private Keys Were Trivially Guessable, and Browsers Have Revoked Them
One key was the number 4. Eight eMudhra intermediate certificates could have been forged for any site until Mozilla, Google and Apple blocked them. Some software is still exposed.
Outspoken Digest Technology Desk
Wednesday, October 21, 2026/2 min read
Every padlock in a browser rests on a promise that a certificate authority guards its secret keys. This week, a researcher showed that one such secret, held by India's eMudhra, was the number 4.
Eight eMudhra intermediate certificates used private keys so weak that anyone could recover them in moments, BleepingComputer reported. Mozilla, Google and Apple have now blocked them, but the cleanup is not finished.
What went wrong with the eMudhra keys?
Mozilla's incident report says all eight certificates used P-384 keys generated in April 2025 with values below 256. A proper key of that kind is a random number of about 384 bits, so an attacker needing only to try 256 possibilities is a total failure. The Register reports that security researcher Scott Helme recovered keys including 4, 56 and 115 from public certificates in under a second.
eMudhra blames an error in a script used to generate the keys, which produced a second, weaker set that was mistakenly chosen for signing because its labels resembled the good set. The company says most of the affected intermediates were never used in production and that it found no evidence of misuse. BleepingComputer notes that an attacker could have recovered the keys at any point since April 2025.
Why is a weak certificate key dangerous?
With a recovered key, an attacker could forge a certificate for a site they do not control, and browsers would trust it. The Register quotes Cloudflare warning that this would allow impersonation and interception or alteration of traffic. The Register says eMudhra claims more than 60 million issued certificates, and had not answered its questions by publication.
Who has blocked the certificates?
A community member reported the problem to Mozilla on Saturday 17 October, the Register says. Mozilla revoked the certificates through its OneCRL system that day, and Chrome blocked six TLS-capable intermediates the same day. Apple added protection on 19 October. On 20 October Mozilla shipped Firefox 158.0.1 and ESR updates for configurations that missed the earlier revocation, and Go released versions 1.27.3 and 1.26.10, tracked as CVE-2026-111943.
What is still exposed?
Software that keeps its own certificate store or does not check revocation may still trust the bad certificates. Mozilla cryptography engineer Dennis Jackson warned that the macOS built-in curl may do so. At publication, patches were still pending for Debian ca-certificates, FreeBSD ca_root_nss, Node.js and Bun, while Ubuntu, Arch, Alpine, Python certifi and Electron had fixed it, BleepingComputer says.
Administrators should update their systems and use the published test endpoints to check what still trusts eMudhra. The broader question, why a root-trusted authority could ship such keys for a year and a half, remains for the browsers' root programmes to answer.
Published in The Outspoken Digest
Editorial desk
Outspoken Digest Technology DeskSoftware, hardware, artificial intelligence and what they change for everyone else.
Newsletter
The Digest, in your inbox
One edition, sent when it is ready. No noise, and your address is never passed on.
Read Next
More Technology →
What PHP2Shell Reveals About Maintaining the Code Behind Most of the Web
Oct 22, 2026/3 min read
PHP2Shell for Hosts, Developers and Security Teams: Backports, WAF Rules and Incident Response
Oct 22, 2026/3 min read
PHP2Shell: What Website Owners and Small Businesses Should Do Right Now
Oct 22, 2026/3 min read
PHP2Shell Timeline: From a Quiet August Report to a Leak, Early Attacks and a Day-Early Patch
Oct 22, 2026/3 min read