Key takeaways
- The private keys of eight eMudhra intermediate CA certificates were generated with too little randomness, so they can be computed from the public certificates. Six are TLS intermediates (DV, OV, EV), two are code-signing intermediates (The Hacker News, CERT-In CIAD-2026-0050).
- Browsers have already blocked the bad intermediates. Chrome and Firefox did it on 17 October (UTC) within hours of the report; Apple and Android followed on 19 October and Microsoft on 20 October.
- The bigger change for site owners: Chrome removes the
emSign ECC Root CA - G3root from its root store, expected to reach devices on 27 October 2026. Any certificate chaining to that root will stop working in Chrome, even if it was never touched by the weak keys. Mozilla has already removed it from NSS. - eMudhra says none of the eight intermediates issued end-entity certificates, only one was in production, and its Indian digital signature (DSC) and eSign businesses are separate and unaffected (eMudhra statement).
- Most Indian sites are not affected — they use Let's Encrypt, Sectigo, DigiCert, GlobalSign or Google Trust Services. But you should confirm in two minutes, and developers must update Go binaries and CA bundles.
1. What happened, in plain terms
A certificate authority (CA) signs the TLS certificates that make the padlock appear. It does this with a private key that must never leak. eMudhra, an Indian CA, has explained that a flaw in its 30 April 2025 key ceremony produced a second, weak set of keys, and that weak set is the one that ended up in browser root stores. CERT-In's advisory says the P-384 keys had very small values, which makes them quickly recoverable.
A researcher reported the problem to the browser root programs on 17 October. Mozilla independently recovered the keys within about two hours, which confirmed the issue was real and not theoretical (Mozilla blog, Bugzilla 2083449).
Why it matters: anyone with those keys could, in principle, mint a certificate for any domain — your bank, your company's login page — or sign malware that looks like it came from a trusted publisher. There is no public evidence of misuse so far, and nobody can fully rule it out either, because unlogged certificates would not show up in Certificate Transparency (CT) searches.
2. Who did what, and when
| Date (2026, UTC) | Action |
|---|---|
| 17 Oct | Report to root programs. Chrome pushes a CRLSet block of the six TLS intermediates; Firefox blocks them via OneCRL |
| 19 Oct | Apple blocks the certificates; Android gets a block through Google Play Services |
| 20 Oct | Microsoft blocks; Mozilla removes emSign ECC Root CA - G3 from NSS; Go 1.27.3 and 1.26.10 released (CVE-2026-111943); Firefox 158.0.1 and ESR updates ship |
| 21 Oct | eMudhra press release on the cause; Node.js fixes; CERT-In advisory CIAD-2026-0050; Red Hat bulletin RHSB-2026-012 |
| 27 Oct (Pacific) | Chrome Root Store version 43 removes emSign ECC Root CA - G3; Canary and Beta get it earlier |
Timeline as compiled by The Hacker News from vendor posts; Chrome's own write-up is on the Google blog. Chrome is also reported to be reviewing eMudhra's other root, emSign Root CA - G1, so watch that space.
The affected intermediates are EM DV TLS CA - G3B/G3C, EM OV TLS CA - G3B/G3C, EM EV TLS CA - G3B/G3C and EM OV CS CA - G3B/G3C (code signing). The TLS ones chain to emSign ECC Root CA - G3, and each also exists as a Sectigo cross-signed copy under AAA Certificate Services. A machine-readable list is maintained here.
3. Check your own sites in two minutes
You only need to act if your certificate chain mentions emSign or an EM … TLS CA intermediate. Run this for each public hostname:
openssl s_client -connect example.in:443 -servername example.in -showcerts </dev/null 2>/dev/null \
| grep -E "^ *(s|i):"
Look at the i: (issuer) lines. If you see emSign or EM DV/OV/EV TLS CA, you are affected. If you see R10/R11/E5/E6 (Let's Encrypt), Sectigo, DigiCert, GlobalSign or GTS, you are not.
To keep an eye on certificate expiry across sites after you swap, use our uptime and SSL checker.
Bulk check: if you manage dozens of client domains, loop the command over a list and grep -il emsign the output. Also search CT logs (crt.sh or Censys) for your domains to see whether any certificate you did not request has been issued — CERT-In explicitly recommends this monitoring.
4. If you are affected: replace before 27 October
| Situation | What to do | Effort |
|---|---|---|
| Public website with an emSign ECC G3 chain | Get a certificate from another hierarchy and install it before 27 Oct. eMudhra says it will move these customers; a free DV cert from Let's Encrypt is the fastest stopgap | 30–60 min per site |
| OV/EV cert required by a bank, PSU tender or client policy | Ask eMudhra for a reissue on a different root, or buy from another CA; keep the old cert only until the new one is live | 1–3 days (validation) |
| Internal apps, APIs or mTLS using emSign chains | Same replacement; also update client trust stores so they don't fail on the root removal | Varies |
Software signed with the EM OV CS CA intermediates |
Re-sign with a certificate from a different issuer; Chrome's TLS verifier doesn't use code-signing intermediates, but Windows and other OS trust decisions may differ | 1 day+ |
Do the swap on a weekday morning, test with openssl s_client and a real Chrome browser, and only then remove the old certificate. Do not wait for 27 October itself — root store updates can land earlier on some channels.
5. Developers and DevOps: update your trust stores
Browsers update themselves. Your servers, containers and binaries often do not.
- Go: rebuild and redeploy with Go 1.27.3 or 1.26.10. Go embeds the block in
crypto/x509, so an old binary keeps trusting the bad keys (Go issue 82345). - Node.js: upgrade to the patched release from 21 October; Node ships its own CA list.
- Python / Rust: update
certifiandwebpki-rootsand rebuild images that pin them. - Linux servers: update
ca-certificates/NSS packages when your distro ships them. Red Hat's interim workaround for RHEL 7 and later removes the affected roots from the system trust store; packages were not yet out as of 21 October. - Containers: rebuild base images; a
FROMimage from last month still carries the old bundle. - Behind Cloudflare? If you run your own origin trust store, mTLS or containers, Cloudflare advises updating those too (Cloudflare blog).
One caution from Mozilla, Canonical and Red Hat: removing a whole root also breaks legitimate certificates under it. That is intentional, but it means you should inventory before you patch, so a payment gateway or partner API that happens to use an emSign chain doesn't surprise you in production.
6. The India angle
eMudhra is one of India's best-known licensed CAs, and many Indian businesses use its DSC tokens for GST, MCA and income-tax filings. eMudhra says its DSC and eSign businesses are separate from the affected TLS hierarchy, and officials are reported to agree, so your DSC token for filings is not affected by this browser-trust issue. India's IT ministry has reportedly formed a team to investigate.
What this incident should change for Indian IT teams:
- Keep a certificate inventory. Know which CA, root and expiry each domain uses. A spreadsheet is fine; a monitoring tool is better.
- Prefer automated certificates (ACME, 90-day or shorter) for public sites. CA-side incidents then become a renewal, not a project.
- Don't let procurement pick a CA on price alone. A single root decision now forces every customer under it to migrate in ten days.
Bottom line
Run the openssl check on your domains today. If an emSign chain shows up, replace that certificate before 27 October. Then rebuild Go services, refresh CA bundles in your containers, and add CT-log monitoring for your domains. For everyone else, keep browsers and operating systems updated — that already covers the weak intermediates.
Need help auditing certificates across many domains or setting up CT-log and expiry alerts? See our incident monitoring service, or generate a fresh CSR with our SSL CSR generator.