Compromise of eMudhra Intermediate CA Certificates · CIAD-2026-0050

CERT-In Advisory CIAD-2026-0050

Compromise of eMudhra Intermediate CA Certificates

Original Issue Date: October 21, 2026

Description

eMudhra Limited, operates in two distinct areas:

Issuance of digital signature certificates and eSign services, regulated by the Controller of Certifying Authorities (CCA) under MeitY.

Issuance of digital certificates trusted by major browsers and operating systems, used to secure websites, software and online communications.

This advisory pertains to the reported incident in public domain to the second area. The issuance of digital signature certificates and eSign services, regulated by the Controller of Certifying Authorities (CCA) under MeitY are not impacted.

The second function is international in nature and operates under global trust framework. It is governed by international standards and subject to independent audits, including Web Trust audits conducted by BDO International Limited.

The affected private keys were generated with insufficient cryptographic randomness. The P-384 elliptic-curve private keys had values smaller than 256 and could be recovered almost instantly from their corresponding public keys. The weakness arose during key generation and does not indicate a vulnerability in the P-384 cryptographic algorithm itself. Whereas eMudhra has stated in its public press release, "A flaw in the key generation ceremony caused a wrap / unwrap step to produce a second set of weak keys along side the original strong keys. The weak keys were the ones published to the browser root stores."

An attacker who recovers these private keys could issue fraudulent certificates for domains they do not control. Such TLS certificates could be used to impersonate legitimate websites and facilitate man-in-the-middle (MitM) attacks, potentially enabling the interception or modification of encrypted communications where an attacker can intercept network traffic and the affected certificate chains remain trusted by the client. The compromised code-signing keys could also be used to issue fraudulent code-signing certificates.

According to eMudhra, none of the affected intermediate CAs had issued end-entity certificates. The company stated that only one of the affected intermediates had been deployed in production. The company has stated that the incident is limited to the affected intermediates and does not involve its root CA private keys or other intermediate CAs. As per the reports, eMudhra’s domestic Indian Digital Signature Certificate (DSC) and eSign infrastructure remained completely unaffected due to strict architectural isolation, utilizing distinct cryptographic keys generated under different regulatory compliance frameworks.

eMudhra revoked the eight affected intermediate certificates on October 18, 2026. M/s Mozilla blocked the six affected TLS intermediate certificates through its OneCRL certificate block list on October 17, 2026. Mozilla released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to protect users whose configurations prevent them from receiving OneCRL updates. Mozilla has also updated the trusted certificate list in Network Security Services (NSS) 3.131.1 to remove the root certificate emSign ECC Root CA - G3, which signed the affected intermediates.

M/s Google blocked the public keys of the affected TLS intermediates in Chrome through a Certificate Revocation List Set (CRLSet) update on October 17, 2026. The blocking was based on the Subject Public Key Information (SPKI) hashes, protecting against certificates using the affected public keys. Google also reported deploying equivalent protections to supported Android devices through Google Play services. Google has also announced the removal of emSign ECC Root CA - G3 from the Chrome Root Store. The change is expected to reach devices relying on the Chrome Root Store on October 27, 2026. The root-store changes are intended to protect applications and devices that do not receive or enforce intermediate-certificate revocation information.

Impact

An attacker able to exploit the compromised TLS private keys could issue fraudulent TLS certificates and potentially impersonate legitimate websites or intercept or modify data exchanged between users and servers, potentially facilitating credential theft, sensitive data exposure, and financial fraud. Compromised code-signing keys could be used to issue fraudulent certificates, enabling malicious software to appear digitally signed by a trusted publisher.

Google reported that no TLS certificates chaining to the six affected TLS intermediates were recorded in Certificate Transparency (CT) logs before its blocking action. eMudhra has also stated that the affected intermediates had not issued end-entity certificates. As of October 21, 2026, the cited public disclosures do not establish confirmed malicious exploitation of the affected keys.

Removal of emSign ECC Root CA - G3 from browser and application trust stores could render legitimate certificates issued under that root untrusted, potentially disrupting affected websites and services.

Target Audience

Government departments, organisations, enterprises, internet service providers, software vendors, website administrators, application developers, system and network administrators, operators of embedded devices, and users relying on TLS certificates and affected certificate trust stores.

Best Practices

Apply security updates:

Update Firefox, Firefox ESR, Chrome, supported Android components, and other affected browsers, applications and operating systems to the latest security releases provided by their respective vendors.

Update certificate trust stores:

Ensure that operating systems, applications, servers and devices receive the latest certificate revocation and distrust information from their respective vendors. Verify that affected certificate chains are rejected by the relevant clients.

Review certificate dependencies:

Identify certificates and services chaining to the affected intermediate CAs or emSign ECC Root CA - G3. Assess the impact of the intermediate-certificate blocking measures and root-store changes on websites, applications and other dependent services. Include relevant cross-signed certificate chains in the review.

Replace affected certificates:

Obtain replacement TLS certificates from a trusted, unaffected PKI hierarchy where required. Administrators should also replace otherwise legitimate certificates chaining to emSign ECC Root CA - G3 if they will no longer be trusted by the relevant clients.

Verify TLS certificates:

Validate certificate chains, issuer information, validity periods and revocation status. Do not bypass certificate-validation warnings or disable certificate verification. Confirm that applications reject certificates chaining through the compromised intermediate CA keys.

Monitor certificate issuance:

Monitor Certificate Transparency logs and security alerts for unauthorised certificate issuance, unexpected certificate changes and other suspicious activity involving affected domains or services. CT monitoring should supplement, rather than replace, certificate revocation and trust-store controls.

Review independent certificate trust stores:

Examine applications, programming-language runtimes, container images, TLS libraries, network appliances and embedded systems that maintain separate CA certificate bundles or do not reliably check certificate revocation. Apply applicable vendor updates and redeploy affected components where necessary.

Review code-signing trust:

Software vendors and administrators should verify the trust and revocation status of relevant code-signing certificate chains and use additional software integrity and provenance checks where appropriate.

Strengthen CA key management:

Certification authorities should use approved cryptographically secure random number generators, implement appropriate hardware security module (HSM) controls, and review key-generation procedures and key-lifecycle management to prevent recurrence of similar weaknesses. Independent verification of generated key parameters, key identifiers, certificate-signing request (CSR) mappings and maker-checker controls should form part of the key-generation process.

Maintain secure configurations:

Ensure that applications, embedded devices and other systems receive timely security and trust-store updates. Where vendor support is unavailable, assess exposure and implement appropriate compensating controls.

References

https://www.mozilla.org/en-US/security/advisories/mfsa2026-111/

https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/

https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

https://emudhra.com/en/post/certificate-security-incident

https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

https://nsearchives.nseindia.com/corporate/EMUDHRA2008_21102026105726_Press_Release_21102026.pdf