"specific security concerns around their operation," the Go team wrote — and on October 20 the language became code.
Go releases Go 1.27.3 and Go 1.26.10 that refuse eight intermediate CA keys
On October 20 the Go project shipped Go 1.27.3 and Go 1.26.10. Both releases change Go's certificate verifier so it rejects any certificate chain that passes through one of eight intermediate certificate authority keys. The Go team handled the fix on its URGENT track — the channel it reserves for the most serious issues — and recommends immediate upgrades.
Which keys are blocked: six TLS intermediates and two code‑signing intermediates
Go published only the SHA‑256 hashes of the eight keys it is blocking. A commenter on the Go issue matched all eight hashes to intermediates issued by eMudhra under its emSign program by looking the hashes up in certificate records. By that matching, the eight affected intermediates are:
- TLS, domain validated: EM DV TLS CA - G3B (eMudhra BV, Netherlands) and EM DV TLS CA - G3C (eMudhra Inc, U.S.)
- TLS, organization validated: EM OV TLS CA - G3B and EM OV TLS CA - G3C
- TLS, extended validation: EM EV TLS CA - G3B and EM EV TLS CA - G3C
- Code signing: EM OV CS CA - G3B and EM OV CS CA - G3C
The Hacker News has not independently checked the hashes against the certificates. Mozilla added six intermediate certificates issued by eMudhra's emSign Root TLS CA - G3 to OneCRL (Firefox's block list) on October 17; Mozilla's six entries list the issuing root but do not name the six certificates themselves.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogHow the block works inside Go and why it breaks connections
Go's filter runs whenever a Go program verifies a certificate chain. Rather than hashing the certificate bytes, Go hashes each certificate's public key; that means a cross‑signed copy of one of the eight keys — the same public key signed by a different root — will be caught as well. A rejected chain yields the error "x509: no valid chains built."
The block is present in Go's own verifier and also in the macOS and Windows code paths that hand verification to the operating system. The change contains no setting to turn the filter off, and by design it also applies when a program supplies its own set of trusted roots; a private deployment that intentionally trusts one of the eight keys will fail too. Go has not said whether that coverage is intended.
Two operational constraints make this a shipping‑time decision rather than a live block list. Go's verifier "doesn't do any revocation checking," its documentation warns, and it does not read the block lists browsers use (the article cites CRLSets Chrome used "this month" as an example). Blocking a key therefore requires shipping the block in a release, and programs keep the old behavior until they are rebuilt. Projects including Bluesky's indigo rebuilt on the new releases on October 20.
Mozilla, eMudhra, and the public record
Mozilla placed six eMudhra intermediates on OneCRL on October 17; the Mozilla bug behind those entries is closed to the public. Neither Mozilla nor Go has said what prompted their actions, and whether Chrome, Apple, or Microsoft have taken similar steps is not established.
eMudhra is named in the public record as an Indian certificate authority that sells certificates under the emSign brand. Two of its roots — emSign Root CA - G1 and emSign ECC Root CA - G3 — are present in the Chrome, Apple, and Mozilla root stores. According to the public record cited, eMudhra told Mozilla earlier this year that its newer TLS root is cross‑signed by emSign Root CA - G1, which is how certificates under the newer root chain to a trusted root.
In September a six‑week public discussion of eMudhra's request to add ten new roots to browser and operating‑system root programs (including emSign Root TLS CA - G3) closed with no objections. Certificate Transparency records checked on October 20 show certificates logged for eMudhra domains chain through other eMudhra intermediates. The company's repository contained no notice about the intermediates and The Hacker News found no public statement from eMudhra as of October 20.
What this means for technologists, enterprises, and end users
- Technologists and security teams: Rebuild Go binaries on a supported release (Go 1.25 and older are out of support and receive no fixes). There is no temporary workaround in any source and the filter cannot be disabled; services using the affected intermediates will fail until servers present certificates chaining to different intermediates and clients are rebuilt on the patched releases.
- Affected enterprises and certificate operators: Sites and services whose certificates chain through the eight keys will need certificates from a different intermediate before rebuilt Go clients can connect to them. The change applies even in deployments that supply their own trusted roots.
- End users: Connections from Go programs will return "x509: no valid chains built" for services using affected intermediates until both server certificates and client binaries are updated.
Go described the action as driven by "specific security concerns" but has not publicly identified which of the URGENT‑track definitions — "a threat to the Go ecosystem's integrity" or active exploitation causing severe damage — applied. A commenter tied the hashes to eMudhra intermediates; Mozilla placed six emSign intermediates on OneCRL three days earlier; and eMudhra had not posted a public notice as of October 20. Those facts leave two immediate operational realities clear: administrators must replace affected certificates where possible, and Go users must rebuild on the updated releases to restore connectivity.
