Chrome Blocked the Weak eMudhra CA Keys in 100 Minutes. Your Go Binary and Python Container Did Not Get the Memo

The eight eMudhra intermediate CA keys were not stolen. They could be computed. Google’s Chrome Root Program says they were “generated with insufficient randomness,” and BleepingComputer’s report says the P-384 private keys had values below 256, so recovering one meant trying at most 256 candidates. One published key was the number 4. That second figure comes from press coverage of the researcher’s disclosure, not from Google, so treat the exact key size as reported rather than confirmed.

The part worth your time is not the CA failure. It is how differently the fix reached two kinds of client.

Push revocation versus a bundle in your image#

Per Google’s write-up, the report arrived at 18:05 UTC on 17 October and Chrome shipped a CRLSet update blocking the intermediates’ SPKI hashes at 19:45 UTC. Users needed no browser update and no restart. Firefox has the equivalent in OneCRL. Because the block is by public key hash, it covers every certificate that shares the key.

Most server-side clients have no such channel. The Hacker News summary names Go binaries and anything using Python’s certifi as examples of software that keeps trusting a chain until its code or root bundle changes. The Go fix, tracked as golang/go#82345, makes crypto/x509 Verify drop any chain containing the affected intermediates. That ships in Go 1.27.3 and 1.26.10, which means a recompile. A container built last month on a base image with an old ca-certificates package is in the same position even if the host was patched.

Google Cloud’s own guidance reads this way. Bulletin GCP-2026-071 rates it medium and says Google infrastructure was not breached. The Cloud SQL release note says no manual certificate store updates are needed for managed instances, but asks users to upgrade the Auth Proxy to 2.26.3 or later and the Proxy Operator to 1.8.4 or later. For the language connectors it asks for a new runtime and OS CA certificates, giving Go 1.26.10 or 1.27.3 and certifi 2026.10.19 as examples. The server side was fixed centrally. The client side is yours.

What the bundles did#

I wanted to see whether “update certifi” is a single well-defined step. I downloaded four releases from PyPI and compared the # Label: lines in each cacert.pem.

The first change removed all four emSign roots, the day after the report. The next release put three back and left out only emSign ECC Root CA - G3, which matches Chrome’s stated plan to remove that root and the version Google’s and others’ advisories name as the fixed certifi. Three days later a third release removed two more. I read these as maintainers reacting to a situation that kept developing, which is reasonable, but it means two services both “on a patched certifi” can disagree about whether a certificate from the same CA validates, depending on which of the three releases they picked up. I did not test live certificates against each bundle, so I am only claiming the bundles differ.

The same drift shows up at the OS level. In this build environment, an Ubuntu 24.04 container with ca-certificates 20260816ubuntu0.24.04.1, /etc/ca-certificates.conf has three emSign roots (C1, G1, ECC C3) disabled with a leading !, and there is no emSign ECC G3 file at all. That is a different set from certifi 2026.10.19 and a different one again from 2026.10.23. Ubuntu’s change is the one the Google bulletin points to as USN-8944-1.

The cost of the safe fix#

Removing a root is the blunt option and it has a price. Every legitimate certificate that chains to that root now fails. The Hacker News summary quotes Mozilla, Canonical and Red Hat warning that some servers will become unreachable until they move to other chains, and Chrome says site operators with certificates under emSign ECC Root CA - G3 must replace them with a certificate from another hierarchy in the Chrome Root Store. Chrome expects that root removal to reach devices on 27 October.

The Go and Node approach of blocking the specific intermediates is narrower, but only applies to runtimes that carry the denylist. Which one you want depends on whether you have any dependency on eMudhra-issued certificates, which is a question you can answer by looking at what your own clients connect to.

What I would check#

Forget the CVE number for a moment and ask three concrete questions about every service that makes outbound TLS calls.

1. Where does its trust come from? System store, a bundled file such as certifi or webpki-roots, or the Go toolchain’s own verifier. Each has a different update path.
2. When was that artifact last built? Compare the base image date and the lockfile pins against the dates above. A lockfile that pins certifi to a July release carries all four emSign roots.
3. Does anything you connect to chain to an eMudhra root? If yes, a root removal is an outage, not a patch.

For the last one, openssl s_client -showcerts -connect host:443 against your dependencies lists the chain. Nothing in the sources I read says the keys were used to issue a certificate: eMudhra says it found no evidence of issuance to end users, and Google says no TLS certificates chaining to the affected intermediates had been logged to Certificate Transparency before the block. The exposure is that a client with no revocation channel would accept a forged one, and it is the clients that have to be rebuilt.

Sources#

• Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, Google
• GCP-2026-071 security bulletin and Google Cloud release notes, 23 October 2026
• golang/go#82345, crypto/x509 mitigation
• Mozilla, Google, Apple block compromised eMudhra CA certificates, BleepingComputer
• Eight eMudhra CA keys compromised, The Hacker News
• certifi release history, PyPI; bundle contents compared from the downloaded wheels