Go certificate update blocks eight intermediate CA keys
The Go certificate update in Go 1.27.3 and Go 1.26.10 makes software reject connections when a certificate chain passes through any of eight blocked intermediate certificate authority keys. A certificate authority (CA) is an organisation trusted to issue digital certificates that help software confirm the identity of a website or service. Both Go releases arrived on October 20, and the Go team recommends updating immediately.
The change affects programs built with the new releases. When one of those programs connects to a website or online service, Go's certificate verifier checks the chain of certificates linking that destination to a trusted authority. If the path includes one of the blocked keys, verification fails and the program returns the error “x509: no valid chains built.” Sites using certificates issued beneath those keys will therefore become unreachable from rebuilt Go clients until the sites obtain certificates from a different intermediate authority.
Go has not named the CA behind the keys. Its announcement refers only to specific security concerns involving their operation. The update was handled through Go's URGENT process, which its security policy reserves for threats to the integrity of the Go ecosystem or vulnerabilities being actively exploited with severe consequences. The project says there are no recent examples of issues receiving that classification, but it has not disclosed which condition applied here or what happened at the CA. The release also arrived without the advance notice that preceded Go's October 8 security releases.
The update identifies the blocked keys only by their SHA-256 hashes, which are digital fingerprints calculated from their public keys. A commenter on the Go issue matched all eight hashes to eMudhra intermediates using public certificate records. The Hacker News said it had not independently confirmed that matching. Based on the commenter's findings, six are Transport Layer Security (TLS) intermediates, used to secure connections to websites and services, under emSign Root TLS CA - G3. They are EM DV TLS CA - G3B and EM DV TLS CA - G3C for domain-validated certificates, EM OV TLS CA - G3B and EM OV TLS CA - G3C for organisation-validated certificates, and EM EV TLS CA - G3B and EM EV TLS CA - G3C for extended-validation certificates. The remaining two, EM OV CS CA - G3B and EM OV CS CA - G3C, are code-signing intermediates under emSign Root CS CA - G3.
Mozilla had added six intermediate certificates issued by eMudhra's emSign Root TLS CA - G3 to OneCRL on October 17. OneCRL is a block list used by Firefox to reject certificates. The related Mozilla bug is not publicly accessible, and Mozilla has not stated why the certificates were added. Mozilla's entries identify the same issuing root but do not name the six certificates themselves. It is not established whether Chrome, Apple or Microsoft have taken comparable action.
Go's filter calculates a fingerprint from each certificate's public key rather than from the complete certificate. That means it also catches a cross-signed certificate containing the same key but authorised through a different root. The check operates in Go's own certificate verifier and in the macOS and Windows paths where Go delegates verification to the operating system. It also appears to apply when an application supplies its own trusted roots, including private environments that deliberately trust one of the keys. Go has not said whether blocking those private configurations was intentional, and the update offers no option to disable the filter.
The distinction matters because Go's documentation states that its verifier does not perform revocation checking, the process used to determine whether a certificate has been withdrawn before it expires. It also does not consume browser-maintained blocking systems such as the CRLSets Chrome used against rogue Google certificates this month. Go must instead distribute the blocked keys through a software release. Existing applications keep their previous behaviour until developers rebuild them with an updated Go version. Projects including Bluesky's indigo were rebuilt with the new releases on October 20.
eMudhra is an Indian CA that sells certificates under the emSign brand. Its emSign Root CA - G1 and emSign ECC Root CA - G3 are present in the Chrome, Apple and Mozilla root stores. The company previously told Mozilla that the newer TLS root is cross-signed by emSign Root CA - G1, allowing certificates beneath that newer root to connect to an already trusted root. A six-week public discussion about adding ten new eMudhra roots to browser and operating-system root programs, including emSign Root TLS CA - G3, ended in September without objections.
Certificate transparency records checked by The Hacker News on October 20 showed that certificates for eMudhra's own domains, including emsign.com and emudhra.com, used other eMudhra intermediates. The company's certificate repository had no notice about the blocked intermediates that day, and The Hacker News found no public statement from eMudhra. A user also asked the Go team to explain which organisations and certificates corresponded to the committed block, but the team had not answered as of October 20.
Administrators should update supported Go branches and rebuild affected applications, then investigate any resulting certificate-chain failures. Go 1.25 and earlier versions are unsupported and will not receive this fix, so users of those branches must move to a supported release from Go's download page. There is no documented temporary workaround, and sites whose certificates pass through the blocked keys need a replacement issued through a different intermediate. For organisations reviewing affected applications and certificate paths, AEU-I provides security-first IT, infrastructure and consulting.