CA Private Key Was Just '4': How eMudhra's Script Bug Broke Global HTTPS Trust

When the Foundation of Trust Cracks

In the internet world, the HTTPS green lock is our primary source of security. All that trust rests on digital certificates issued by Certificate Authorities (CAs). As technology evolves, certificate lifetimes are shrinking — Let's Encrypt certificates will be shortened to 64 days starting February 10 next year. Yet while the industry prepares for a post-quantum future, eMudhra dropped a nuclear self-destruct.

On October 17, 2026, a security researcher uncovered a staggering fact: India's largest digital trust provider, eMudhra, had 8 intermediate CA certificates whose private keys could be trivially recovered by anyone. Worse, multiple keys turned out to be mere integers — 4, 56, 115 — meaning anyone with basic coding skills could compute them in under a second and issue browser-trusted forged certificates for any site.

Why '4'?

To grasp the absurdity, we need a cryptography primer. In elliptic-curve cryptography (ECC), a private key is normally a huge random number. If that randomness is flawed, the key becomes trivial to crack. According to Mozilla's incident report, the 8 compromised keys came from a batch of 24 intermediate certificates eMudhra generated on April 30, 2025. eMudhra later told Mozilla the cause was a bug in the certificate-generation script.

Imagine buying a high-security safe only to find its key cut to the pattern "1-2-3-4". That is exactly what eMudhra did. This extreme negligence instantly destroyed the credibility of over 60 million end-entity certificates chained to those intermediates.

Global Containment

Because eMudhra's root certificates are pre-installed in OS and browser trust stores worldwide, the impact was universal. With the private keys exposed, attackers could launch Man-in-the-Middle (MitM) attacks, intercept and decrypt HTTPS traffic, and spoof login pages for banks or social platforms. Vendors reacted swiftly and uniformly:

Google Chrome & Android: Within hours, blocked the certificates via the CRLSet mechanism; Android devices received updates through Google Play Services.

Mozilla Firefox: Used OneCRL to revoke trust automatically, no user action needed.

Apple & Microsoft: Followed on October 19 and 20, removing trust for the affected roots in their respective trust stores.

Cloudflare: Published a detailed analysis noting that while no maliciously issued certificates had yet appeared in Certificate Transparency (CT) logs, the risk remained extremely high.

Domestic apps including WeChat were also affected. The fallout reached programming language runtimes — PHP, Node.js, Go, Rust, Java, Python, and others — because they rely on the system certificate store. The vulnerability scored above CVSS 9.1.

Is Your Code Safe?

For ordinary users, automatic browser updates mitigate most risk. But for backend developers, ops engineers, and security researchers, the incident is a profound wake-up call:

Trust-store update lag: Applications using custom trust stores or running on legacy embedded devices may not receive CRL/OCSP updates as quickly as mainstream browsers. You must manually verify and remove trust for the eMudhra G3 root.

Language and library impact: Many languages (Java, Python, Go) delegate HTTPS validation to the OS certificate store. If the OS isn't patched, those applications may continue to trust malicious certificates issued with the leaked keys.

Internal service communication: Microservices often use self-signed or private-CA certificates. Although this event primarily hit public CAs, it underscores the need to rigorously audit internal CA key-generation processes and enforce the use of standards-compliant CSPRNGs.

Numerous sites have already been hit; domestic ops teams and developers have been working overtime to patch or shut down affected services, including mini-programs, games, and PHP sites.

eMudhra's Stock Also Crashed

eMudhra stated its infrastructure was not hacked — physical and logical controls remained intact. In other words, this was not a breach but a self-inflicted explosion. The episode sparked fierce debate on technical ethics and responsibility:

Missing automation script audits: In modern DevOps, scripts automate everything. Without strict code review and security testing, a tiny script error can destroy millions of users' trust.

CA admission and oversight: As gatekeepers of the internet trust chain, CAs should face the most stringent audits. This incident exposes massive gaps in key management at some CAs.

Market exit: Reports indicate eMudhra has decided to exit the CA business entirely because major root programs are preparing to evict it completely — a heavy price for a single mistake.

Meanwhile, eMudhra's stock plunged over 20% on the day the news broke.

It's as if a top-tier app company forced every user's password to be "123456" regardless of what they set. The absurdity is staggering.

The fallout even forced Java to release three consecutive patch versions — for each major version, three minor updates were pushed. For example, after the regular quarterly JDK 25.0.5, an emergency JDK 25.0.5.1 appeared, followed quickly by JDK 25.0.5.2 when a more severe issue surfaced.

Conclusion

The eMudhra incident, though seemingly farcical, reminds us once again that

the internet's security edifice is built on countless lines of code and countless details

. Even a simple number like 4, 56, or 115, if placed in the wrong spot, can trigger a tsunami.

In this hyper-connected era, trust is expensive, and maintaining it demands rigor and reverence from every one of us.

The world really is a giant makeshift crew!