The **Go** programming language project has issued an urgent security update, Go 1.27.3 and Go 1.26.10, which implements a significant change to its certificate verification process. Released on October 20, these updates cause Go's certificate verifier to reject any certificate chain that passes through one of eight specific intermediate certificate authority (CA) keys. The Go team has not publicly named the CA but cited "specific security concerns around their operation" as the reason for the block. This fix was handled on Go's "URGENT track," reserved for the most serious issues, with an immediate upgrade recommendation. ### Mozilla's Parallel Action Just two days prior, on October 17, **Mozilla** added six intermediate certificates issued by **eMudhra's emSign Root TLS CA - G3** to **OneCRL**, the certificate revocation list used by **Firefox**. The bug report detailing Mozilla's action remains closed to the public, and neither Mozilla nor Go has disclosed the specific events prompting these measures. ### Identifying the Blocked Keys While Go's announcement only provided **SHA-256** hashes of the eight keys, a commenter on a Go issue tracker successfully matched all eight to eMudhra intermediates. Based on this matching, six are **TLS** intermediates issued under the same **emSign Root TLS CA - G3** that Mozilla named, and two are code-signing intermediates under **emSign Root CS CA - G3**. The identified TLS certificates include: * **EM DV TLS CA - G3B** (eMudhra BV, Netherlands) * **EM DV TLS CA - G3C** (eMudhra Inc, U.S.) * **EM OV TLS CA - G3B** * **EM OV TLS CA - G3C** * **EM EV TLS CA - G3B** * **EM EV TLS CA - G3C** Code signing certificates affected are **EM OV CS CA - G3B** and **EM OV CS CA - G3C**. ### Technical Implications The filter operates by hashing each certificate's public key, ensuring that even cross-signed copies of these keys are caught. This change applies universally within Go's verifier, including macOS and Windows code paths that delegate verification to the operating system. A rejected chain will return the error `x509: no valid chains built`. Crucially, the update provides no setting to disable this filter. This means private deployments that intentionally trust one of the eight keys will also fail. The Go team has not clarified if this behavior is intended. Go's verifier does not perform revocation checking, nor does it read browser-specific block lists like the **CRLSets** used by **Chrome**. Consequently, blocking a key requires a new release, and programs must be rebuilt to adopt the new behavior. Projects like **Bluesky's indigo** were promptly rebuilt on the new releases. ### Undisclosed Reasons and eMudhra's Status The exact nature of the security concerns remains under wraps. Go's security policy defines URGENT track issues as a "threat to the Go ecosystem's integrity" or actively exploited flaws with severe damage, but it has not specified which applied in this case. The lack of a pre-announcement, typical for Go security releases, further underscores the gravity and urgency of the situation. eMudhra, an Indian certificate authority operating under the emSign brand, has its roots (**emSign Root CA - G1** and **emSign ECC Root CA - G3**) included in the root stores of Chrome, Apple, and Mozilla. Earlier this year, eMudhra informed Mozilla that its newer TLS root is cross-signed by **emSign Root CA - G1**, maintaining its trust chain. Notably, a public discussion in September regarding eMudhra's request to add ten new roots, including **emSign Root TLS CA - G3**, to browser and OS root programs concluded without objections. As of October 20, eMudhra had not issued any public statement or notice concerning these intermediate certificate blocks. Older Go releases (1.25 and earlier) are out of support and will not receive these fixes. Users of affected services will need to obtain certificates from a different intermediate CA before rebuilt Go clients can establish connections.