The eMudhra CA key compromise: what happened and what to check

On Saturday 17 October 2026, a security researcher reported that the private keys of eight intermediate certificates belonging to eMudhra, an Indian certificate authority (CA) whose emSign roots are trusted by the major browsers, could be worked out by anyone. Within hours, Chrome and Firefox blocked them. Within days, browsers had decided to stop trusting the root certificate above them.

This post explains what went wrong, why it was serious, what it means if you run a website, and what it teaches about watching certificates for more than their expiry date.

Facts here are as reported by Google, Mozilla, eMudhra and the public Mozilla incident record (bug 2083449) up to 22 October 2026. The investigation is still open.

A quick refresher: why CA keys matter

Browsers trust a website's certificate because it was signed by a CA they trust, usually through an intermediate certificate that sits between the CA's root and your certificate (more on the chain of trust).

Whoever holds an intermediate's private key can sign certificates for any domain, and browsers will accept them. That's why CAs generate these keys inside hardware security modules (HSMs) during formal, audited key ceremonies, and why a leaked CA key is one of the worst events in the web's trust system.

What happened

• The keys were tiny. The affected keys were P-384 elliptic-curve keys created at a key generation ceremony on 30 April 2025. According to the Mozilla incident record, each private key was a number below 256. A real P-384 private key is a random 384-bit number. A key below 256 can be found by trying at most 255 values against the public certificate, which takes a computer a fraction of a second. Mozilla recovered the keys independently.
• Eight intermediates were affected. Six were for TLS (website) certificates, trusted by Chrome, Mozilla, Microsoft and Apple. Two were code-signing CAs trusted by Microsoft. Some had also been cross-signed by Sectigo, another CA.
• The cause is still being confirmed. eMudhra says an approved test step in the ceremony (a key "wrap/unwrap" test) contained a code flaw that created a second, weak key pair alongside the strong one, and the weak keys were used by mistake. eMudhra says the HSMs themselves were FIPS 140-2 Level 3 certified, and that its root private keys and its RSA intermediates are not affected.

Why it was serious

Anyone could have recovered these keys from public information and used them to issue a certificate for, say, your bank's domain. Combined with a position on the network (a hostile Wi-Fi network, a compromised router, a malicious ISP), that certificate would let an attacker impersonate the site and read or change traffic, with the browser showing a normal padlock.

What it didn't mean

There's no public evidence the keys were abused:

• eMudhra says seven of the eight intermediates were never used in production, and the one that was had issued no certificates.
• Google says no TLS certificates chaining to these CAs had been logged in Certificate Transparency (CT) before the block. Chrome, and Android apps that enforce CT, reject certificates that aren't logged, so a forged certificate couldn't have been used against them unnoticed.

As of 22 October 2026, no misuse has been reported.

How the browsers responded

Apple and Microsoft also blocked the certificates, on 19 and 20 October according to press reports.

Why remove the whole root rather than just the eight intermediates? Not every program checks revocation or can be told to distrust a single intermediate. Removing the root protects them too. Google is also reviewing whether eMudhra's other CA certificates should stay trusted.

What it means if you run a website

If your certificate chains to emSign ECC Root CA - G3, Google's advice is that you "must immediately acquire and install" a new certificate from a CA that's still trusted. Once the root is removed, browsers will reject your site. eMudhra says it has stopped issuing from that hierarchy and is moving affected customers to its RSA root or to Sectigo-issued certificates. In the Mozilla record it estimated about 30,000 certificates need to move, most of them through ACME automation.

If you have other eMudhra certificates, eMudhra says those under its other hierarchies are not affected. Keep an eye on the incident record, because browsers are still reviewing the CA.

If you don't use eMudhra, your website isn't directly affected. But check the software you run:

• Non-browser clients (Java and Python apps, containers, build pipelines, IoT devices, API clients) use their own trust stores and often don't check revocation or CT. Update their CA bundles so the distrusted root is removed.
• Code signing: two of the eight were code-signing CAs. If you verify signed software on Windows, keep it up to date.

To see which root your site's certificate chains to:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

The last i: line names the root CA. Or run your domain through the free SSL checker, which shows the issuer and the full chain.

Why you should track revocation and validity, not only expiry

Most certificate monitoring stops at one question: how many days until it expires? This incident is a reminder that a certificate can stop working, or stop being trustworthy, long before that date:

• Certificates get revoked. When a key is compromised or a certificate was issued wrongly, the CA revokes it. Your site keeps serving it until someone replaces it.
• CAs lose trust. A whole hierarchy can be distrusted after an incident, as happened here, breaking every certificate under it on a date set by the browsers, not by you.
• Replacements need watching too. Moving to a new CA in a hurry means new certificates, new chains and new expiry dates, often on a schedule you didn't plan for.
• Renewals are about to get far more frequent. Certificate lifetimes fall to 100 days in 2027 and 47 days in 2029 (how to prepare), so there's more change to keep track of.

The only reliable way to know is to check, regularly and from the outside, what each server actually presents: is the certificate still valid, still trusted, and not revoked?

How CertHalo helps

CertHalo checks every certificate you add from the outside, the way a browser sees it, and alerts you by email, Slack or Microsoft Teams:

• Revoked: each check asks the issuer whether your certificate has been revoked, using OCSP and the CA's revocation list (CRL), and alerts the moment it has.
• No longer trusted: you're alerted if the chain stops leading to a trusted root or is incomplete.
• Changed: you're told when a certificate is renewed or its issuer changes, so a CA migration is visible and confirmed.
• Expiring: reminders 60, 30, 14, 7, 3 and 1 day before expiry, or on your own schedule on a paid plan.

Each check also grades the certificate's overall health from A to F and shows who issued it and the full chain, so you can see at a glance whether any of your sites depend on a CA in the news.

Run a one-off check with the free SSL checker, or monitor 3 certificates free.

Key takeaways

• Eight eMudhra intermediate CA keys were created so weak that anyone could recover them. Browsers blocked them within hours of the report on 17 October 2026.
• There's no evidence they were used to issue fraudulent certificates, and Certificate Transparency helped show that.
• Browsers are removing emSign ECC Root CA - G3. Sites with certificates under it need new ones now.
• Update trust stores in non-browser software, which doesn't get browser-style emergency blocks.
• A certificate's expiry date is only one way it can fail. Track revocation and trust as well.