The eMudhra CA compromise, explained
In October 2026, eight intermediate certificate authorities operated by India’s eMudhra were found to have derivable private keys. Any one of them could have been used to issue a certificate that your browser would accept for any domain on the internet.
What actually happened
The flaw was in the keys themselves. Eight intermediate certificates were issued with private keys carrying only 3 to 8 bits of entropy, where NIST P-384 requires 384 bits. A key with 8 bits of entropy has 256 possible values. A laptop can enumerate those before the kettle boils.
Once the private key of an intermediate CA is known, the holder can sign new certificates below it — for any domain — and those certificates inherit the trust of the root above. That is the difference between stealing one site’s certificate and being able to impersonate every site.
Timeline
| Date (2026) | What happened |
|---|---|
| 17 Oct | A researcher publishes proof of control — a message signed with the private key of one of the intermediate certificates — to the root program teams. Firefox and Chrome begin blocking the certificates the same day. |
| 18 Oct | eMudhra revokes the eight intermediate certificates. |
| 19 Oct | Apple blocks the affected chain on its platforms. |
| 20 Oct | Microsoft blocks the certificates. A public incident site goes live. Mozilla decides to remove the root. |
| 21 Oct | Chrome counts roughly 30,800 unexpired certificates still chaining to that root, most of them issued through InCommon. |
| 22 Oct | eMudhra announces it is exiting the public SSL/TLS certificate business. |
| 27 Oct | Chrome removes trust in the emSign ECC Root CA – G3 root. |
Why eight intermediates is worse than eight certificates
A website certificate lets someone impersonate that website. An intermediate certificate lets them impersonate anything they can redirect you to. Combined with a position on the network — a malicious Wi-Fi access point, a compromised router, a state-level interception system — it is enough to read an HTTPS session end to end.
That is why the response was so fast and so blunt: the certificates were revoked within a day, and the root was removed from browser trust stores within ten days.
Am I affected?
Almost certainly not directly, and this is where most reporting gets it wrong. To be a victim you needed two things at once: traffic passing through someone who had the key, and a certificate minted from it for the site you were visiting. There is no public evidence that either happened at scale.
What is affected is the assumption. A certificate authority is a single point of trust for the entire web, and this one shipped keys that could be guessed.
What to do now
- Update your phone, computer and browser. The block lists ship with system updates. An unpatched device may still trust the revoked chain.
- Never click through a certificate warning. A warning is exactly what this attack looks like from the user side.
- If you run servers: check whether any of your certificates chain to the emSign ECC Root CA – G3 hierarchy, and replace them with a certificate from another CA. Then update your `ca-certificates` package — the fix version depends on your distribution.
- Watch public Wi-Fi more carefully than usual. The attack needed a network position; untrusted networks are where that is easiest to obtain.
What a VPN does — and does not do — here
This part matters, because VPN vendors are already using this incident to imply that a VPN solves it. It does not, and we would rather say so.
What it does
Melon VPN encrypts your traffic between your device and our servers with AES-256-GCM inside Melon-Link. That encryption does not depend on the public CA system at all. A compromised CA does not weaken the tunnel, and someone sitting on the local network cannot read what passes through it.
What it does not do
- It cannot make a forged certificate genuine. Certificate trust is between your browser and the website. The VPN is not on that path.
- It cannot protect a device that already trusts a malicious root certificate. If someone installed a root on your device, they can intercept the connection before any VPN logic sees it.
- It does not replace updating your software. The fix for this incident is a trust-store update, not a tunnel.
The honest summary: a VPN reduces what a network operator can observe. Certificate authorities are about who a website claims to be. These are two different problems, and treating one as a solution to the other is how people end up feeling safe without being safe.
Sources
- Ars Technica, “The Internet goes on high alert after discovery of 8 compromised TLS certs”, 20 October 2026
- Palo Alto Networks Unit 42, “eMudhra Intermediate CA Certificates Compromised”, 22 October 2026
- Cisco Talos, “Compromised eMudhra intermediate certificates”
- CCADB entries for the eight affected intermediates
- Chrome Root Store removal notice for emSign ECC Root CA – G3, effective 27 October 2026