Chrome and Firefox Block Eight Weak eMudhra Keys

Mozilla and Google's Chrome Root Program confirmed on October 20 that eight eMudhra certificate keys were compromised, exposing credentials that could let someone impersonate trusted websites or sign software. ^[2][4][5]

Six keys belonged to intermediate certificates authorized to issue website TLS certificates, the credentials browsers check when establishing a secure connection. Two were for code signing, which software uses to check a program's publisher. Chrome and Firefox have blocked the affected website credentials, while fixes across other software are moving at different speeds. ^[2][4][5]

The keys were extraordinarily weak. Mozilla said all eight were numbers below 256, rather than the enormous random values expected for this kind of cryptography. It independently recovered the website-certificate keys and described the flaw as trivial to exploit. ^[5]

Security researcher Scott Helme said he recovered the keys from the public certificates in under a second. Possession of a stolen file was unnecessary, the public information was enough to work out the secret. ^[3]

A researcher identified as Wayne first reported control of all eight keys to browser trust programs and eMudhra on October 17. His proof included a message signed with the compromised credentials: "We have a problem here - Wayne." ^[5]

The power to vouch for a website

A browser trusts a website through a chain of certificates. At the top is a root certificate already accepted by the browser. Below it, an intermediate certificate has permission to issue further certificates.

A website presents its own certificate, and the browser checks that the chain leads back to a root it trusts.

Control of an intermediate's private key can therefore give someone the ability to manufacture credentials for sites they do not own. The attacker is borrowing the authority of an issuer the browser already accepts. Mozilla described interception as a possible use of these compromised keys. ^[4]

A forged certificate alone does not deliver someone's traffic to an attacker. The attacker must also get between the user and the website. If that succeeds and the client accepts the certificate, the attacker could impersonate the site and potentially read or alter the connection. ^[1][4]

Chrome said no TLS certificates chaining to the six affected intermediates appeared in Certificate Transparency logs before its block. Those public logs record certificate issuance, and Chrome requires that logging. It said a fraudulent certificate from these intermediates therefore could not have been trusted by default in Chrome or other browsers enforcing that requirement.

Ars Technica reported no known malicious use. ^[1][6]

That finding does not establish whether someone used the keys against software outside those protections. Who else obtained them, how the weak keys were generated and the full reach of the incident remain under investigation. ^[4][5][6]

The affected certificates came from a batch of 24 intermediates created on April 30, 2025, according to Mozilla's incident record. The weak keys were the P-384 keys, a type of cryptographic key used for certificates, in the batch's B and C series. The six website intermediates covered domain, organization and extended-validation certificates. ^[5]

Browsers blocked the keys before revocation

Chrome received the alert at 18:05 UTC on October 17, verified it and blocked the six website intermediate keys by 19:45 UTC. Mozilla received the report at 20:06 UTC and completed its Firefox block by 22:59 UTC. Neither protection required users to restart or update their browsers. ^[4][6]

Mozilla said eMudhra marked all eight certificates revoked for certificate-authority compromise on October 18, with individual revocation times between 09:24 and 09:38 UTC. The browsers had already acted the previous evening. ^[5]

Revocation is the issuer's formal withdrawal of a certificate. A browser's own block gives it another way to reject the credential, without relying solely on the issuer's revocation mechanism.

According to Wayne's account in Mozilla's incident record, eMudhra acknowledged his report and said the G3B intermediates had issued only certificates used for checking revocation status. He said the company told him that one G3C website intermediate had been live and was then disabled.

That is the researcher's account of the company's response. Ars Technica said eMudhra representatives were not immediately available. ^[1][5]

There is another route through the trust chain to consider. The same public keys appear in certificates signed by Sectigo, a different certificate authority. Wayne said those cross-signed certificates remained unrevoked when he commented. Chrome said its block identifies the public keys themselves, so it also covers certificates using those keys under another signature. ^[5][6]

The harder repair is outside the browser

Mozilla released Firefox updates on October 20 to carry the block to users whose settings prevent the normal automatic block-list update. It also released NSS 3.131.1, an update to its security software that removes the root which signed the affected intermediates. That change can reach other applications using Mozilla's trust list. ^[2][4]

Go, Python's certifi certificate bundle and Rust's webpki-roots package also had fixes available on October 20, according to The Hacker News. Node.js and Composer changes were still pending at that point. Programs using Go must be rebuilt with a patched release to receive its fix. ^[2]

That makes the remaining work an operator-by-operator repair. Applications may carry their own certificate bundles, and older or embedded devices can be difficult to update. A browser block does not automatically change what those programs trust. ^[1][2]

Mozilla advised operators to block the affected intermediates where possible. Where software cannot do that, it said operators should consider removing trust in the roots that signed them. The cost is possible disruption to legitimate websites whose certificates also lead to those roots. ^[6]

Chrome said its check of other certificate-authority certificates within its root-store trust boundary found no other instances of this failure. Mozilla said it did not then believe other certificate authorities were affected. ^[6]

Mozilla is working with eMudhra, other browser trust programs and trust-store operators to establish the cause. Chrome has also set out planned action against eMudhra's upstream root and a review of its remaining certificate in the Chrome Root Store. Those decisions, alongside updates for software beyond browsers, are the next steps in containing the failure. ^[4][6]