Go heeft een emergency update uitgebracht die direct invloed kan hebben op TLS-verbindingen. In de nieuwe versies (Go 1.27.3 en Go 1.26.10) wordt de certificaatverificatie zó aangepast dat een certificaatketen die via acht specifieke intermediate CA-sleutels loopt, wordt geweigerd. Dat betekent: programma’s die met deze nieuwe Go-builds zijn gemaakt, kunnen sites of diensten met die certificaatketens niet meer bereiken.
De boodschap van het Go-team is helder: upgrade onmiddellijk. Er is namelijk geen instelling die het blokkeren uitschakelt, en bestaande builds blijven tot herbouw hetzelfde gedrag houden.
Wat betekent “Go blokkeert CA-sleutels” voor jou?
Het gaat om de manier waarop Go certificaatketens valideert. De filter controleert bij het verifiëren van certificaten op basis van de hash van de publieke sleutel, niet op de volledige certificaattekst. Daardoor kan ook een “gekopieerde” variant of een cross-signed keten alsnog worden geraakt als dezelfde publieke sleutel onder de afgeleide keten voorkomt.
Concreet: zodra Go een certificaatketen niet als geldig kan opbouwen omdat die langs één van de acht geblokkeerde intermediate keys loopt, krijg je een fout zoals “x509: no valid chains built”.
Welke Go-versies zijn getroffen en wat moet je doen?
Go publiceerde de wijziging in twee releases die op 20 oktober zijn uitgebracht: Go 1.27.3 en Go 1.26.10. Het Go-team heeft de fix op de URGENT-track gezet, bedoeld voor de meest ernstige problemen.
De praktische aanpak is daarom:
- Upgrade naar een ondersteunde Go-versie (oudere releases krijgen geen fix meer).
- Herbouw je applicaties die met Go zijn samengesteld, zodat ze het nieuwe certificaatgedrag meenemen.
- Test TLS-verbindingen naar alle externe services waarvan certificaten mogelijk via die acht intermediates lopen.
Belangrijk: er is geen tijdelijke workaround in Go-gedrag beschikbaar, en je kunt het filter niet uitzetten.
Waarom is dit geen “browserprobleem”, maar een echte compatibiliteitsimpact?
Veel organisaties denken bij blokkades eerst aan browser root stores, CRLs of vergelijkbare mechanismen. In dit geval is het anders: Go’s verifier pakt het zelf aan. De filter draait in de Go-verificatiecode en ook in de codepaden die certificaatverificatie aan het besturingssysteem overlaten op macOS en Windows.
Daarnaast doet Go zelf volgens de documentatie geen revocation checking en het leest ook niet automatisch blokkadelijsten die browsers gebruiken, zoals CRLSets uit Chrome. Met andere woorden: “verboden” is hier niet gebaseerd op wat een browser vandaag blokkeert, maar op een expliciet ingerichte blokkering in de Go-verificatie.
Omdat de beslissing in een release wordt “meegenomen”, blijft gedrag tot herbouw gelijk voor bestaande binaries. Nieuwe builds kunnen dus anders uitpakken dan oudere.
Welke CA-sleutels zijn geblokkeerd?
Go publiceerde enkel de SHA-256 hashes van de acht intermediate keys. Een commentator matchte deze hashes vervolgens met bestaande certificate records, waarmee een verband met eMudhra intermediates aannemelijk werd gemaakt.
Op basis van die match zouden zes van de acht keys gaan over TLS intermediates onder de emSign Root TLS CA – G3, met varianten voor domain validation, organization validation en extended validation. De andere twee zouden code-signing intermediates zijn onder emSign Root CS CA – G3.
Het artikel benadrukt dat er geen onafhankelijke controle is uitgevoerd door de publicatie zelf op basis van de hashes tegen certificaten; wel wordt aangegeven dat de betreffende Mozilla-blokkade-items dezelfde root noemen, maar dat Mozilla’s records niet dezelfde certificaatnamen weergeven.
Vergelijking met Mozilla: wat is er al eerder geblokkeerd?
Twee dagen eerder, op 17 oktober, voegde Mozilla zes intermediate certificaten toe aan OneCRL, een lijst die Firefox gebruikt om certificaten te blokkeren. Het achterliggende bugrapport is niet publiek toegankelijk, en er is niet duidelijk gemaakt waarom Mozilla deze actie nam.
Ook voor andere ecosystemen—zoals Chrome, Apple of Microsoft—staat niet vast of zij vergelijkbare maatregelen hebben genomen. Het is in elk geval geen “gelijk spel”: Go’s actie komt uit eigen verificatiegedrag en heeft geen instelling om de filter te neutraliseren.
Geen bypass: ook private trust kan mislukken
Een opvallend detail is dat de filter niet alleen speelt wanneer je Go een standaard set vertrouwde roots laat gebruiken. Door de manier waarop de code is opgebouwd, kan het filter ook actief blijven wanneer een programma zelf een set trusted roots aanlevert in een private deployment.
Dat betekent dat je niet kunt redeneren: “wij vertrouwen die key bewust, dus het werkt.” Als een keten door één van de acht geblokkeerde publieke sleutels loopt, wordt de verbinding geweigerd.
Wat kun je nu meteen regelen in je omgeving?
Omdat het om een compatibiliteitswijziging gaat, is snelheid belangrijk. Dit is een praktische checklist die je vandaag kunt doorlopen:
- Inventariseer waar je Go-clients gebruiken in productie en welke externe endpoints zij bereiken.
- Plan een herbouw zodra je naar Go 1.27.3 of 1.26.10 migreert.
- Voer TLS-tests uit op alle kritieke verbindingen (API’s, callbacks, externe datapijplijnen).
- Werk certificaten bij waar nodig: de getroffen ketens zullen moeten overstappen op een alternatief intermediate voordat Go clients opnieuw succesvol kunnen verbinden.
Let erop dat de foutmelding pas zichtbaar wordt wanneer je verbinding daadwerkelijk probeert te verifiëren. Dat kan dus in een laat stadium opvallen als je niet vooraf test.
Wat weten we over de oorzaak?
Het is niet openbaar wat er precies met de betreffende certificaatautoriteit of intermediates aan de hand was. De aankondiging van Go noemt één zin over specifieke beveiligingszorgen rond de operation van de betrokken keys.
Daarnaast kwam de release zonder voorafgaande melding die Go normaal zou sturen voor security releases eerder in oktober. Go’s security policy beschrijft URGENT issues als een bedreiging voor de integriteit van het Go-ecosysteem of als gevallen waarin actief misbruik met ernstige schade speelt. In dit geval is niet publiek gemaakt welke van die categorieën van toepassing is.
Bottom line: upgrade en test nu
Go blokkeert CA-sleutels door acht intermediate publieke keys in de certificaatketenverificatie te weigeren. Dat kan ervoor zorgen dat sommige clients geen verbinding meer krijgen met services waarvan certificaten via die intermediates zijn uitgegeven. Er is geen uitschakeloptie en geen tijdelijke workaround.
Als je Go gebruikt—zeker voor productiecode die TLS-verkeer doet—richt je actie dan op snelle upgrade naar Go 1.27.3 of 1.26.10 en grondige test van je endpoints. Daarmee voorkom je dat de eerste signalen pas verschijnen zodra je herbouwde binaries live gaan.
Wil je je bredere context rond certificaat- en toegangsrisico’s aanscherpen? Lees dan ook wat een gecompromitteerde toegang in de praktijk betekent en waarom patches en updates cruciaal zijn.
Bron: https://thehackernews.com/2026/10/go-issues-emergency-update-blocking.html
