A certificate authority trusted by every major browser was found issuing intermediate certificates whose private keys were effectively guessable. The certificates are now blocked, but the cleanup reaches further than the browser address bar.
What happened
On 17 October a researcher reported to the Chrome Root Program that the private keys behind eight eMudhra subordinate CA certificates had been generated with insufficient randomness. The keys were nominally P-384 but held values small enough that testing a few hundred numbers recovered them. One published key was literally the number 4.
Chrome corroborated the report within 100 minutes and pushed a CRLSet update blocking the affected keys by their public key hashes, so desktop users were protected without restarting. Android and Chromebooks received the equivalent update through Google Play Services on 19 October, and Apple added its block the same day. Mozilla blocked the certificates through OneCRL on 17 October and shipped Firefox 158.0.1 on 20 October for users whose configuration blocked the remote update.
Two limits matter. Google states that no TLS certificates chaining to the six TLS-issuing intermediates had been logged to Certificate Transparency before the block, so CT-enforcing clients were never exposed to a usable forged certificate. And eMudhra says most of the affected intermediates were never used in production, with no evidence of abuse found so far.
The Go project shipped 1.27.3 and 1.26.10 to reject the certificates in its own verifier, tracked as CVE-2026-111943, because some systems rely on a local trust store that does not receive browser revocation data.
Who is affected
The direct victims are sites holding TLS certificates that chain to emSign ECC Root CA - G3, which Chrome is removing from its root store from 27 October. The wider group is anyone running software that carries its own certificate store.
- Website and mail operators whose certificates were issued under the eMudhra G3 root, including cross-signed chains
- Go applications built with versions older than 1.27.3 or 1.26.10
- Appliances, embedded devices, Java services and API gateways that ship a fixed CA bundle and never refresh it
- Any client that does not check revocation and therefore still trusts the blocked intermediates
What to do now
Check the issuing chain on every public certificate you own, and reissue anything that traces back to emSign ECC Root CA - G3 before 27 October. The immediate risk for most organisations is an outage, not a forgery.
- Run the chain check on web, mail, VPN and API endpoints - look at the intermediate and root, not just the common name
- Rebuild Go binaries with 1.27.3 or 1.26.10, and rebuild container images rather than patching running ones
- Ask vendors of any appliance with a fixed CA bundle when their trust store was last refreshed
- Confirm your endpoints are receiving browser revocation updates; Firefox 158.0.1 or later and a recent Chrome build are the safe baseline
What this means for South African businesses
Few local organisations buy certificates from an Indian CA directly, so the forgery angle is mostly academic here - the practical fallout is a certificate that stops validating after the root is pulled. Plenty of South African shops run Go-built services, API gateways and appliances with pinned trust stores, and those are exactly the places where a removed root surfaces at 07:00 on a Monday.
The lesson worth keeping is that trust in a certificate is only as good as the key generation behind it, and that is invisible from the outside until someone publishes a cracked key.
Source: Google Chrome and Android security teams, 20 October 2026.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.