eMudhra CA Incident: When the “random” keys were not random

In October 2026 a Certificate Authority called eMudhra got into serious trouble. Researchers found that private keys of eight of its intermediate certificates were so weak that anyone could guess them in seconds. Before we dive into what happened, let’s understand a few basics and then go through the incident.

Topics we will be covering in this post

  • What is a Certificate Authority?
  • Who is eMudhra?
  • What went wrong?
  • Why was it so easy to break?
  • Timeline
  • What should you do?

What is a Certificate Authority?

When you open a website with HTTPS, your browser needs to be sure it is talking to the real site. A Certificate Authority (CA) is the one who vouches for it by issuing a certificate.

Think of a CA like a passport office. The passport office does not need to know you personally, but every country trusts the passport it issues. Same like that, browsers trust a list of CAs, and any certificate signed by them is accepted.

CAs don’t sign everything with their main key (the root). They use intermediate CAs, like authorised officers in the passport office. The root stays locked away and the officers do the daily work.

Who is eMudhra?

eMudhra is a Bengaluru based company, well known in India for digital signature certificates. It was also the first Indian CA to get its root accepted by Mozilla, so its certificates were trusted in browsers across the world.

What went wrong?

The root in question is emSign ECC Root CA - G3. Under it, eMudhra had eight intermediates (six for TLS and two for code signing). The private keys of all eight were weak.

A private key for this type of certificate (P-384) should be a huge random number, around 384 bits. These keys were not. Mozilla’s Dennis Jackson found that all eight keys used numbers less than 256. Basically the key was all zeroes except the last byte.

Why was it so easy to break?

Let’s say your house lock has a 384 digit PIN, which nobody can guess. Now imagine the PIN is 000…000 followed by a number between 1 and 255. You just try all 255. Done.

That is what happened here. The public key is in the certificate for everyone to see. You try the 255 possible private keys one by one and check which one matches. It takes seconds on a normal laptop, no special hardware needed.

With that key you can act as the CA. You can issue a certificate for any website and browsers would trust it. Two of the eight were code signing intermediates, so signing software was also possible.

How did it happen? From eMudhra’s own replies in the bug, the keys came from a key ceremony on April 30, 2025 using Utimaco HSMs. They said a flaw in the code created a second, weaker key pair and that pair was used by mistake to create the CSR. So the issue was there for around 17 months.

Timeline

  • Oct 17: A researcher privately reports the issue to Mozilla, Chrome, Apple, Microsoft and eMudhra. Mozilla confirms and starts distrust the same evening.
  • Oct 18: eMudhra revokes all eight intermediates. The bug becomes public.
  • Oct 19: Sectigo had cross-signed these intermediates, and it revokes its copies.
  • Oct 20: Mozilla announces emergency distrust of the root. Chrome follows.
  • Oct 22: eMudhra announces it is exiting the global TLS business. It will continue with digital signatures.
  • Oct 23: Chrome says this was the “predictable result of eMudhra’s own failure”. Mozilla notes eMudhra missed two response deadlines.

One more interesting point. In June 2025 there was an earlier bug where CRLs were signed with the original keys, gave wrong signatures, and were then re-signed with the flawed keys. That was a hint that something was off, 16 months before anyone caught it.

What should you do?

  • Update your browsers and OS, trust stores are being updated.
  • Check if any certificate you use chains to an eMudhra TLS root. openssl s_client -connect yoursite:443 -showcerts and look at the issuer.
  • If you manage your own trust stores (Java cacerts, container images, CI runners), check them for eMudhra roots. Don’t wait for upstream.
  • Plan a move to another CA if you are using eMudhra for TLS.

Final thoughts

This was not some fancy cryptographic attack. Just a basic check on key generation would have caught it. Good thing is the system worked, researchers found it, public bug trackers made it visible and browsers acted in three days.

Still a lot of questions are open, like how audits missed this. I will update the post when we know more.

0 Shares

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.