What Just Happened With eMudhra — Explained So Anyone Can Understand
On October 17, 2026, a security researcher known only as Wayne discovered something almost unbelievable: eight intermediate certificate authority (CA) keys belonging to the Indian company eMudhra were so weak that one of them was literally the number 4. Others were 56, 66, 115, 155, 156, 230, and 237.
These weren’t stolen in a dramatic hack. They were accidentally created that way during a key-generation ceremony on April 30, 2025 — and then sat publicly available for roughly 17–18 months until someone noticed.
First, a 60-Second Explanation of Why Certificates Matter
When you visit a website and see the padlock and “https://”, your browser is checking a digital certificate. That certificate is basically a digital ID card that says “Yes, this really is the bank / store / email service you think it is, and the connection is encrypted.”
Those certificates are issued by Certificate Authorities (CAs). Think of CAs as the digital equivalent of a government’s passport office. If someone gets the master key that can print passports, they can create fake ones for any person or company.
In this case, eMudhra’s intermediate CAs (the ones that actually issue the everyday website certificates) had private keys that were tiny, easily guessable numbers instead of enormous random numbers.
How Weak Were the Keys, Really?
A proper private key for this type of cryptography (P-384 elliptic curve) is supposed to be a random number with about 384 bits of strength — roughly a 115-digit number. Trying every possibility would take longer than the age of the universe.
eMudhra’s keys were single-byte values (0–255). Researchers, including Scott Helme, recovered all eight of them from the public certificates on a normal laptop in under one second simply by trying every number up to 255 until they found matches.
Wayne proved he had the keys by digitally signing the message “We have a problem here – Wayne” with each of them and reporting it to Mozilla, Google, Apple, and Microsoft on October 17.
What Caused It?
According to eMudhra, during the April 30, 2025 key generation ceremony (performed on hardware security modules), a flaw in a script’s key wrap/unwrap step created a second, weak set of keys alongside the proper strong ones. Staff then used the weak keys by mistake because the labels looked similar.
The company states:
- Its infrastructure was not compromised.
- No data was breached.
- None of the eight weak intermediate CAs ever issued any actual end-user/website certificates.
- Its India-focused Digital Signature Certificate (DSC) and eSign businesses were completely unaffected.
How Fast Did Browsers React?
Very fast.
- October 17: Chrome and Firefox blocked the affected certificates within hours of the report (Chrome via CRLSet, Firefox via OneCRL).
- October 18–19: eMudhra revoked the certificates.
- October 19–20: Apple and Microsoft followed with blocks.
- The associated ECC root was also distrusted by browser programs as a precaution.
For most people using updated Chrome, Firefox, Safari, or Edge, the risk was neutralized almost immediately.
Who Actually Needs to Worry?
Most everyday users: almost nothing.
If your browser is reasonably up to date, it no longer trusts these keys. You don’t need to change passwords or take special action for normal web browsing.
The longer-term risk sits outside browsers.
Linux distributions, servers, IoT devices, embedded systems, programming language trust stores (Python, Java, etc.), and older software that don’t automatically update their list of trusted certificates can remain vulnerable until their administrators push updates. An attacker who could position themselves between you and a site (for example, on a compromised network) could theoretically forge a trusted certificate for any website while those systems still trust the old keys.
Certificate Transparency logs (public records of issued certificates) showed no evidence that the keys were used maliciously before the discovery, which is good news. But not every client checks those logs.
The Bottom Line
This was a serious process failure at a Certificate Authority — the kind of mistake that should be nearly impossible — but it was caught before the weak keys appear to have been used to issue real certificates. The major browsers moved extremely quickly.
It is a useful reminder that the padlock in your browser depends on a chain of trust, and that chain is only as strong as its weakest key-generation ceremony. In this case, one of those keys really was the number 4.
If you run servers, IoT devices, or internal systems that manage their own certificate trust stores, check for updates related to eMudhra / emSign ECC Root CA – G3 and the affected intermediates. For everyone else, keep your browser updated and you’re largely covered.