Go heeft een noodupdate uitgebracht die in nieuwere versies een belangrijk certificaatrisico afvangt: Go weigert vanaf Go 1.27.3 en Go 1.26.10 verbindingen als de certificaatketen loopt via acht specifieke intermediate CA-sleutels. Dat betekent concreet dat Go-toepassingen plots sites of diensten kunnen benaderen met de melding x509: no valid chains built, ook al werkten dezelfde clients eerder wel.
De kern is dat het Go-team deze sleutels blokkeert vanwege “specifieke security concerns” rond de werking ervan. Een praktische consequentie: er is geen uit/aan-schakelaar om het filter te omzeilen en oude Go-builds blijven hun gedrag houden totdat je opnieuw bouwt met een ondersteunde versie.
Wat doet de Go noodupdate precies?
De update introduceert een filter in de Go-certificaatverificatie. Tijdens het valideren van een certificaatketen controleert Go of een van de betrokken sleutels overeenkomt met de geblokkeerde set. Opvallend is dat Go niet alleen naar certificaten zelf kijkt, maar naar de SHA-256 hashes van de publieke sleutels die in de keten voorkomen.
Daarmee is het filter robuust tegen varianten zoals cross-signed exemplaren: als dezelfde publieke sleutel ook via een ander root-pad wordt aangeboden, kan het alsnog worden afgevangen. Het filter wordt gebruikt in Go’s eigen verificatepad én in codepaden op macOS en Windows die certificaatverificatie via het besturingssysteem laten verlopen.
Welke certificaatketens worden geblokkeerd?
Go blokkeert acht intermediate CA-sleutels. De broninfo beschrijft dat Go zelf geen namen noemt van de betreffende CA in de aankondiging. Wel werd door een community-lid een koppeling gemaakt door hashes te vergelijken met openbare certificaatrecords.
Volgens die matching behoren zes van de acht sleutels tot TLS-intermediates onder een emSign Root TLS CA (genaamd “emSign Root TLS CA – G3”), en de overige twee tot code-signing intermediates onder “emSign Root CS CA – G3”. De domeinen van eMudhra worden daarbij niet als probleem aangemerkt, maar de intermediates die via dezelfde rootketen verlopen worden wél geraakt.
- TLS, domain validated: EM DV TLS CA – G3B en EM DV TLS CA – G3C
- TLS, organization validated: EM OV TLS CA – G3B en EM OV TLS CA – G3C
- TLS, extended validation: EM EV TLS CA – G3B en EM EV TLS CA – G3C
- Code signing: EM OV CS CA – G3B en EM OV CS CA – G3C
Let op: het bronartikel stelt dat The Hacker News de hashes niet onafhankelijk heeft geverifieerd. Wel is er context dat Mozilla eerder (twee dagen voor Go’s release) zes intermediate certificaten heeft toegevoegd aan een Firefox-blocklist (OneCRL), maar zonder publiek toegelichte reden. Ook voor andere browsers/OS’s is niet vastgesteld dat zij vergelijkbare maatregelen hebben genomen.
Waarom is dit belangrijk voor jouw applicaties?
Als je applicatie in Go draait en een servercertificaat gebruikt waarvan de keten door één van de geblokkeerde sleutels loopt, dan kan Go de verbinding weigeren. In het dagelijks gebruik merk je dat als webhooks die falen, API-calls die stoppen, of data-overdrachten die niet meer werken na een upgrade.
Cruciaal om te begrijpen: Go’s verifier doet geen revocation checking en gebruikt ook niet automatisch de browser-specifieke blocklijsten zoals CRLSets. Het “blokkeren” zit daardoor vooral in het feit dat de filterlogica in een release wordt opgenomen. Nieuwe behavior komt dus pas beschikbaar zodra je applicatie wordt herbouwd met een Go-release die het filter bevat.
Geen tijdelijke workaround
Volgens de broninformatie is er geen instelling om het filter uit te zetten. Daarnaast geldt het vermoedelijk ook voor omgevingen waarin een programma zelf een set vertrouwde roots aanlevert: ook in zo’n privaat trust-model kan de geblokkeerde intermediate keten alsnog leiden tot afwijzing.
Wat moet je nu doen? (praktische checklist)
De Go-team raadt aan om onmiddellijk te upgraden. Dat klinkt zwaar, maar het is logisch gezien de impact op TLS-verbindingen. Dit is een praktische aanpak.
1) Upgrade Go en herbouw
Installeer Go 1.27.3 of Go 1.26.10 (of een latere ondersteunde variant) en herbouw je binaries. Alleen upgraden op je buildmachine zonder rebuild in je distributieketen zorgt ervoor dat productie nog oud gedrag vertoont.
2) Test op je belangrijkste endpoints
Richt je test op de services waarmee je system-to-system communiceert: API’s, interne gateways, externe SaaS en observability endpoints. Verwacht geen nette degradatie; de fout komt als een x509 no valid chains built-melding.
3) Controleer je certificaatketens
Als een verbinding faalt, inspecteer dan welke intermediate CA in de keten zit. Je doel is niet om “de fout te repareren” bij Go, maar om de keten die jouw clients aangeboden krijgen te vervangen door een alternatief intermediate pad.
4) Werk met leveranciers af
Wanneer een externe dienst de TLS-keten levert, zal de oplossing uiteindelijk bij de aanbieder liggen. De broninformatie geeft aan dat het gaat om clients die opnieuw moeten worden gebouwd voordat ze met de herziene keten weer kunnen verbinden. Zet dit dus door richting je vendor of service provider.
Context: waarom gebeurt dit zonder voorafgaande uitleg?
De bron beschrijft dat Go deze fix in het URGENT track traject publiceerde. Dat track is bedoeld voor problemen die de integriteit van het Go-ecosysteem bedreigen of waar actief misbruik mee plaatsvindt met ernstige schade. Tegelijk vermeldt de bron dat Go niet publiek heeft gemaakt welke van de URGENT criteria precies speelde.
Daarnaast kwam de release zonder de gebruikelijke pre-announcement die Go normaal stuurde voorafgaand aan zijn security releases. De daadwerkelijke aanleiding bij de certificate authority is dus niet publiek gedocumenteerd.
Voor teams die security governance al serieus nemen, is dit een reminder dat certificaatvertrouwen geen statisch gegeven is. Het kan door blocklists en CA-verwante maatregelen sneller veranderen dan je deploymentcyclus aankan. Als je wilt vergelijken met eerdere incidentpatronen rond certificaten en governance, is dit artikel over AI-security governance nuttig voor het breder denken over controles en upgradesnelheid.
Impact op bestaande releases en deploymentstrategieën
Go 1.25 en oudere versies zijn out of support en krijgen geen fixes. Met andere woorden: als je nog op een oudere Go versie draait, is herzien van je toolchain onvermijdelijk.
Voor bestaande (gecompileerde) binaries geldt dat ze pas door de nieuwe filterlogica worden beïnvloed wanneer ze zijn gebouwd met een Go versie die het filter bevat. Dat maakt je releaseplanning belangrijk: je kunt deels mitigeren door gecontroleerd te herdeployen zodra je endpoints getest zijn.
Het bronartikel meldt ook dat projecten zoals Bluesky’s indigo op de release-datum zijn herbouwd. Dat is een aanwijzing dat teams snel moeten schakelen wanneer TLS-verificatie centraal staat in hun connectiviteit.
Conclusie
De Go noodupdate blokkeert: met Go 1.27.3 en Go 1.26.10 worden certificaatketens geweigerd wanneer ze via acht specifieke intermediate CA-sleutels lopen. Er is geen schakelaar om dit uit te zetten, dus de praktische route is upgraden en herbouw, gevolgd door testen op je kritieke endpoints.
Door dit vroeg te adresseren voorkom je dat je systemen onverwacht “in het donker” raken door een TLS-verificatiefout. Richt je nu op Go-upgrade, rebuild en het afstemmen met service providers zodra je certificaatketens in scope blijken.
Bron: https://thehackernews.com/2026/10/go-issues-emergency-update-blocking.html
