- The chain of CA, root and intermediate behind the padlock
- What "the key was weak" means
- Two ways browsers stop trusting a CA
- What individuals and site owners should check
The short answer
On October 17, 2026 (UTC), a security researcher reported that the private keys of intermediate CA certificates from the certificate authority eMudhra (emSign) had been generated without enough randomness, and could be recovered. Anyone holding those keys could have forged HTTPS certificates that browsers would trust. Google blocked these intermediates in Chrome the same day, and extended the same protection to Android on October 19. Individuals have little to do. If you run a website, take a minute to check who issued your certificate.
The chain of trust behind the padlock
- Built into browsers and operating systems
- No longer trusted once removed from the list
- An authority approved by the root
- Here the key was weak, so browsers blocked it
- Issued by the intermediate
- Follow the chain to check the issuer
The chain of trust behind the padlock
When you open an HTTPS site, the server presents a certificate saying it controls that domain. Certificates are issued by certificate authorities (CAs). Your browser does not remember every site's certificate. What it keeps is a list of top-level certificates from CAs it trusts, called root certificates.
Site certificates are usually issued not by the root itself but by an intermediate CA the root has approved. The browser follows the chain from the site certificate to the intermediate to the root, and trusts it if the root is on its list. Think of the root as head office, the intermediate as a branch, and the site certificate as an ID card the branch issued. If someone gets hold of the branch's official stamp, they can produce ID cards nobody can tell from the real thing.
The padlock only tells you the connection is encrypted and the certificate checked out. It says nothing about whether the operator can be trusted. Our article on what HTTPS does not protect covers this in more detail.
What "the key was weak" means
A CA signs certificates with a private key. That key is supposed to be generated from plenty of unpredictable random data. In this case there was not enough randomness, so the key could be worked out from the outside. Picture a PIN that was not chosen freely but picked from a short list: try each candidate in turn and you will hit it.
With the key in hand, someone could issue a certificate for any domain in that intermediate's name, so a fake site could show the same padlock as the real one. According to Google, no certificates chaining to these CAs had been recorded in Certificate Transparency (CT) logs before the block. That means forged certificates could not have been used against clients that require CT, such as Chrome.
Two ways a browser stops trusting a CA
There are two main levers.
| Method | What it does | What happened here |
|---|---|---|
| Add to a block list | Tells clients not to accept specific intermediate certificates | Chrome pushed a CRLSet update on October 17; no browser update or restart needed |
| Remove the root | Withdraws trust from the whole hierarchy | Chrome removes "emSign ECC Root CA - G3" from the Chrome Root Store; Google said this would ship Tuesday morning, October 27, Pacific time |
The first works quickly, but only on clients that receive the block list. The second covers clients that rely on the Chrome Root Store without taking those list updates. The trade-off is that legitimate certificates chaining to that root will also stop working in Chrome.
Android devices and Googlebooks received an equivalent block through Google Play services on October 19 (UTC). Google says most devices already have it, and restarting a device applies it right away.
What individuals should do
If you use Chrome, you were protected automatically this time. Bigger changes such as removing a root still arrive through new versions and updates, so the best preparation for incidents like this is simply not to hold off on browser and OS updates.
Checklist
- Chrome is on the latest version (see "About Chrome" in Settings)
- If your Android phone has not been restarted for a while, restart it once
- You are not doing important logins or payments on an old device that no longer gets updates
What site owners should check
Google asks operators whose certificates chain to this root to get a new certificate from a different CA hierarchy in the Chrome Root Store and install it right away. Google said the root removal would ship on October 27 (US Pacific Time), with pre-release Chrome channels getting it earlier. As of November 7, Google's announcement carries no note confirming the rollout finished, but the scheduled date has passed. If your certificate still chains to this root, your site may already fail to open in Chrome.
On November 4, Google added an update about a different root, "emSign Root CA - G1": certificates chaining to it whose earliest SCT (the timestamp from a Certificate Transparency log) is after November 16, 2026 (UTC) will no longer be trusted by default in Chrome 153 and later. If your certificate hierarchy shows the emSign name, G3 or G1, talk to your issuer soon. According to Google, eMudhra has committed to helping affected customers move.
To check, open your site in a browser, click the icon on the left of the address bar, open the certificate details, and look at the hierarchy or certification path. It lists the root, the intermediate and your site's certificate from top to bottom. If you see "emSign" anywhere in it, contact whoever issued your certificate, or the agency that built your site, straight away.
Software other than browsers does not get the browser's protection. Mobile apps, internal systems, servers calling external APIs, printers and older devices each decide trust from their own certificate list.
For example, the Python releases of October 21 bundle an updated pip that includes a new certifi certificate list addressing this incident, and Python advises upgrading pip in existing virtual environments as well. Node.js updated its built-in certificate list in its security release the same day. Software that carries its own list keeps the old trust until it is updated. For the software and devices your business uses, the reliable answer comes from the developer or vendor, so ask them.
Checklist
- Your site's certificate hierarchy does not include "emSign"
- Your apps and servers run Python, Node.js and similar on versions with the updated certificate list
- You have asked vendors of hard-to-update equipment, such as printers and work terminals, about this
Summary
- Trust in the padlock is a chain: root, intermediate CA, site certificate.
- This time an intermediate CA's keys were weak enough to forge certificates, but Chrome blocked them the same day and Android followed.
- Browsers withdraw trust in two steps: a block list, then removing the root.
- Non-browser software and older devices may not be protected automatically.
One thing to check today
Open your website and check whether "emSign" appears in its certificate hierarchy. If it does, contact your certificate issuer or the agency that built the site.