SMALLPEARL
Blog

The eMudhra Certificate Compromise Incident

· 6 min read

In October 2026, researchers found that the private keys of eight eMudhra intermediate certificate authorities could be recovered in under a second. Anyone holding those keys could issue a certificate for any domain, such as your bank, Google Drive or your own API, and many systems would accept it as genuine.

Critical software such as browsers and operating systems released patches within days. However, the problem extends to many other applications too, and protecting those requires action from their vendors and from the people who run them. This post takes a layman's look at the incident and its impact.

What are certificates?

In general terms, a certificate is a digital ID that confirms the identity of a person or a computer. Think of it like a passport: it's only worth something because a trusted authority issued it and stamped it.

For instance, when you contact google.com in your browser, how do you know that the server that returns you the data is really owned by Google, and not an impostor pretending to be Google? Google's server presents a certificate stamped by a trusted certificate authority (CA). A certificate authority here is like the government department that issues the passport.

The server also proves it holds a secret key, the private key, that only the real owner has. Your browser checks both. If either check fails, you see a warning.

This system works only as long as the authorities' stamps can't be forged, which is exactly what went wrong in the eMudhra case.

The certificate chain and how it works

CAs don't sign website certificates directly with their most valuable key. Trust is delegated through a chain of three levels:

  1. Root certificate. The CA's top-level certificate. It ships preinstalled in your computer's trust store, a folder or a protected database, for example /etc/ssl/certs on Ubuntu. Its private key is kept offline.
  2. Intermediate certificate. Signed by the root's private key. The intermediate's own key does the day-to-day signing.
  3. Leaf certificate. The website's own certificate, containing its domain name and signed by an intermediate's private key.

Your machine stores only the roots. While establishing a secure connection to a remote server (the TLS handshake), the server sends its leaf certificate and the intermediate that signed it. Your machine checks each signature up the chain: the leaf against the intermediate's public key, and the intermediate against the root's public key. If the chain ends at a root in the trust store, the connection is trusted.

One more detail matters for this incident: cross-signing. A CA can have its root signed by an older, more widely deployed root, so that devices which only know the older root still accept its certificates. This creates a second path to trust. Cross-signing helps compatibility, but in an incident it is one more path that has to be cut.

The eMudhra issue

eMudhra is an Indian certificate authority that sells certificates to anyone who buys them.

Every certificate comes with a private key, and a private key is essentially a randomly chosen number. The public key, which is published in the certificate, is calculated from that number. Going forward, from private to public, is easy. Going backwards is practically impossible, as long as the number was picked at random from a big enough range. For the type of key eMudhra used (called P-384), that range goes up to roughly 2³⁸⁴, a number with about 115 digits.

The only way to crack such a key is brute force: guess a number, calculate its public key, and compare it with the published one. If it matches, you've found the private key. With a range that large, this would take an unimaginable amount of time and computing power.

In eMudhra's case, the private keys of 8 of their intermediate certificates were numbers below 256. To crack them, someone only had to try the numbers 1 to 255, calculate the public key for each, and see which one matched. That takes a fraction of a second.

Real-world impact

With a recovered intermediate private key, an attacker can issue a valid-looking certificate for any domain. The real site does not need any connection to eMudhra, because the check happens only on the client. Combined with a position on the network path, such as public Wi-Fi, a compromised router or DNS hijacking, this allows a classic man-in-the-middle attack:

  • Intercept logins, OAuth tokens and API keys in transit
  • Read or alter data, such as files synced to cloud storage
  • Feed fake responses or, where updates rely only on the secure connection, fake software updates

The client sees a valid certificate and a working connection, so nothing looks wrong. It sends its data to the attacker's server, which can quietly pass everything on to the real destination so that the user notices nothing, while it collects what it wants.

This is the most dangerous situation: everything works as expected while data leaks to an attacker. That data could be your online banking session token, which the attacker can then use to masquerade as you and do anything you're authorised to do.

What's the patch?

The first step is to remove eMudhra's root certificate, emSign ECC Root CA - G3, from trust stores. Without it, your machine can no longer verify the compromised intermediates, so any chain through them is rejected, including a forged certificate made with a recovered key. This is deliberately broad: legitimate certificates under that root stop working too.

Second, eMudhra's root was also cross-signed by Sectigo's legacy AAA Certificate Services root, which gives the compromised intermediates a second path to trust. Some updates, such as Debian's, remove AAA as well. It is a genuinely legacy root that modern applications rarely need, so removing it should not cause severe disruption. If you run a server whose certificate chain still ends at AAA, configure it to send a chain that ends at Sectigo's current roots instead.

Browsers took a narrower route: they block the eight compromised intermediates by name, which they can do because they push blocklist updates to users continuously.

Note that patching the operating system only protects software that uses the operating system's trust store. Many applications carry their own. Examples are Node.js, Electron apps, Java, and Python applications that use the certifi package. All of these have released patched versions. If your application is built on one of them and connects to third-party services over the internet, you must update it to the patched version. The same goes for Docker images, which each carry their own copy of the trust store: rebuild them, because updating the host doesn't change what's inside.

Finally, firmware is also affected. Many IoT devices have their own built-in secure-connection software and their own list of trusted roots. Some include only the few roots needed for the services they talk to, but others include the full list, especially those that were not carefully optimised. Those need a firmware update, and devices whose list can't be updated stay vulnerable.

Final thoughts

Secure communication relies heavily on one assumption: that the numbers used to generate keys are truly random. If that randomness fails, keys can be reproduced easily with brute force, no matter how strong the mathematics behind them.

So being random, in computing (and in life too), is perhaps the safest choice!

References