Go 1.27.3 and Go 1.26.10, released October 20, make Go's certificate verifier reject any chain passing through eight intermediate certificate authority keys. Programs built on the new releases will refuse connections to sites and services whose certificates were issued under those keys. The Go team says the keys belong to one unnamed certificate authority, blocked over "specific security concerns around their operation." The fix went out on Go's URGENT track, reserved for its most serious issues, and the team recommends upgrading immediately.
Two days earlier, on October 17, Mozilla added six intermediate certificates issued by eMudhra's emSign Root TLS CA - G3 to OneCRL, the list Firefox uses to block certificates. The Mozilla bug behind those entries is closed to the public, and neither Mozilla nor Go has said what prompted the action. Whether Chrome, Apple or Microsoft have taken similar steps is not established.
Go's change lists only the SHA-256 hashes of the eight keys. A commenter on the Go issue matched all eight to eMudhra intermediates by looking the hashes up in certificate records. By that matching, six are TLS intermediates under the same emSign Root TLS CA - G3 named in Mozilla's entries, and two are code-signing intermediates under emSign Root CS CA - G3. The Hacker News has not independently checked the hashes against the certificates.
The filter runs whenever a Go program verifies a certificate chain. It hashes each certificate's public key rather than the certificate itself, so a cross-signed copy of one of the eight keys is caught too. It applies in Go's own verifier and in the macOS and Windows paths that hand verification to the operating system. A rejected chain returns the error x509: no valid chains built.
The change contains no setting to turn the filter off. Given the code's structure, it also applies when a program supplies its own trusted roots, so a private deployment that intentionally trusts one of the eight keys will fail as well. The Go team has not said whether that is intended. Go's verifier does no revocation checking and does not read browser block lists, so blocking a key means shipping it in a release, and programs keep the old behavior until rebuilt. Projects including Bluesky's indigo were rebuilt on the new releases on October 20.
What happened at the certificate authority is not public. Go's announcement gives one sentence about security concerns, and the release came without the pre-announcement Go sent before its October 8 security releases. Go's security policy defines URGENT track issues as a threat to the Go ecosystem's integrity or flaws being actively exploited with severe damage. Go has not said which applied. On the issue, one user asked for the committed patch to explain "who and what they correspond to." The Go team had not replied as of October 20.
eMudhra is an Indian certificate authority selling certificates under the emSign brand. In September, a six-week public discussion of its request to add ten new roots to browser and operating-system root programs, including emSign Root TLS CA - G3, closed with no objections. Certificates logged for eMudhra's own domains chain through other eMudhra intermediates, according to certificate transparency records The Hacker News checked on October 20. The company's repository contained no notice about the intermediates that day, and The Hacker News found no public statement from eMudhra. Go 1.25 and older releases are out of support and get no fixes. No temporary workaround exists in any source. Sites whose certificates chain through the eight keys will need certificates from a different intermediate before rebuilt Go clients can connect.
Source: The Hackers News