What Two Code-Signing Intermediates in eMudhra’s Key Compromise Mean for Software Makers

In October 2026, eight intermediate certificates issued by eMudhra, a certificate authority, were found to have compromised private keys. Two of the eight are for code-signing certificates. The other six issue TLS certificates, which secure HTTPS connections to websites.

On 17 October 2026, Chrome received a report at 18:05 UTC, according to Google, and Mozilla at 20:06 UTC, according to Mozilla’s bug. The researcher showed that the private keys could be worked out from the public certificates, and signed a test message with all eight keys to prove compromise. Mozilla’s bug report says the eight keys used integers less than 256, and that Mozilla recovered the private keys itself. Generator Labs says the largest value had only three digits, against the roughly 116 digits a P-384 key should have.

What the Two Code-Signing Intermediates Are

The two code-signing intermediates are EM OV CS CA – G3B and EM OV CS CA – G3C. Generator Labs says they issue code-signing certificates and do not affect TLS. The six TLS intermediates are the DV, OV and EV TLS CAs, each in the G3B and G3C variants.

A comment on the Mozilla bug by eMudhra’s Naveen Kumar ML says the code-signing issuers were not put into production and did not issue any certificates.

The two accounts conflict on the issuing root. The Mozilla bug lists the code-signing pair’s issuer as emSign Root CS CA – G3. Generator Labs says all eight intermediates chain to emSign ECC Root CA – G3, a root it describes as part of every major root store.

Chrome’s Expected Removal Date
Google says Chrome’s removal of the emSign ECC Root CA – G3 root is expected on 27 October 2026, Pacific time, with Chrome Canary and Chrome Beta receiving the change sooner.

What the Browser Blocks Covered

Chrome’s response was a CRLSet update that blocks the affected intermediate CAs by the hash of their public key. Google says the block took effect for Chrome at 19:45 UTC on 17 October. It says Android devices and Googlebooks received an equivalent update through Google Play Services at around 22:00 UTC on 19 October, and that most Android devices had already updated.

Google describes the protection as being against forged HTTPS certificates that could impersonate any website. It also says that no TLS certificates chaining to the six TLS intermediates had been logged to Certificate Transparency before the block, and that CT logs were then updated to reject certificates chaining to the compromised CAs. Google says it reviewed the other keys in its root stores and found none with the same weakness.

The Mozilla bug records the six TLS intermediates as trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The two code-signing intermediates are recorded as trusted by Microsoft. The bug also records a CRLSet showing the six TLS keys as revoked.

Mozilla’s bug says Firefox’s OneCRL block completed at 22:59 UTC on 17 October. Some users reported that Firefox for Android 158.0.1 did not block the certificates, and Mozilla acknowledged the Android issue.

What Apple and Microsoft Have Done So Far

The sources disagree on Apple. Generator Labs says Apple devices blocked the intermediates on 19 October. The Mozilla bug instead records that Apple corroborated the findings at 21:05 UTC on 17 October and noted the cross-signed certificates, then requested new attestations for them. The new attestations were emailed to Apple at 21:27 UTC.

The bug’s current-situation entry lists no response from Microsoft, and its timeline runs to 12:06 UTC on 18 October. A Sectigo comment in the bug says that the Sectigo-operated root that cross-signed the intermediates remains trusted in the Microsoft and Apple root programs, and that Sectigo has completed revocation of the affected cross-signed CA certificates.

No Microsoft block of the two code-signing intermediates has been announced.

eMudhra disabled the live G3C DV TLS CA on 17 October. Between 09:24:32 and 09:38:46 UTC on 18 October, it revoked all eight intermediates, with the reason given as a CA compromise. Mozilla asked it to cease issuance from all intermediates under emSign ECC Root CA – G3, and eMudhra later confirmed it had stopped. It plans to move subscribers to the G1 (RSA) chain. eMudhra estimates that about 30,000 certificates need migration, roughly 97 percent of them issued through ACME.

How the Weak Keys Were Generated, and the 2025 CRL Warning

Generator Labs says eMudhra created all eight intermediates in one key ceremony on 30 April 2025, and that Sectigo cross-signed them about two weeks later. According to eMudhra, a flaw in the ceremony script created a second, weaker key pair during a key-wrapping test. That weaker pair was used for certificate requests and root signing.

eMudhra also said its hardware security modules were FIPS 140-2 Level 3 compliant, and that human errors occurred at several process steps. It said it would re-verify all of its key ceremonies.

Generator Labs says CRL signature checks failed for the six TLS intermediates in May 2025. Sectigo reported the problem. eMudhra re-signed the CRLs with the weak keys and closed the incident as a process error. The Mozilla bug links the earlier problem to bug 1970728, which covered CRLs for the same TLS intermediates with invalid signatures.

Mozilla’s bug says it has not been able to recover the private keys for the P-384 keys in the A and A-1 series, and has not yet started on the RSA keys. Mozilla asked eMudhra to answer questions about its hardware, device mapping, RSA key status, why the A-series keys appeared unaffected, and how invalid CRLs were signed. The bug remains open while eMudhra’s root cause analysis continues.

The two code-signing intermediates are recorded as trusted by Microsoft.

The Browser Removal Timeline

Google says Chrome’s removal of emSign ECC Root CA – G3 is expected on all devices on Tuesday morning, 27 October 2026, Pacific time, and sooner on Chrome Canary and Chrome Beta. Google also says some legitimate certificates chaining to that root will stop working in Chrome.

Generator Labs reports that Mozilla removed emSign ECC Root CA – G3 from NSS on 20 October. Mozilla’s bug says it is not removing trust in emSign Root CA – G1, and that Firefox would ship an unscheduled release on 20 October.

Google says the Chrome Root Program is investigating whether eMudhra’s remaining CA certificates should stay in the Chrome Root Store. eMudhra has committed to working with impacted subscribers to migrate.

What Software Makers Should Check Before 27 October

Start with the signature itself. Open the properties of a shipped installer, plug-in or update file and read the certificate chain. Any chain that runs through EM OV CS CA – G3B or EM OV CS CA – G3C should go to the signing provider first. The issuer names in the sources differ, so the full chain is worth recording.

Then ask the provider in writing whether any code-signing certificate it issued came from either intermediate, when it will replace it, and whether it will help re-sign existing releases. Keep the answer with release records.

Check the web side too. Google says website operators with certificates chaining to emSign ECC Root CA – G3 must immediately obtain and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store.

Google says an equivalent update reached Android devices through Google Play Services, and that most Android devices have received it. No equivalent fix for signing trust has been announced, so a release team should not assume one exists.