x509: No Valid Chains Built After Go 1.27.3: What to Do

Why does Go say x509: no valid chains built after the 1.27.3 update?

Go 1.27.3 and 1.26.10, released on 20 October 2026, filter out any certificate chain that contains one of a small set of blocked intermediate certificate authority keys. If a server's chain passes through one, a program built with these releases fails the connection with x509: no valid chains built [1][2].

The Go team described it as blocking trust in intermediates because of "specific security concerns around their operation". It is tracked as CVE-2026-111943 and Go issue 82345, handled on the URGENT track [1].

Only programs rebuilt on the new releases are affected. A binary you built earlier keeps its old behaviour until you recompile it [2].

What exactly did Go block?

The Go change lists SHA-256 hashes of eight public keys and does not name the certificate authority. The Hacker News reports that a commenter on the Go issue matched them to eMudhra emSign intermediates: six TLS intermediates under emSign Root TLS CA - G3 and two code-signing intermediates. The Hacker News said it had not independently checked those hashes [2].

Because the filter hashes each public key rather than the certificate, a cross-signed copy of a blocked key is caught too. It runs in Go's own verifier and in the macOS and Windows paths that hand verification to the operating system [2].

Fact versus open question: the Go team has not said what prompted the change, and eMudhra had published no public statement when The Hacker News checked on 20 October [2].

How do I check whether my service is affected?

1. Rebuild a staging copy with Go 1.27.3 or 1.26.10 and run your normal outbound TLS paths: payment, email, webhooks, internal services, and any partner API.

2. Search logs for x509: no valid chains built after the rebuild. The error means no acceptable chain could be built, so also check the server side.

3. Inspect the failing host's chain with openssl s_client -connect host:443 -showcerts, and note the issuer of each intermediate. If it names an emSign TLS intermediate, that is the likely cause. Treat this as a lead to confirm, not proof, since the Go team has not published the mapping.

4. Check whether your own private PKI or a vendor trusts one of the eight keys. The report says the filter appears to apply even when a program supplies its own trusted roots, though the Go team has not said whether that is intended [2].

What are my options if a dependency's chain is blocked?

The sources describe no setting to disable the filter, and no temporary workaround [2]. Go 1.25 and older are out of support and get no fix, so the only route is a supported release from the Go download page [2][3].

The realistic fix is on the certificate side: the operator of the failing server needs a certificate issued under a different intermediate. If that server is a vendor's, ask them. If you run it, reissue with another CA.

Some teams reverted a toolchain bump after seeing failures. Docker's secrets-engine repository has commits titled revert Go to 1.26.10, visible on the Go issue [1]. Reverting only postpones the problem and keeps the older behaviour, so use it as a short-term measure while certificates are replaced.

Should small SaaS teams rush this upgrade?

Prediction, not fact: for most teams the safer order is to upgrade promptly and test outbound connections first, because the Go team said it "highly recommend[s]" upgrading immediately [1]. A failed TLS call in staging is cheaper than one in production.

Our reading, not Go's wording: the interesting lesson is that a toolchain patch can change which internet services your code trusts. Go's verifier does no revocation checking [4], so shipping the block in a release is how it removes trust. That puts "pin your Go version and rebuild on a schedule" next to dependency updates in the release checklist.

Another point from the reports: whether Chrome, Apple or Microsoft took similar action is not established [2]. Do not assume browsers and Go agree on the same list.

Frequently asked questions

The short version

Go 1.27.3 and 1.26.10 block eight intermediate CA keys, so a rebuilt program can fail with x509: no valid chains built if a server's chain uses one. Upgrade, test outbound connections in staging, and ask affected operators to reissue certificates.

For the wider picture of keeping a product's dependencies current, see our guide to the Next.js and React security update, and our services page for how we scope SaaS builds.