Saturday evening, 17 October 2026. Most of the internet was settling into the weekend.
A researcher, identified publicly so far only as Wayne, was doing something very few people do for fun: reading the Common CA Database, the public register where the organisations that vouch for websites list their certificates.
Eight certificates belonging to eMudhra, an Indian certificate company, stood out. A little arithmetic showed that anyone could work out the secret key behind every one of them. No supercomputer. No stolen password. No break-in. Just counting.
Wayne wrote to the browser makers and to eMudhra. Each recovered key came with a short note: “We have a problem here.”
One of those secret keys was the number 4.
First, what is a certificate authority?
Every time you open your bank’s website and see the padlock, your browser is trusting a promise: this site really is who it says it is. That promise comes from a certificate, and certificates are issued by certificate authorities (CAs).
Think of a CA as a notary with a rubber stamp. The stamp is a secret cryptographic key. Anyone can check that a stamp is genuine, but only the holder can make one. Chrome, Firefox, Safari and Edge each carry a short list of notaries they trust, called a root store.
Big CAs don’t use their master stamp every day. They lock the master (the root) away and create deputy stamps, called intermediates, that do the daily work. The eMudhra problem was with eight of these deputies.
Many of us in India know eMudhra from the Digital Signature Certificate (DSC) tokens used for GST, income tax and company filings. It is a licensed certifying authority under India’s Controller of Certifying Authorities (CCA). Separately, it also issued website (TLS) certificates trusted by browsers around the world. This story is about that second business. Keep that distinction in mind; we will come back to it.
A ceremony in a locked room
A CA’s secret keys are not created on someone’s laptop. They are created in a key ceremony: a scripted, witnessed and usually recorded event, where keys are generated inside hardware security modules (HSMs). These are tamper-resistant machines built so that the secret never leaves them.
On 30 April 2025, eMudhra held such a ceremony and created a batch of 24 intermediate certificates, using HSMs certified to FIPS 140-2 Level 3, a respected security standard.
According to eMudhra’s own account, a faulty script in one step of the process (wrapping and unwrapping keys, which is how keys are moved in and out of an HSM in encrypted form) quietly produced a second set of keys next to the good ones. The second set was weak, and its labels looked almost the same as the good set. When the certificates were prepared, the weak keys were the ones picked. In the company’s words, “the weak set is what was published to the browser root stores.” eMudhra has acknowledged human error at several steps and said it is still establishing the full root cause.
In May 2025, Sectigo, another large CA, cross-signed the eight intermediates, so they were trusted through Sectigo’s chain as well. Six of the eight were for website certificates and two were for signing software.
Then, for about 17 months, nothing happened. Or at least, nothing that anyone has reported.
Why a key of “4” is a problem
These certificates use elliptic-curve cryptography. The secret (private) key is meant to be a random number more than 100 digits long. There are so many possible values that guessing is hopeless, even for all the computers on Earth working together.
The public key, which anyone can read from the certificate, is made by combining that secret number with a fixed, publicly known starting point. Going forwards is easy. Going backwards is meant to be practically impossible, as long as the secret is large and random.
eMudhra’s eight secrets were all smaller than 256. One was 4. So nobody needs to reverse anything: you try 1, 2, 3, 4… and compare each result with the public key. Security researcher Scott Helme reported recovering all eight keys in under a second on a laptop. This is the simplest form of a brute-force attack.
That is all the maths we need today. We’ll publish a proper, friendly explainer on elliptic-curve keys on Vajra Blogs soon.
How the internet responded
This is the part of the story worth showing every security student. All times are UTC.
17 Oct, 18:05. Google’s Chrome team receives the report. By 19:45 Chrome has blocked the six website intermediates using CRLSet, its built-in block list.
17 Oct, 20:06 to 22:59. Mozilla receives the report and pushes a block to Firefox through OneCRL. No update or restart needed.
18 Oct. eMudhra revokes all eight intermediates, giving “CA compromise” as the reason. Its chairman later said this was done within 14 hours of discovery.
19 to 20 Oct. Apple, Android and Microsoft add blocks. Go, Node.js, Python’s certifi, Rust, Debian and Ubuntu ship updates. Oracle’s Java updates follow within days.
20 Oct. Mozilla decides to remove eMudhra’s emSign ECC Root CA – G3 from Firefox. Google announces the same for Chrome.
21 Oct. CERT-In issues an advisory. MeitY sets up a team to investigate.
22 Oct. eMudhra’s board decides to exit the global SSL/TLS certificate business.
27 Oct. Chrome’s scheduled removal of the G3 root.
For contrast, look at DigiNotar in 2011. That Dutch CA was actually hacked, forged certificates were used against real people, and the response stretched over weeks. This time there was no break-in, and the block came within hours.
What happened to eMudhra
eMudhra’s position is that its systems were not breached, no customer data was lost, only one of the eight intermediates was in production use, and none of them was used to issue certificates to websites or users.
Markets: eMudhra shares fell 20% to the lower circuit of ₹432 on the NSE on 21 October.
Business: the company is leaving the global SSL/TLS certificate business, which it says is about 1% of its revenue. It says affected customers will get free replacement certificates from partners, and that DSC, eSign and its other services continue.
Open questions: in 2025, eMudhra reported a problem with revocation lists for six of the same intermediates. Chrome said that report did not mention that two key pairs existed for those CAs, and that this “raises serious concerns regarding eMudhra’s transparency and incident handling.”
Ownership: on 26 October, eMudhra’s leadership said “the flaw was ours”, promised a published root cause analysis and commissioned an independent expert review.
There is also some collateral impact. Removing the G3 root affects about 30,000 certificates, mostly for US universities, that chain to that root through other intermediates, not the weak ones. They are being moved to eMudhra’s older RSA (G1) root or to other CAs.
Is my DSC, eSign or Aadhaar signing safe?
This is the question going around WhatsApp groups, so let’s be clear. According to MeitY, yes.
DSC and eSign (including Aadhaar-based eSign) are governed by the CCA under India’s IT Act. MeitY officials said these are “completely unaffected by this incident.”
Website (TLS) certificates are trusted by browsers under international rules and audits. This is where the problem was.
Officials described the impact on Indian websites and apps as “very limited and for a very short period” and cautioned against fear-mongering on social media. CERT-In also warned that scammers may use news like this for fake websites and fraud.
How to check if you are safe
The issue. The risk was never your data sitting at eMudhra. It was a device that still trusts the eight intermediates, or the emSign ECC Root CA – G3 above them, accepting a forged certificate for a real website. Today that risk is limited to devices and software that have not received the fixes.
The solution. Browsers and operating systems have blocked the eight intermediates and are removing the G3 root. On most phones and computers this happens automatically through normal updates. The gaps are devices that are rarely updated, and software that carries its own private list of trusted certificates.
For everyone
Update your browser. In Chrome, open Settings → About Chrome. In Firefox, open Help → About Firefox; version 158.0.1 or later has the fix.
Update your phone and computer: Windows Update, Android system and Google Play updates, and Apple software updates.
Check the website address before you type a password or OTP. Treat any message telling you to “fix” or “renew” a certificate as a scam.
For developers and admins
Update OS certificate packages and runtimes. Go 1.26.10 / 1.27.3 and Node.js 22.23.4 / 24.22.1 / 26.12.1 or later reject the eight keys.
Rebuild container images and apps that ship their own trust store (Java, Python
certifi, Electron). They do not update themselves.If your own website uses a certificate that chains to emSign ECC Root CA – G3, replace it now.
A few quick checks. No output from the first three means the G3 root is gone:
# Debian / Ubuntu system trust store
ls /etc/ssl/certs | grep -i "emSign_ECC_Root_CA_-_G3"
# RHEL / Fedora system trust store
trust list | grep -i "emSign ECC Root CA - G3"
# Python certifi bundle
grep -i "emSign ECC Root CA - G3" "$(python3 -m certifi)"
# Your own website: look for emSign in the chain
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | grep -i "emsign"Lessons from the trenches
Check the output, not just the process. A ceremony can follow every step and still produce a bad key. A simple check (is this key a sensible size?) would have caught this. Google said it found no other CA with this failure mode.
Ceremony scripts are software. They deserve the same review and testing as any production code.
Tell the whole story, early. Root programmes judge a CA as much on how it reports problems as on the problems themselves.
Know what you trust. Most of us never look at the trust stores inside our apps and containers. Incidents like this are a good reason to.
Key takeaways
Eight keys were made in a locked room, with certified hardware and witnesses, and turned out to be small enough to count on your fingers. The internet’s defences caught it within hours, no misuse has been found so far, and India’s DSC and eSign systems were not part of it.
Strong cryptography is rarely what fails. The scripts, labels and people around it are. That is true for a certificate authority, and it is true for the rest of us.
Coming up on Vajra Blogs
Elliptic-curve keys explained simply: why a large random number keeps you safe.
A hands-on walkthrough of recovering a weak test key, so you can see the problem for yourself.
