Skip to content
HANU
Deploy Hanu
Menu

By role

Eight CA keys, generated weak, recovered by a researcher

An intermediate CA key lets you issue a certificate for any domain that browsers will accept. Eight of eMudhra's were generated so weakly that someone worked them out from the public certificates — one of them was the number 4.

emudhra ca compromiseemsign root ca distrustedCVE-2026-111943

On 17 October 2026 at 20:06 UTC, Mozilla received a report that the private keys of eight eMudhra intermediate CA certificates were compromised. Chrome verified the finding, and both Chrome and Firefox blocked all eight within hours. The root programs confirmed publicly on 20 October.

An intermediate CA certificate signs the certificates that websites present. Hold its private key and you can issue a certificate for any name — a bank, a government service, an update server — and a browser that trusts the chain will accept it. Two of the eight were code-signing intermediates, which extends the same problem to signed software.

The eight compromised intermediatesGenerated 30 Apr 2025 · blocked 17–20 Oct 2026 · CVE-2026-111943
UseCertificatesWhat a holder could do
TLS, domain validatedEM DV TLS CA - G3B, EM DV TLS CA - G3Cissue a cert for any domain
TLS, organization validatedEM OV TLS CA - G3B, EM OV TLS CA - G3Csame, with an organization name
TLS, extended validationEM EV TLS CA - G3B, EM EV TLS CA - G3Csame, with the EV indicator
Code signingEM OV CS CA - G3B, EM OV CS CA - G3Csign software and fake updates

The mechanism

eMudhra's own account, filed with the BSE stock exchange on 21 October, is that the eight intermediates were created under its ECC root in a key generation ceremony on 30 April 2025, using hardware security modules certified to FIPS 140-2 Level 3, and that a flaw in that ceremony corrupted a key wrap and unwrap step. The result was key material with far less entropy than its size implied. A researcher found over the weekend of 17 October that the keys could be reverse-engineered — eMudhra's statement says "possibly with AI-assisted techniques" — and reported it to Apple, Google, Microsoft and Mozilla. One of the recovered private keys was the integer 4.

The company maintains that its infrastructure was not intruded, that no data was breached, that the incident does not affect its root CA private keys or other intermediates, that only one of the eight had been deployed in production, and that none of the eight — including that one — had issued any end-entity certificate. It has since left the SSL/TLS business. Whether anyone exploited the keys between April 2025 and October 2026 is not known, and the nature of the flaw means there would be nothing in eMudhra's logs to say either way: deriving a key from a published certificate leaves no trace at the CA.

What makes this incident instructive is the shape of the fix. Revocation is the mechanism the web has for exactly this, and it did not work. Chrome pushed its blocklist, Mozilla pushed OneCRL, and then the fixes had to be written into code — Go handled it on its URGENT track as CVE-2026-111943, rejecting any chain containing one of the eight keys, and removing emSign ECC Root CA - G3 from its bundle. Go's standard-library maintainer was blunt about why: Linux root stores are too poorly maintained for revocation to reach applications, so putting the keys in code was the only option. Anything that checks TLS without processing revocation data — a Go binary, anything using Python's certifi — keeps trusting a chain until its code or its bundle changes.

What we would have seen

  • CERT-TRUST-INTERMEDIATE-COMPROMISED fires critical on a chain through any of the eight, matched by issuer and subject name pattern, with the public record of the block as the stated source.
  • CERT-TRUST-POST-BLOCK-ISSUANCE escalates when the certificate's issuance date is after the block date — a certificate that should not exist, because no conforming CA would have signed it by then.
  • CERT-TRUST-ROOT-DISTRUSTED fires high for emSign ECC Root CA - G3 and emSign Root TLS CA - G3, the roots pulled from the Mozilla, Chrome and Go bundles.
  • The ACM certificate transparency audit cross-references CT logs, which answers the question the trust-store change actually raises: not "is my certificate on a list" but "does anything I own chain through a poisoned issuer". STALE_CERTIFICATE then orders replacement by expiry.

What to do

  1. 01

    Separate impersonation from expiry

    Find anything that chains through the eight intermediates first — that is the impersonation case and it is urgent regardless of expiry. Then find what chains to the removed root; that is a scheduled outage you can plan, as long as you plan it before a client updates.

  2. 02

    Look in certificate transparency, not just your inventory

    Your inventory holds the certificates you know you have. CT logs hold the ones issued for your names, including by teams and vendors who did not tell you. For a CA incident, the second list is the one that matters.

  3. 03

    Check the clients, not only the servers

    Revocation did not reach applications here. Inventory what pins certificates or ships its own trust bundle — Go binaries, containers using certifi, mobile apps, embedded devices — because each one trusts the chain until someone rebuilds it.

  4. 04

    Reissue from a CA still in the root programs

    Replacement, not renewal: a renewal from the same issuer inherits the problem. Check your internal trust stores too, since a root removed from browsers may still be installed on your own machines.

eMudhra says none of the eight issued any end-entity certificate. Is there anything to do?
Yes, for two reasons. The first is that the statement covers what the CA issued, and the whole problem is that someone else holding the key can issue without the CA knowing — a certificate minted from a recovered key would not appear in eMudhra's records at all. The second is the root removal, which is independent of the eight: if anything you own chains to emSign ECC Root CA - G3, it will be rejected by clients that have updated their bundle, whether or not the intermediates were ever used.
Our certificates come from a different CA. Does this affect us?
Directly, probably not. What it should change is how you treat CA concentration as a risk. The actionable question is whether you can enumerate, today, every certificate issued for your names and the issuer chain of each — because that is the question a CA incident asks, and the answer has to come from certificate transparency rather than from an inventory you maintain by hand.
Why does revocation not solve this?
Because much of the software that validates TLS never checks it. Browsers have their own push mechanisms — Chrome's blocklist, Mozilla's OneCRL — and those worked within hours. Outside the browser, a great deal of code trusts a compiled-in or packaged root bundle and processes no revocation data, which is why the fixes had to hard-code the blocked keys and ship as a release. Your exposure window is the time until the things you run get rebuilt.
Was this an AI attack?
No. eMudhra's statement says the weak keys could be reverse-engineered "possibly with AI-assisted techniques", which is a note about the researcher's method, not about an attacker. The failure was a key generation ceremony that produced keys with almost no entropy. The keys were weak from the day they were created; the only thing that changed in October 2026 is that someone checked.

Run it in your own account

One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.

Deploy HanuSee what is paid