← All writing
Go

When Go stopped trusting eight CA keys

On 20 October Go blocked eight certificate-authority keys in a point release. Rebuilt programs may refuse sites that older binaries still accept. Here is what to check.

Udara Premadasa 3 min read

Most security alerts are about a bug. This one is about trust. On 20 October 2026, in an emergency release, Go stopped trusting eight keys belonging to a certificate authority. This followed Mozilla’s decision on 17 October to distrust six intermediates from the same family of issues.

What happened

Every HTTPS connection relies on a chain: a trusted root, an intermediate that it vouches for, and the website’s own certificate. Go’s release blocks specific intermediate keys. If a site’s chain goes through one of them, a program built with the new Go fails with:

x509: no valid chains built
THE SAME WEBSITE, THREE PROGRAMSBuilt before Oct 20an older Go releaseserver certificatevia blocked intermediateconnectsuntil rebuiltRebuilt on Go 1.27.3or 1.26.10server certificatevia blocked intermediaterefusedx509 errorRebuilt, and the servermoved to another CAserver certificatevia another intermediateconnectsnew chainOld binaries keep the old behaviour until they are rebuilt.
Figure 1. The same website seen by three programs. Only the rebuilt one that still uses a blocked key is refused.

The surprise is who is affected. A binary built before 20 October keeps the old behaviour and connects happily, until it is rebuilt. A service built on Go 1.27.3 or 1.26.10 starts failing the moment it meets a chain through a blocked key. That makes this a rebuild-day bug: everything works, you ship a routine update, and then an outbound call breaks.

What could happen to your code

  • A routine rebuild of a healthy service suddenly cannot reach a payment, mail, identity or webhook provider.
  • CI pipelines that download tools or call registries start failing with certificate errors.
  • A partner API you do not control may still be on a blocked chain. You cannot fix that on your side beyond waiting for them.

What to do

  1. Before deploying a rebuild, run it in staging and call every external endpoint it depends on. Look specifically for x509 errors.
  2. If you operate a server, check which CA and intermediate your certificate chains through. If it is one of the blocked keys, re-issue the certificate from another intermediate and make sure your server sends the full chain.
  3. If a dependency’s endpoint fails, contact them with the exact error and chain. Do not turn off certificate verification as a workaround; that trades a broken connection for an open door.
  4. Keep an inventory of your outbound dependencies so you know what to test.
  5. Alert on certificate errors in logs, so the first sign is a graph, not a customer.
GoCertificates
Working through something similar?
I'm Udara. I build these tools and I like talking about how they get built. Tell me what you're stuck on, or let's work on it together.
Write to me
Keep reading
Previous · Self-hostingBefore you self-host your sign-in Related · GoGo: fifteen fixes in one release Next · SecurityThe week the foundations shook