Go Emergency Update Blocks Eight Certificate Authority Keys

A single update keeps your software connecting only to certificate authorities it can still trust. On October 20, the Go team released Go 1.27.3 and Go 1.26.10, a Go emergency update that makes the language’s certificate verifier reject any certificate chain passing through one of 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, and the Go team recommends upgrading immediately.

What happened

According to the Go team’s announcement, Go 1.27.3 and Go 1.26.10, both released on October 20, make the certificate verifier reject any chain that passes through one of eight intermediate certificate authority keys because of "specific security concerns around their operation." The team has not named the certificate authority, handled the fix on its URGENT track reserved for its most serious issues, and recommends upgrading right away. 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. You can get the fixed builds from Go’s official download page.

Are you affected?

Any program your business runs that is built with Go and that verifies certificate chains is in scope, and so is any site or service whose certificate chains through one of the eight keys. The filter runs whenever a Go program verifies a chain. It hashes each certificate’s public key rather than the certificate itself, so a cross-signed copy of one of the keys, the same key signed by a different root, is caught too. It applies in Go’s own verifier and in the macOS and Windows code paths that hand verification to the operating system. A rejected chain returns the error x509: no valid chains built, which is the signal to watch for.

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 issued under the same emSign Root TLS CA – G3 that Mozilla’s entries name, and two are code-signing intermediates under emSign Root CS CA – G3:

• 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 change contains no setting to turn the filter off. Given the structure of the code, it also applies when a program supplies its own set of 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. Whether Chrome, Apple, or Microsoft have taken similar action is not established.

What to do now

1. Upgrade Go programs to Go 1.27.3 or Go 1.26.10 from Go’s official download page, then rebuild and redeploy them. Programs keep the old behavior until they are rebuilt.
2. If you are on Go 1.25 or older, move to a supported release. Those versions are out of support and get no fix.
3. Watch your logs and connection errors for x509: no valid chains built, which indicates a chain was blocked by the new filter.
4. If you operate sites or services whose certificates chain through one of the eight keys, obtain certificates from a different intermediate. Rebuilt Go clients cannot connect to them otherwise.
5. Do not plan around a toggle or temporary workaround. No source describes one, and the filter cannot be disabled.

Background on the certificate authority

eMudhra is an Indian certificate authority that sells certificates under the emSign brand. Its roots emSign Root CA – G1 and emSign ECC Root CA – G3 are in the Chrome, Apple, and Mozilla root stores. The company 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 the root programs run by browser and operating-system makers, including emSign Root TLS CA – G3, closed with no objections.

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, and says there are no recent examples. Go has not said which of those applied. On the issue, one user asked for the committed patch to explain who and what the keys correspond to, and the Go team had not replied as of October 20. Projects including Bluesky’s indigo were rebuilt on the new releases on October 20.

Go’s verifier does no revocation checking, as its documentation warns, and it does not read the block lists browsers use. Blocking a key therefore means shipping it in a release. Certificates logged for eMudhra’s own domains, including emsign.com and emudhra.com, chain through other eMudhra intermediates, according to certificate transparency records checked on October 20. As of that day, eMudhra’s repository contained no notice about the intermediates, and no public statement from the company had appeared.

FAQ

Which Go versions fix the blocked keys?

Go 1.27.3 and Go 1.26.10, both released on October 20, carry the fix. Go 1.25 and older releases are out of support and receive no fix, so the only route is a supported release from Go’s download page.

Can the new certificate filter be turned off?

No. The change contains no setting to disable the filter, and no source describes a temporary workaround. Because of how the code is structured, the filter also applies when a program supplies its own trusted roots.

Why did Go block the eight keys?

The Go team says the eight keys belong to one certificate authority it has not named and that it blocked them because of "specific security concerns around their operation." It used its URGENT track, reserved for its most serious issues, and has not said what specifically prompted the action.