Eight eMudhra CA keys were recoverable from tiny numbers. Firefox blocked them; 30,000 certificates may need migration

What the primary record actually says

The Mozilla Security Team notice of 20 October reports receipt at 20:06 UTC on 17 October, OneCRL distribution complete by 22:59 UTC, Firefox 158.0.1 and ESR updates on 20 October, and an NSS trust-store update. The more technical record is public Bugzilla issue 2083449, which contains dated comments by Mozilla, eMudhra, Sectigo, the Chrome Root Program and the original reporter. I read its public comment record on 20 October. Some responses are preliminary and the issue is still open; the entries below are attributed to their speakers rather than treated as one settled company account.

Mozilla's first incident entry says the original report included proof of control over all eight private keys. Mozilla says it independently recovered them at 21:48 UTC on 17 October without being told the reporter's method. In its technical investigation, Mozilla states that the weak values arose in key generation, not from a way to forge an otherwise sound signature. It describes all eight affected values as integers below 256. That is not a small reduction in a normal 384-bit search space. A normal P-384 private scalar spans an enormous range; restricting it to 1 through 255 leaves at most 255 candidates. This is why the keys should be described as recoverable, even if no one physically extracted a secret from an HSM.

The original reporter dates their discovery to 16:27 UTC on 17 October in their timeline. Mozilla's receipt time is later because the report travelled through the Chrome Root Program. Mozilla's own 21:48 recovery corroborates the weakness. The public record does not establish when someone first recovered these keys before 17 October, whether anyone issued a fraudulent certificate, or whether traffic was intercepted. It also does not yet identify the precise mistake in the key-generation script or device process. eMudhra says it is investigating that root cause.

Which eight certificates, and why six is not eight

Mozilla lists six TLS intermediates chaining to roots trusted by major browser programmes and two code-signing intermediates trusted by Microsoft. The six TLS certificates cover DV, OV and EV variants in the G3B and G3C series. The two code-signing certificates are OV CS variants. The eight were part of a batch of 24 intermediates created on 30 April 2025, according to Mozilla's preliminary analysis. That is a generation date, not a proven date of attacker access.

This split changes the practical threat statement. A recovered TLS intermediate key could be used to sign a plausible website certificate. To impersonate a site to a user, the attacker would also need a trust path the client accepts and a way to put the forged certificate in the user's connection path. The two code-signing intermediates raise a different trust question; a TLS browser mitigation cannot be assumed to protect a code-signing verifier. Mozilla's incident record describes trust in those two under Microsoft, while its Firefox blog concentrates on website certificates. Operators should identify the application and trust store involved before assuming one browser update covers all eight purposes.

The exact affected intermediate certificates, serial numbers and SHA-256 fingerprints appear in Mozilla's first Bugzilla entry. For certificate inventory work, match those identifiers or the issuer chain rather than a string such as “eMudhra” alone. A broad name search could sweep in unaffected issuers and miss a cross-signed path with a different visible root.

Two protections, different populations

The trust chain at issue is root certificate → intermediate certificate → website or code-signing certificate → validating application. Firefox's OneCRL blocks the eight affected intermediates for standard clients. Mozilla says it completed distribution through RemoteSettings by 22:59 UTC on 17 October, which is 2 hours 53 minutes after it received the report. “Distribution complete” is not a measurement of every browser having downloaded and applied the list at that instant.

Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 on 20 October embed the updated blocklist. Mozilla says that packaged route covers a minority of users whose policy or network prevents RemoteSettings delivery. The Firefox advisory assigns CVE-2026-113470 to this certificate blocklist issue. The same Firefox release contains other, separate security fixes. Do not read their CVEs as additional eMudhra incidents.

The second protection is broader. Mozilla says NSS 3.131.1 removes the root signing the affected TLS intermediates for applications that use Mozilla's trust store but do not receive Firefox's OneCRL feed. In a 20 October incident comment, Mozilla names that root as emSign ECC Root CA - G3, says multiple people had independently recovered the intermediate keys and asks eMudhra to stop issuing from that root. Mozilla explicitly says it is not removing trust in emSign Root CA - G1 at that time. Chrome's root programme said it would follow a similar path. Those are root-programme decisions, not proof that every operating system and embedded device already received the change.

Why the root decision has a cost

Blocking the eight intermediates addresses those keys directly. Removing trust in the G3 root can also break otherwise legitimate chains beneath it until site owners move to a trusted chain. In its 20 October response, eMudhra estimated about 30,000 certificates require migration and said about 97% came through ACME. It proposed moving subscribers to intermediates chaining to the G1 RSA root, and later said issuance under the G3 root had ceased. The 30,000 is the CA's initial migration estimate, not the number issued by the eight weak keys and not a victim count. Multiplying 30,000 by 97% would yield about 29,100 ACME-managed certificates as a rough derived figure, but the estimate can change and says nothing by itself about which subscribers have already moved.

The diagram distinguishes the compromised intermediate-key route from the subsequent root distrust. It shows a security control and a compatibility consequence, not evidence of certificate misuse.

Key ceremony, CRLs and unresolved causation

eMudhra's 19 October comment says the affected intermediates came from one 30 April 2025 key-generation ceremony using Ultimaco HSMs. It says most were not put into production and claims no end-entity certificates were issued from the one G3C DV TLS intermediate it says was live. That is a CA statement under investigation, not an independent audit of every issuance record. The company also says other issuers generated using different HSM vendors did not show the same weakness. Mozilla's preliminary analysis says it had not recovered keys from the A/A-1 P-384 series after additional effort and had not yet tested the RSA keys. Neither statement is a final proof that every other eMudhra key is sound.

The Bugzilla record raises a separate historical concern: the six affected TLS intermediates appeared in a 2025 invalid-CRL-signature issue. Mozilla notes the overlap and asks eMudhra how wrong keys came to sign those revocation lists. The overlap is a lead, not proof that the 2025 CRL fault caused the 2026 weak private keys. The original reporter also found a later invalid CRL signature for a different G1 root; its cause and relevance are unresolved. These questions matter because certificate revocation is a control only when clients can obtain and verify the right revocation material.

eMudhra says it marked all eight intermediate certificates revoked with the cACompromise reason on 18 October, with recorded CRL times between 09:24:32 and 09:38:46 UTC. Sectigo, which had cross-signed some affected intermediates, reported on 19 October that it had completed revocation of the cross-signed CA certificates and published new CRL and OCSP responses. Those statements describe revocation actions and distribution, not proof that all relying parties had already consumed them.

What to check on a real estate

For Firefox users, check the installed desktop, Android or ESR version and confirm whether RemoteSettings is permitted by policy and network rules. A standard Firefox client that received the 17 October OneCRL update was protected before the 20 October point release; an isolated client may need the packaged version. For software using NSS or a Mozilla-derived trust store, identify the actual bundled NSS version and trust-store refresh path, not merely the browser version on the same host.

For website operators, inventory chains that terminate at emSign ECC Root CA - G3 and ask the issuing CA or ACME automation provider for a replacement chain. Test the replacement on each relevant browser and platform before retiring the old chain. A sudden certificate error after root distrust can be an expected compatibility signal; bypassing the warning is not a remedy. Monitor your domains' Certificate Transparency records for unexpected issuance, but do not equate a lack of noticed entries with proof that a weak key was never used.

For enterprise PKI and code-signing teams, check whether any validation stack trusts the two affected code-signing intermediates or a cross-signed path. Review software and device trust-store update schedules, especially appliances, embedded clients and older runtimes that may lag browsers. The available Mozilla notice cannot verify those products' patch states for you. Where an application cannot process revocation and still trusts a relevant root, identify an alternative trust-store update or explicit distrust path through that vendor.

What would change this assessment

An incident report from eMudhra explaining the HSM workflow, key-generation script and scope testing would resolve the core “how” question. A published audit of certificate issuance and CT/CRL evidence could clarify whether the weak intermediates signed end-entity certificates and whether any unexpected certificate appeared. Platform-specific notices would establish when the root or intermediate blocks reached each relying party. None of those should be inferred from Mozilla's 2-hour-53-minute Firefox distribution interval.

Sources checked 20 October 2026: Mozilla Security Team notice; Mozilla Bugzilla incident 2083449 and dated comments linked above; Firefox advisory 2026-111; Firefox ESR advisory 2026-113; earlier CRL incident 1970728. The Bugzilla issue remains open and its later comments may change the account.