eMudhra CA Key Compromise Explained: What Happened, Who's Affected, and What to Do

Igal Flegmann | October 21, 2026

Usually private keys for CAs are long random numbers. But this week, 8 publicly trusted CAs which are supposed to be super secure were found to have extremely weak private keys. One of the private keys trusted to secure the internet was the number 4. Not a long random number, just 4. In October 2026, a researcher found that eight intermediate certificate authority (CA) keys operated by eMudhra were so weak that anyone could calculate them in under a second. For about 18 months, anyone who thought to check could have used them to impersonate almost any website, or sign code that Windows would trust.

This post covers what happened in the eMudhra key compromise, how many CAs were compromised, who was protected, who is still exposed, and what you should do now, including the checks that matter for Windows and Intune-managed fleets.

What Happened in the eMudhra Key Compromise?

On October 17, 2026, an independent researcher credited as “Wayne” ran a test against the CCADB corpus of publicly trusted intermediate certificates and found that eight eMudhra P-384 keys were broken. He reported it to Apple, Google, Microsoft, Mozilla and eMudhra at 18:05 UTC the same day and, as proof, included a signed attestation from every key (quite gangster if you ask me to be “I compromised these keys here is a signature pretending to be each CA to prove it”).

An intermediate CA is the CA that issues the certificates your websites and apps use. Whoever holds an intermediate’s private key can issue certificates that browsers and apps accept (well all browsers also check the certificate transparency logs to ensure that the certificate is also there but most organizations don’t monitor them to ensure no one issues certifificates impersonating them). With these keys, an attacker could have created a valid-looking certificate for a bank, an email provider or a software update server. As Mozilla’s Dennis Jackson put it, these keys “could allow attackers to issue fraudulent HTTPS certificates for websites they do not control.”

The important detail: the keys were never stolen. These CAs use a Hardware Security Module (HSM) to protect their private keys, which are literally impossible to steal the keys from, so the compromise was purely due to weak key generation. They were generated incorrectly during a key ceremony in April 2025.

How Weak Were the eMudhra Keys? One Was the Number 4

The eight private keys were 4, 56, 66, 115, 155, 156, 230 and 237. A properly generated P-384 elliptic curve private key is a random number about 115 digits long, with roughly 384 bits of randomness. These keys had fewer than 8. Mozilla described them as “effectively all-zeroes apart from the last byte.”.

Think of a bank vault with a 115-digit combination, and the combination turns out to be smaller than your iPhone’s passcode

That is exactly what happened. Mozilla independently recovered the keys less than two hours after receiving the report, and security researcher Scott Helme recovered all eight on his laptop in under a second.

eMudhra Compromise Timeline

The browser blocks landed under two hours after the report. The weak keys had been public for about 18 months before that. All times are UTC and come from Mozilla Bug 2083449 and the ctlogs.dev incident timeline.

Root Cause: Was eMudhra hacked? No, it was a Key Ceremony Mistake, Not a Breach

According to eMudhra’s preliminary root cause, the April 2025 ceremony included an approved deviation to test key wrap and unwrap for export. A flaw in that script created a second, weak key pair on the HSM alongside each strong one. Because the two sets had similar labels, the weak keys were used to build the certificate signing requests (CSRs). eMudhra’s root then signed those CSRs, and they were sent to Sectigo for cross-signing. In eMudhra’s own words, “There were human errors in multiple steps of the process.” This is why it is important to have multiple people looking over the key ceremonies and actually ensuring that the right steps are followed. Additionlly you should never be testing in production.

eMudhra says the keys were generated on Utimaco HSMs certified to FIPS 140-2 Level 3, and that the hardware doesn’t appear to be at fault. That is the most uncomfortable lesson of this incident: a certified HSM protects a key from being stolen. It does nothing to stop you from generating a bad key, or from picking the wrong one. eMudhra says it will re-verify every key ceremony it has performed.

What were the warning signs eMudhra missed

In 2025, eMudhra published certificate revocation lists (CRLs) with invalid signatures for the same six TLS intermediates (Mozilla Bug 1970728). eMudhra now says those CRLs were first signed with the strong keys, failed to verify against the certificates, and were re-signed with the weak keys.

Read that again. The CA noticed that its CRL signatures didn’t match its own certificates, and fixed the symptom instead of asking why. A signature that doesn’t verify against the certificate it belongs to is exactly the signal that should stop a CA and trigger a full key review. Computers are really good at math, so if you turn it off and turn it back on and it gives you a different result, there is probably something wrong (more if it happens in 6 different machines).

Was the eMudhra Flaw Found by AI?

There’s no public evidence that AI discovered it. Bugzilla describes the researcher’s discovery as a test run over the CCADB corpus of intermediate certificates. Scanning public certificate data for weak keys is a long-established technique. Researchers have been finding weak RSA and ECC keys in the wild this way for over a decade.

The AI angle comes from two places:

• eMudhra’s statement says the researcher reverse-engineered the keys with the help of AI-assisted tooling. The researcher hasn’t said so.
• After the report, Mozilla found that several local AI agents recovered the keys on the first attempt when given a CTF-style prompt, and Scott Helme reported that an AI agent did it from a single prompt.

That demonstration measures how weak the keys were, not how clever the attack was. Trying 256 numbers takes a few lines of code that are not even complicated enough to make it to a Keytos interview question. AI didn’t find this. It just proved that anyone could have.

Who Was Protected, and Who Is Still Exposed?

Modern browsers were protected. Most other software was not.

Why Browsers Were Safe for the eMudhra attack?

We can confidently say that browsers were safe from this attack because the Certificate Transparency (CT) logs were checked against the certificate logs of the CAs and there were no extra certificates issued that were not issued by the CAs.

Why do CT Logs matter for the eMudhra attack analysis

CT logs are public, append-only records of issued certificates. Chrome, Edge Firefox, and Safari reject publicly trusted TLS certificates that haven’t been logged. Chrome confirmed that no TLS certificates chaining to the compromised intermediates had been logged before its block, so no forged certificate could have worked silently in those browsers.

CT is a notary, not a gatekeeper in won’t stop all future PKI attacks

Here is the part most people miss, CT logs don’t authenticate the CA. Anyone can submit a certificate, and the log only checks that it chains to an accepted root. So an attacker holding these keys could have logged a forged certificate. The catch is that it would have been instantly visible to everyone watching CT for that domain.

We now know this isn’t hypothetical. Once the keys were public, people started logging certificates signed with them. According to ctlogs.dev, more than 106,000 certificates from the compromised TLS intermediates had been logged by October 21, almost all of them for google.com. They appeared after the browsers had already blocked the intermediates, and most look like research or proof-of-concept certificates. But consider what they mean for a client that doesn’t check CT or revocation: a publicly logged, valid-looking google.com certificate is sitting there for anyone to use.

This is why monitoring CT logs is important. CT doesn’t stop a rogue certificate from existing. It makes sure everyone can see it, but only if someone is actually watching for your domains.

Who Is Still Exposed to the eMudhra attack

Most non-browser clients don’t check CT and we have seen a lot of then turn off revocation checking as well, so they keep trusting a chain until their code or root bundle is updated:

• Go programs, which only pick up the fix when they’re rebuilt with a patched Go version.
• Python apps using certifi, plus pip and uv, and anything built on them, such as the AWS CLI.
• Node.js and Electron apps that bundle their own roots.
• macOS command-line tools (curl, git, python3) that read /etc/ssl/cert.pem, which hadn’t been updated at the time of writing.
• Linux servers and container images with outdated ca-certificates packages.
• Appliances, IoT devices and internal tools with frozen trust stores. These are the long tail, and the emSign root they trust doesn’t expire until 2039.

What About Windows?

Microsoft began blocking the intermediates on October 20. Before that, Scott Helme’s testing found that Windows CryptoAPI accepted the forged chain unless revocation checking was enabled. Two Windows-specific risks are worth your attention:

• Code signing. The two code signing intermediates were trusted by Microsoft only. Anyone holding those keys could have signed binaries that chain to a root Windows trusts (these are harder to track since they are not certificate transparency logs for this). eMudhra says neither intermediate issued certificates, but again, an attacker didn’t need them to.
• Devices that don’t get trust list updates. Windows receives Microsoft’s certificate blocks through its automatic root and disallowed certificate updates. If you’ve turned those off with Group Policy (common in air-gapped and locked-down environments), your devices won’t see the block until you deploy it yourself.

Additionally, people that signed their binaries with legit certificates from eMudhra, their binaries will stop working on Windows so they should rebuild their binaries and sign them with a new CA and push the new version to all users.

What to Do Now: eMudhra Compromise Checklist

Update every trust store your software actually uses, not just your browser. The community-maintained incident page tracks the full patch list by package and distribution.

• Update browsers: Firefox 158.0.1 or later (ESR has patches too), and current Chrome, Edge and Safari.
• Confirm Windows devices are getting Microsoft’s trust list updates, especially if you’ve disabled automatic root certificate updates via Group Policy.
• Update OS CA bundles (ca-certificates on Ubuntu, Debian, Fedora, Alpine and other distributions), and rebuild container images that bake in an old bundle.
• Rebuild and redeploy Go services with Go 1.27.3 or 1.26.10 or later (Go announcement).
• Update certifi to 2026.10.19 or later in Python environments, plus pip and uv.
• Update Node.js and Electron apps to releases with the fix.
• On macOS, don’t rely on /etc/ssl/cert.pem for command-line tools until Apple updates it.
• Check appliances, IoT devices and vendor software with embedded trust stores, and ask your vendors for patches.
• Hunt for binaries signed by the compromised code signing CAs with Microsoft Defender for Endpoint (query below).
• Test your clients against the test hosts. A connection that succeeds means that client still trusts the compromised keys.
• If you hold eMudhra certificates under the G3 hierarchy, plan the migration now. eMudhra estimates about 30,000 certificates need to move, most of them automatically through ACME, to chains under emSign Root CA - G1.

How to Test Whether a Client Still Trusts the Compromised Keys

The researcher’s site serves certificate chains from the compromised intermediates. A certificate error is the result you want. Run the test from the actual machine, container or runtime your application uses:

# Linux / macOS / containers: an SSL certificate error means you're protected
curl -I https://dv-g3b-emudhra.we-have-a-problem.com/
curl -I https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

# Windows: tests the Windows trust store (a trust failure means you're protected)
Invoke-WebRequest https://dv-g3b-emudhra.we-have-a-problem.com/ -UseBasicParsing
Invoke-WebRequest https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ -UseBasicParsing

As Cloudflare pointed out, a successful test from your browser or your laptop doesn’t prove your background services are safe. Test the real path your application takes, and don’t “fix” a failing connection by disabling certificate validation.

How to Hunt for eMudhra Code Signing in Defender for Endpoint

If your devices are onboarded to Microsoft Defender for Endpoint, you can check whether any file on your fleet was signed by a certificate from the two compromised code signing intermediates:

DeviceFileCertificateInfo
| where Timestamp > ago(30d)
| where Issuer has "EM OV CS CA"
| summarize Devices = dcount(DeviceId), Files = dcount(SHA1) by Issuer, Signer

An empty result is what you want. Any hit deserves a closer look at the file, the device and how it got there.

Who Is eMudhra?

eMudhra is a publicly listed Indian company (NSE: EMUDHRA, BSE: 543533) that has been a licensed certifying authority in India since 2008. At its 2022 IPO it was India’s largest licensed CA, with about 38% of the country’s digital signature certificate market.

• 2008: Incorporated as 3i Infotech Consumer Services, a 3i Infotech subsidiary, and licensed by India’s Controller of Certifying Authorities.
• 2010 to 2014: Renamed eMudhra Consumer Services after an acquisition by Indus Innovest, then eMudhra Limited.
• 2018: Achieved WebTrust certification and launched emSign, its globally trusted public CA brand.
• 2019: Four emSign roots, including emSign ECC Root CA - G3, were added to Firefox in version 67 (Mozilla Bug 1515457).
• 2022: Listed on the Indian stock exchanges in June.

The company is controlled by its founding family, led by founder and Executive Chairman Venkatraman Srinivasan. eMudhra says global TLS is about 1% of its revenue and that its Indian digital signature and eSign businesses are unaffected. India’s Ministry of Electronics and IT (MeitY) has set up a team to investigate.

Lessons From the eMudhra Key Compromise for PKI Operators and Enterprises

A certified HSM doesn’t make a key safe. The process around it does. The planned steps of a key ceremony are rarely what goes wrong. The danger is the “quick extra step” someone adds the week before, which is exactly what happened here.

For Anyone Running a CA, Public or Private

• Treat every ceremony deviation as a new ceremony. A last-minute test step caused this incident, so deviations need the same scripting, review and witness sign-off as the main procedure.
• Validate keys after generation. Check generated key material for obvious weakness instead of trusting the HSM output, and confirm that each CSR’s public key matches the key you intended to use.
• Use unambiguous key labels. Two keys with near-identical names on the same HSM is an accident waiting to happen.
• Treat signature failures as incidents. An invalid CRL signature is evidence that something is wrong with a key, not a formatting bug to re-sign around.
• Automate what you can. Every manual, hand-edited step in a ceremony is a chance for human error. Our PKI best practices cover this in more depth.

This is one of the reasons we built EZCA the way we did. CA keys are generated inside HSM-backed Azure Key Vault or Azure managed HSMs through the same automated, tested code path every time, instead of a one-off ceremony script that someone tweaked with Claude last week.

For Enterprises

• Know which trust stores you depend on. Your browser updated itself in hours. Your Go services, Python containers and appliances didn’t.
• Plan for crypto agility. Root and intermediate changes can arrive with no notice, as eMudhra’s customers just learned. If you can’t rotate every certificate in your environment in a few days, the next distrust event will be an outage. Automating renewal with ACME and preparing for 47-day certificates builds exactly that muscle.
• Monitor CT Logs In this scenario there was no attacker using the keys, but if someone would compromise a CA, how long would it take you to notice that they issued a certificate to impersonate you? Certificate Transparency monitors such as EZMonitor can alert you if someone issues a certificate from a certificate authority that you usually don’t use.

eMudhra Key Compromise FAQ

Was eMudhra hacked?

No evidence suggests a breach. The private keys were generated incorrectly during a 2025 key ceremony, which made them recoverable from the public certificates. eMudhra says its infrastructure wasn’t compromised.

How many eMudhra CAs were compromised?

Eight intermediate CAs: six for TLS and two for code signing. Including Sectigo’s cross-signed copies, sixteen certificates were revoked. No root CA key has been shown to be weak.

Is the emSign ECC Root CA - G3 being distrusted?

Yes. Mozilla removed it from NSS on October 20, 2026, and Chrome is removing it in Chrome Root Store version 43. eMudhra has stopped issuing under it, and Chrome is also reviewing eMudhra’s remaining emSign Root CA - G1.

Do I need to replace my eMudhra certificate?

If it chains to emSign ECC Root CA - G3, yes. eMudhra estimates about 30,000 certificates need to move to chains under emSign Root CA - G1, and says most were issued through ACME and can be reissued automatically.

Were any fake certificates issued?

None were logged in CT before the browsers blocked the intermediates. Since the keys became public, more than 106,000 certificates signed with them have been logged, almost all for google.com. Browsers reject them, but clients that don’t check CT or revocation may not. There’s no way to rule out unlogged certificates used against non-browser clients during the 18 months the keys were exposed.

Was the flaw discovered by AI?

There’s no public evidence of that. AI agents recovered the keys after the report, which shows how weak they were, not how they were found.

Is my browser safe?

Current versions of Chrome, Edge, Firefox and Safari block the compromised intermediates. Update if you’re behind.

Are eMudhra’s Indian digital signatures affected?

eMudhra and Indian officials say its Indian DSC and eSign services run on separate infrastructure and are not affected.

Know About Rogue Certificates Before Attackers Use Them With EZMonitor

The eMudhra incident proved two things. First, CT logs are the internet’s early warning system, but they only help if someone is watching them for your domains. More than 100,000 google.com certificates showed up in public logs in a matter of days. Would you know if one showed up for yours? Second, when a CA is distrusted overnight, the teams that recover fastest are the ones that already know where every certificate lives.

EZMonitor, our SSL and CT log monitoring tool, does both:

• Certificate Transparency monitoring. EZMonitor scans and indexes CT logs and alerts you when a certificate is issued for your domains, so an unauthorized certificate is caught as soon as it’s logged, whichever CA issued it.
• One inventory for public and private certificates. It scans your public endpoints and your internal network, so you can quickly find every certificate affected by the next distrust event.
• Alerts where your team works. Get findings by email, in Microsoft Sentinel or your SIEM, or through the API.
• Fast to start. EZMonitor is hosted and connects to your Azure tenant, so you can be monitoring in minutes.

Want to see what’s already in the CT logs for your domains, or talk through how this incident affects your environment? Schedule a FREE call with one of our PKI experts, or get started with EZMonitor today and find out about the next rogue certificate before your customers do.