Mozilla, Google, Apple block compromised eMudhra CA certificates

eMudhra revoked eight intermediate certificates after researchers discovered that their private keys were dangerously weak. An intermediate certificate can help issue certificates trusted by browsers and operating systems. Because these certificates were compromised, attackers could potentially impersonate legitimate websites or intercept encrypted communications.

Mozilla blocked the certificates through Firefox’s OneCRL system on October 17. Google Chrome blocked the six affected intermediates authorized to issue TLS certificates that same day. Apple added protections on October 19. The danger came from private-key values smaller than 256, making them easy to recover.

The response reduced the immediate risk, but protection is not universal. Firefox users whose settings blocked revocation updates needed newer releases, including Firefox 158.0.1. Software with separate certificate stores, or software that does not check revocations, may continue trusting the certificates. eMudhra also stopped issuing certificates under its G3 root.

A certificate authority, or CA, is an organization that browsers and operating systems trust to confirm website identities. It issues digital certificates that connect a website’s name with a public cryptographic key. Browsers use that information when establishing secure connections.

An intermediate certificate sits between the CA’s root certificate and a website certificate. The root authorizes the intermediate, and the intermediate can then sign certificates for websites or other certificates. This structure helps a CA limit exposure of its most important root key. In the eMudhra incident, eight intermediate certificates were weak enough that their private keys could be recovered.

That weakness mattered because browsers trusted the certificate chain. An attacker who recovered an intermediate private key could potentially create certificates that appeared authorized by eMudhra. Mozilla, Google, and Apple therefore blocked the affected intermediates, while eMudhra revoked them and stopped issuing new certificates under its G3 root.

The compromised certificates used P-384 private keys, but the keys were not actually strong. Mozilla’s incident report said all eight had private-key values smaller than 256. That reduced the recovery problem to a tiny set of possibilities.

An attacker could test just 256 possible numbers to find a matching private key. Security researcher Flüpke demonstrated the problem by publishing the key for eMudhra’s “EM OV TLS CA - G3C” certificate. Its private-key value was just 4. BleepingComputer independently verified that the published key matched a revoked certificate.

The weakness reportedly came from an error in eMudhra’s April 2025 certificate-generation script. The script created a second set of weaker keys, and similar labels caused some to be selected for signing. The keys may have been recoverable from their creation date onward, although the article reports no evidence that attackers used them.

Recovering an intermediate certificate’s private key would give an attacker the ability to sign new certificates under that trusted authority. Browsers and operating systems could then treat those counterfeit certificates as legitimate because they appeared to come through a trusted certificate chain.

The article’s central risk was website impersonation. An attacker could potentially create a certificate for a legitimate website and present it to users. The attacker could then position a system between the user and the real site, using the counterfeit certificate to make an encrypted connection appear trustworthy.

That could expose encrypted communications or enable other attacks against users visiting the impersonated site. eMudhra said most affected intermediates were never used in production and found no evidence they issued certificates to end users. Still, attackers could have recovered and abused the weak keys after April 2025, so revocation and software protections were necessary.

The vendors used certificate-blocking and revocation mechanisms to remove trust in the compromised intermediates. Mozilla blocked them through Firefox’s OneCRL system on October 17, without requiring a browser update or restart. Google Chrome blocked six affected TLS-authorized intermediates that day, and Apple added protections on October 19.

Mozilla later released Firefox 158.0.1 and updates for its ESR releases on October 20. Those updates helped users whose browser configurations prevented them from receiving earlier revocation data. The Go development team also released versions 1.27.3 and 1.26.10 for the issue tracked as CVE-2026-111943.

Some systems may remain vulnerable because they use their own certificate stores or do not check revocation information. Mozilla engineer Dennis Jackson warned that macOS’s built-in curl may continue trusting the certificates. Administrators should apply updates and use the advisory’s test endpoints and mitigation instructions.

A certificate is useful only while its issuing authority and private key remain trustworthy. If a private key is exposed, attackers may be able to create certificates that look valid. Revocation checks give browsers and other software a way to learn that trust has been withdrawn before a certificate reaches its normal expiration.

That mattered in the eMudhra case because the weak keys could have been recovered by testing only 256 values. Mozilla blocked the certificates through OneCRL, while Google and Apple added protections. These actions told supported software not to accept the compromised intermediates, even though they had previously been trusted.

Revocation is not applied everywhere automatically. Software may use an independent certificate store or skip revocation checks, leaving it exposed. The article specifically warns that macOS’s built-in curl may continue trusting the certificates. Updates, blocking rules, and administrator testing therefore remain important after a private key is exposed.

Public-key cryptography uses a matched pair: a public key that can be shared and a private key that must remain secret. A website certificate connects the website’s name to its public key. A trusted certificate authority signs that information, allowing a browser to verify that the certificate came through an accepted authority.

During a secure connection, the website proves possession of the matching private key through cryptographic operations. The browser checks the certificate signatures, the website name, and the chain leading to a trusted CA. If those checks succeed, the browser can use the website’s public key as part of establishing encrypted communication.

The eMudhra incident shows why the private key must be protected. The compromised intermediate keys could have let attackers sign apparently trusted certificates for legitimate websites. Browser blocks and revocation checks were needed because a valid-looking certificate could no longer be treated as trustworthy.