Weak Private Keys Compromise Indian TLS Certificates

“Maybe some horribly dangerous key generation interface has a ‘size’ parameter and they set it to 1 by mistake???” Valdorda said.

eMudhra Limited: eight TLS certificates with laughably weak keys

The Indian certificate authority eMudhra Limited issued eight Transport Layer Security (TLS) certificates whose private keys were dramatically defective, the reporting shows. The certificates’ private key sizes were listed as 4, 56, 66, 115, 155, 156, 230, and 237. The episode has prompted incredulous reaction from engineers and researchers studying the incident, with one observer calling the result “extremely in the ‘this should not be possible’ category.” eMudhra representatives weren’t immediately available to answer questions, the record notes.

NIST P‑384 expectations versus the compromise

For context provided in the report, a normal NIST P‑384 elliptic curve private key contains roughly 384 bits of entropy — a size allowing almost 2384, described in the source as “a number with 116 digits,” different possibilities. By contrast, the compromised eMudhra private-key sizes were far smaller — the smallest listed as 4 bits — a deficiency that observers called “bonkers” and “astonishing.” Ben Cartwright‑Cox, director of BGP.tools, commented: “My guess is that it’s example code that accidentally leaked to production, but hard to know. But it’s bonkers that no one noticed.”

How an attacker could exploit these certificates

The source stresses that exploiting compromised certificates requires an active adversary-in-the-middle (MitM) operation: the attacker must position themselves as a proxy between two TLS endpoints, receive encrypted traffic, decrypt it using the compromised key, reencrypt it, and forward it. That capability is sometimes limited to “the most well-resourced attackers,” the reporting says. Yet the source also warns that people who control a local network — at a coffee shop, a university, or other organization — “face much less of a challenge.”

Immediate risk: VPNs and non-browser TLS clients

At this early stage, the most immediate threat appears to be for users relying on VPNs, particularly in countries where governments are likely to maliciously intercept traffic. The reporting advises that end users largely have no recourse other than to “hold off using many non-browser forms of TLS communication until they receive assurances updates are in place.” Browsers benefit from extra protections and active ecosystem monitoring, but many VPNs and other TLS-using applications lack those safeguards.

Transparency logs, cleanup, and broader consequences

Transparency logs are credited in the report with revealing much of the failure; however, that mechanism is reactive and “requires parties to actively monitor massive feeds” and functions only after unauthorized certificates have already been issued. The source warns that cleanup “is going to be another mess”—and notes that the timing is awkward because it sits “right on top of the PHP vulnerabilities” also being handled at the moment. Those two remediation efforts together are presented as a compounding operational burden.

What this means for technologists, end users, and adversaries

• Technologists and security teams: Expect to scrutinize certificate issuance records and transparency logs and to prioritize updates for non-browser TLS clients, particularly VPN configurations. The anomaly in basic key-generation entropy suggests a need to audit key-generation tooling and deployment pipelines.
• End users and affected enterprises: The source recommends holding off on many non-browser TLS communications until vendors or certificate authorities provide explicit assurances that keys have been regenerated and replacements deployed. Users on local networks — coffee shops, universities, shared Wi‑Fi — should be aware that those environments reduce the barrier for MitM exploitation.
• Adversaries and threat actors: The report indicates that well-resourced actors are the ones most likely to exploit such certificates at scale, but local-network actors also face “much less of a challenge,” effectively widening the pool of potential exploiters beyond nation-state capabilities alone.

The episode underscores a blunt fact repeated in the reporting: the TLS certificate regime is “only as strong as its weakest link,” and in this case, a single certificate authority’s failures produced keys so small that engineers called them unimaginable. With eight compromised certificates, limited remediation options for many users, and cleanup described as “another mess,” the near-term worklist is concrete — identify affected keys, revoke and replace them, and verify key-generation tooling — even as the broader system once again finds itself exposed by a single technical failure.

Original story