On October 17, 2026, a researcher reported that the private keys of eight eMudhra intermediate certificate authorities could be recovered, because the keys had been generated with too little randomness. With those keys, anyone could have signed HTTPS certificates for any website. Chrome, Firefox and Android blocked the affected certificates within hours, and Google says no forged certificate from them could have been accepted by Chrome. Most people only need to keep their browser updated. Website owners whose certificate comes from eMudhra's emSign ECC Root CA – G3 have until October 27 to replace it before Chrome stops trusting it. On October 22, eMudhra said it will leave the global SSL/TLS certificate business altogether.
You can check which authority issued any site's certificate in a few seconds with the SSL Certificate Checker: enter the hostname and read the Issuer field.
What happened
A certificate authority (CA) vouches for websites by signing their certificates. Browsers trust a short list of root CAs, and roots usually delegate day-to-day signing to intermediate CAs. If an intermediate's private key leaks, whoever holds it can issue certificates that browsers accept as genuine. Our guide to X.509 certificates explains how the chain works.
According to Google's Chrome and Android security post, published October 20, the Chrome Root Program received a researcher's report on October 17 that the private keys of eight eMudhra subordinate CAs were exposed. The cause was the key generation process: the keys lacked enough randomness, so they could be worked out rather than stolen. Mozilla says in its incident bug that its own team recovered the keys independently, which confirmed the flaw.
The eight certificates split into two groups, as described in the Mozilla dev-security-policy thread:
| Certificates | Used for | Trusted by |
|---|---|---|
| 6 intermediates | TLS (HTTPS websites) | Chrome, Mozilla, Microsoft and Apple root programs |
| 2 intermediates | Code signing | Microsoft |
How browsers blocked the certificates
Browsers have emergency mechanisms that block a certificate without waiting for a full software release:
- Chrome pushed a CRLSet update that blocks the affected intermediates by the hash of their public keys. Google says this takes effect without restarting or updating the browser. Because the block is by key, it also covers any other certificate that reuses the same key.
- Android received the equivalent protection through Google Play Services. Google says most devices already have it, and restarting the device triggers the update right away.
- Firefox blocked the certificates through OneCRL, Mozilla's revocation list, the same day. Mozilla's security blog also lists Firefox 158.0.1 and ESR releases for users whose settings could block OneCRL updates, and its incident bug notes a Firefox for Android 158.0.2 fix that followed on October 21.
These mechanisms protect the browsers that use them. Other software that ships its own list of trusted roots, such as some command-line tools, programming language runtimes and embedded devices, does not receive CRLSet or OneCRL, so it relies on its vendor's next trust store update.
Could anyone have been attacked?
Google says no. Chrome only accepts a public TLS certificate if it was logged to Certificate Transparency (CT), the public, append-only record of issued certificates. Google reports that no TLS certificate chaining to these CAs had been logged before the block, so no fraudulent certificate from them could have been used against Chrome or other CT-enforcing clients. Google also had CT logs updated to reject new certificates that chain to these CAs.
That is a strong answer for modern browsers, and the reason CT exists: a forged certificate cannot stay hidden if browsers demand that it be published first. Clients that do not check CT get no such guarantee, which is why the blocks above matter.
What changes on October 27
Google went further than blocking the leaked intermediates. It removed emSign ECC Root CA – G3, the root that signed them, from the Chrome Root Store. Google expects the removal to reach all devices that rely on the Chrome Root Store on the morning of Tuesday, October 27, 2026 (Pacific time).
After that, Chrome will reject every certificate that chains to that root, including legitimate ones. Google says website operators with certificates under it should get a new TLS certificate from a different hierarchy in the Chrome Root Store now, and that eMudhra has committed to helping affected customers move. Google also says it is still evaluating eMudhra's other CA certificates and will share updates publicly.
eMudhra is leaving the TLS certificate business
On October 22, eMudhra announced that its board had decided to exit the global SSL/TLS certificate business. In its statement the company says:
- It will provide replacement certificates to affected customers free of charge, through partner certificate authorities.
- Its certificate status and revocation services keep running until the existing certificates expire or are replaced.
- The TLS business is about 1 percent of its global revenue, and its other businesses, such as digital signatures, identity management and enterprise PKI, are not affected.
- Besides the incident, it cites rising compliance costs and competition from free certificates.
The announcement does not change the deadline. If your site's certificate chains to emSign ECC Root CA – G3, you still need a replacement installed before Chrome stops trusting that root on October 27. Ask eMudhra or your reseller which partner issues the free replacement, or buy one from any other certificate authority in the Chrome Root Store.
What to do
If you just browse the web:
- Keep Chrome, Firefox and Edge updated, and restart the browser if it asks.
- On Android, restart your phone to pick up the Google Play Services fix immediately.
- Nothing else is needed. You do not have to remove certificates by hand.
If you run a website:
- Open the SSL Certificate Checker, enter your hostname and look at the Issuer field. If it names eMudhra or emSign, check which root your chain goes back to with your certificate provider or in your server's chain file.
- If your certificate chains to emSign ECC Root CA – G3, order a replacement from another CA before October 27 and install it with its full intermediate chain.
- After you install the new certificate, run the checker again to confirm the new issuer and the Valid to date.
- To read every field of a certificate file, paste it into the Certificate Decoder. It parses RSA certificates; ECDSA certificates, which this root issues, return an error there, so rely on the Issuer field and your provider for those.
If you maintain software or devices that use their own trust store: update the CA bundle as soon as your operating system or runtime vendor ships one without the affected certificates, and check that your clients enforce revocation where they can.
Why weak randomness breaks a key
A private key is a very large secret number. Its security depends entirely on being impossible to guess, which is why keys are generated from a cryptographically secure random source. If the generator draws from too small a range, an attacker does not need to break the math; they only need to try the possible values until one produces the matching public key. Our explainer on public key cryptography covers why the private half must stay unpredictable.
This incident is a reminder that the weakest link is often the process around the cryptography, not the algorithm. For everyday secrets, the same rule applies: a Password Generator that draws from a secure random source makes passwords that cannot be guessed by enumeration.
Common questions
Is eMudhra still selling SSL certificates? It is winding that business down. On October 22, 2026, it announced it will exit the global SSL/TLS certificate business and replace affected customers' certificates free of charge through partners; its statement gives no end date for existing sales.
Do I need to do anything as a regular user? No action beyond keeping your browser and phone updated. Chrome, Firefox and Android already block the compromised certificates.
Was any website impersonated? Google says no fraudulent certificate from these CAs could have been trusted by Chrome or other browsers that enforce Certificate Transparency, because none had been logged before the block.
What is emSign ECC Root CA – G3? It is the eMudhra root certificate that signed the compromised intermediates. Google removed it from the Chrome Root Store, effective for devices on October 27, 2026.
How do I see who issued a website's certificate? Enter the hostname in the SSL Certificate Checker, or click the icon next to the address in your browser and open the certificate details. The Issuer field names the CA.
What does CA key compromise mean? It means someone other than the certificate authority can use its private signing key, so they could issue certificates that browsers would trust. The fix is to block the affected certificates and, when needed, distrust the root above them.