Eight website-certificate keys were tiny. Browsers blocked them

On October 17, 2026, browser makers were told that the private keys for eight eMudhra intermediate certificates could be recovered by anyone. The keys were not stolen from a safe. They were generated as tiny numbers. Chrome and Firefox blocked them the same day, without asking you to install an update.

If you use Chrome or Firefox and you have not turned off their usual security updates, you do not have a setting to flip. The part that still matters is older software that never hears about a revocation, and websites whose certificate still chains to the root Google is about to stop trusting.

What was wrong with the keys

An intermediate certificate authority is an organization the root trusts to issue website certificates. Whoever holds that intermediate’s private key can mint a certificate for a site they do not own. A browser that still trusts the intermediate will accept it.

Chrome’s security post says the Chrome Root Program received the report at 18:05 UTC on October 17. The keys had been generated with too little randomness, so anyone could forge trusted HTTPS certificates for clients that had not yet dropped those authorities.

Mozilla’s incident bug, 2083449, records the same report and the check Mozilla did itself. Dennis Jackson wrote that the eight keys were created on April 30, 2025, as part of a batch of 24 intermediates. They are the P-384 keys from two of the three series in that batch. A P-384 private key is supposed to be a random integer across an enormous range. These eight were all smaller than 256. They are zeros except for the last byte. Mozilla recovered them on its own, without the reporter’s method, which is what makes this a broken generator rather than a one-off leak. Jackson wrote that he had not recovered the other P-384 series, and that he had not yet looked at the RSA keys from the same ceremony.

Six of the eight are TLS intermediates, trusted by the Chrome, Mozilla, Microsoft, and Apple root programs. Two are for code signing and were trusted by Microsoft. eMudhra’s statement says the incident does not affect its root private keys or its other intermediates, that only one of the eight was deployed in production, and that none of them, including that one, had issued an end-entity certificate. Google says no TLS certificate chaining to the six TLS intermediates was in Certificate Transparency logs before the block. A browser that requires those logs, which Chrome does by default, could not have been shown a fraudulent certificate from these authorities before the block. Clients that do not check Certificate Transparency are a different population. Google says it does not know of fraudulent use against them, and the absence of a log entry is not a search of every network.

What browsers did

At 19:45 UTC on October 17, Chrome pushed a CRLSet update that blocks the affected keys by their public-key hash. Chrome says that covers every certificate sharing those keys, and that it does not require a browser update or a restart. Android received an equivalent update through Google Play Services around 22:00 UTC on Monday. Google says most devices already have it, and that a restart pulls it immediately.

Mozilla received the report at 20:06 UTC, acknowledged it at 20:08, and finished pushing the block to Firefox through OneCRL at 22:59 UTC the same day. Mozilla’s post says that reaches Firefox users on the standard configuration without an update or a restart. Firefox 158.0.1, ESR 115.43.1, and ESR 153.5.1 carry the same block for people whose settings do not take OneCRL updates. Mozilla is also removing the root that signed these intermediates from NSS 3.131.1, for other software that uses Mozilla’s trust store and never sees OneCRL.

eMudhra revoked the eight intermediates on October 18. Revocation only helps software that bothers to look it up.

Google is removing the root those intermediates chain to, emSign ECC Root CA – G3, from the Chrome Root Store. That change is scheduled for Tuesday morning, October 27, 2026, Pacific time, and sooner on Chrome Canary and Beta. Google says some legitimate certificates that chain to this root will stop working in Chrome, and that eMudhra has committed to moving those subscribers. Chrome is also still deciding whether eMudhra’s remaining roots stay in the store.

What to do

1. Leave Chrome and Firefox on their default update settings. The block is already a list they fetch. Turning off “security updates” or Safe Browsing-style components is how you opt out of the thing that fixed this.
2. Restart an Android phone if you want the Play Services update now rather than whenever it arrives. Google’s instruction is a restart, not a new setting.
3. If you run a website, check who issued the certificate. If it chains to emSign ECC Root CA – G3, replace it with a certificate from a hierarchy still in the Chrome Root Store before October 27. After that, Chrome visitors can get a full-page warning on an otherwise honest site.
4. Anything that pins trust and does not take a browser revocation list is still your problem. Old phones, appliances, and libraries that shipped with this root and never update will keep trusting a key that is public. There is no setting on your laptop that fixes those.

You do not need to change your passwords because of this. A forged certificate is a way to sit in the middle of a connection, not a dump of a company’s customer database.

Sources

• Chrome Root Program, Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, October 20, 2026
• Mozilla, Protecting Firefox users following the compromise of eMudhra intermediate certificates, October 20, 2026
• Mozilla Bugzilla, 2083449: eMudhra private key compromise of intermediate certificates
• eMudhra, Statement on the certificate security incident