Eight eMudhra CA keys were compromised. Here is what it means for you

Eight eMudhra intermediate CAs were created with private keys that anyone can recover from the public certificate. Browsers blocked them within hours of the 17 October report, and the certificates are now revoked. We have checked every inventory in Red Sift Certificates and Hardenize, and contacted the affected accounts: those with certificates under the eight CAs and those with certificates under the emSign ECC Root CA - G3, which Firefox and Chrome are now removing. If you run anything that speaks TLS without a browser in front of it, update your trust stores.

eMudhra, the Indian CA behind the emSign brand, set up eight new intermediate CAs on 30 April 2025: six for TLS certificates and two for code signing. A month later, Sectigo cross-signed all eight under its AAA Certificate Services root, so each key lives in two certificates that share the same Subject Key Identifier.

Nobody had to steal these keys. Each one is a P-384 elliptic-curve key whose secret value is below 256, and one of them is the number 4. With the certificate in hand, you can recover the private key on a laptop in well under a second by trying each value in turn. eMudhra has not confirmed the root cause yet. Its preliminary explanation is that a flaw in the key-ceremony script produced a second, weak key pair alongside the strong one, and the weak pair was included in the certificate requests because the labels looked alike.

A researcher reported this to the browser root programs on 17 October 2026, with a message signed by all eight keys as proof. These are the affected intermediates. Each hash links to its crt.sh entry.

• 17 October. A researcher reported the keys to the browser root programs. Within hours, Chrome and Firefox pushed updates telling every installed browser to reject them, with no new browser version or restart needed.
• 18 and 19 October. eMudhra, then Sectigo, revoked the certificates. Apple pushed the same rejection to iOS and macOS.
• 20 October. Windows followed. Mozilla published the details and removed the emSign ECC Root CA - G3 from Firefox; Chrome has said it will follow. Mozilla is keeping the RSA emSign Root CA - G1, which Chrome is still reviewing.

The good news is that nothing was issued under these CAs before the block. Google confirmed that no certificate chaining to them was ever logged in Certificate Transparency, and eMudhra says they issued no customer certificates at all.

Desktop Chrome, Safari, Firefox, and Edge reject a TLS certificate without CT proof, so a forgery could not have been trusted by any of them. That protection is not universal, though. Mozilla is still working on a problem with Firefox for Android 158.0.1, and clients that do not enforce CT get none of it. Since the disclosure, researchers have logged more than 100,000 demonstration certificates under these keys, including forgeries for google.com. That is how little effort this takes.

• You hold a certificate from one of the eight CAs. The issuing intermediate is revoked, so the chain is untrusted, and browsers reject it. Replace it. eMudhra says this group is empty; check your inventory rather than take its word for it.
• You hold a certificate that chains to the emSign ECC Root CA - G3. It is not compromised, but Firefox no longer trusts that root and Chrome will stop soon. eMudhra's initial estimate is that about 30,000 certificates need to move to its RSA root, emSign Root CA - G1, which Mozilla is keeping. Reissue yours before the Chrome change reaches your users.
• Your software connects to other servers over TLS. That is everyone. curl, Python, Node.js, Go, Java, CI runners, API clients, mutual TLS, and embedded devices trust a certificate bundle on disk and mostly check neither revocation nor CT. A researcher forged a certificate for a well-known payments API, and curl, Python, and Node.js all accepted it by default. Until your bundles are updated, so will yours.
• You verify signed Windows software. Code-signing certificates are not logged in CT, so nobody can list what was signed under the two code-signing CAs. eMudhra says nothing was, but the keys have been weak since 30 April 2025, so a timestamp proves nothing. Treat anything signed under them as untrusted.

On 21 October, we searched every inventory in Red Sift Certificates and Hardenize for certificates under the eight keys, matching on the issuer's key identifier and on the chain hashes of all sixteen certificates. We found a handful, none on a live service, all logged after the disclosure by researchers testing the recovered keys. We also searched for certificates under the ECC G3 root. We have contacted every account in either group.

You can check this yourself. The Certificate Authorities widget on your dashboard, below, lists the CAs behind your certificates. If eMudhra appears, open those certificates, compare the issuing CA's SHA-256 with the table above, and look at which root the chain ends in. Only certificates under the eight intermediates are compromised. Certificates under the ECC G3 root are not; they will need to be reissued. InCommon certificates issued since April 2026 also show as eMudhra, because their intermediates are issued under eMudhra's G1 root; they need nothing.

• Update trust stores everywhere. Update OS CA packages, Python certifi, Node.js, Java cacerts, Homebrew, and bundled trust stores. Rebuild Go binaries with a patched toolchain and containers with updated base images and dependencies, then redeploy.
• Block the compromised CAs. Check mTLS, VPNs, API gateways and certificate pins. Reject the affected keys through both eMudhra and Sectigo cross-signed chains; deleting a cached intermediate alone is not enough.
• Reissue certificates chaining to emSign ECC Root CA - G3. Replace them with certificates chaining to a trusted root before Chrome’s change reaches your users.
• Keep verification enabled. Investigate certificate errors after updates rather than disabling the checks.
• Test the real path. Confirm the actual application rejects compromised chains. A browser or laptop curl test does not prove a production service is protected.
• Identify devices you cannot update. Restrict their network access. Where supported, use an updated gateway that terminates TLS and validates upstream certificates. A firewall alone is not enough.

Red Sift Certificates keeps a live inventory of every certificate on your estate, with the chain each server actually sends, so a CA incident becomes a search rather than a scramble. The Certificate Authorities widget shows which CAs you depend on, and Certificate Transparency monitoring tells you when a new certificate is issued for your domains and who issued it.

If you are not yet a Red Sift Certificates customer and want to know whether any certificate on your domains chains to these CAs, request a free demo.

• eMudhra Intermediate CA Compromise: disclosure page and test site
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates (includes the Chrome Root Program statement)
• Bugzilla 2083449: Private key compromise of eMudhra Intermediate Certificates
• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know
• Scott Helme: Eight bits of trust, eMudhra's CA keys cracked in milliseconds