Was diese Woche passiert ist

Laut Google ging die Meldung am 17. Oktober 2026 ein. Die betroffenen privaten Schlüssel waren mit unzureichender Zufälligkeit erzeugt worden. Damit lassen sich gegenüber Clients, die diesen Stellen noch vertrauen, gefälschte HTTPS-Zertifikate zur Identitätsvortäuschung verwenden.[2] Das Problem betrifft also nicht einfach ein abgelaufenes Zertifikat einer einzelnen Website, sondern das Vertrauen in ausstellende Stellen.[2]

Google berichtet, dass Chrome noch am 17. Oktober eine Sperrliste für die betroffenen Schlüssel erhielt, ohne dass dafür ein Browserupdate oder Neustart nötig war.[2] Daraus würde ich aber keine pauschale Entwarnung für die eigene Infrastruktur ableiten. Canonical weist ausdrücklich darauf hin, dass die typischerweise als Snap installierten Browser auf Ubuntu Desktop nicht den System-Zertifikatsspeicher aus ca-certificates verwenden.[1] Browserstatus und Systemstatus sind deshalb zwei getrennte Prüfpunkte.

Der eigene Anbieter ist nicht die ganze Antwort

„Unsere Website nutzt doch eine andere CA“ wäre für mich noch kein Abschluss des Tickets. Canonical beschreibt, dass ein Client, der der kompromittierten CA vertraut, auch ein gefälschtes Zertifikat akzeptieren könnte – unabhängig davon, welche CA der echte Zielserver verwendet, sofern keine wirksamen zusätzlichen Schutzmaßnahmen greifen.[1] Entscheidend ist also auch, welchen Ausstellern deine Clients vertrauen.

Meine Empfehlung: Betrachte den Vorfall aus zwei Richtungen. Als Betreiber prüfst du die Zertifikatskette deiner eigenen Dienste. Als Nutzer fremder Dienste prüfst du den Wartungsstand deiner Clients. Im Homelab würde ich dafür beispielsweise den Reverse Proxy, die Backup-VM, einen Monitoring-Container und einen automatisierten Downloadjob auf die Liste setzen. Nicht weil diese Systeme nachweislich betroffen wären, sondern weil ich ihren tatsächlichen Zustand erst feststellen möchte.

Ubuntu: gezielt prüfen statt blind bestätigen

Canonical nennt als gezielte Aktualisierung sudo apt update && sudo apt install --only-upgrade ca-certificates.[1] Ich würde den Befehl bewusst ohne automatische Bestätigung ausführen: Paketquellen, angebotene Änderungen und eventuelle Fehlermeldungen sollen sichtbar bleiben. Auf produktiven Systemen gehört das in den üblichen Freigabe- und Wartungsablauf, nicht in eine hektische Sammelaktion.

Für Ubuntu 24.04 nennt die veröffentlichte Tabelle 20260816ubuntu0.24.04.1 als korrigierte Paketversion; für 22.04 ist es 20260816ubuntu0.22.04.1.[1] Das sind Angaben für genau diese Releases, keine universelle Versionsvorgabe. Canonical unterscheidet außerdem zwischen Standard-Support für neuere Releases und ESM über Ubuntu Pro bei 20.04 oder älter.[1] Prüfe daher zuerst deine tatsächliche Ubuntu-Version und den dazugehörigen Updateweg.

Für die Bestandsaufnahme schlage ich diese rein lesenden Befehle vor:

cat /etc/os-release
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates
apt-cache policy ca-certificates

Notiere installierte Version, angebotene Version und Prüftermin. Vergleiche das Ergebnis mit der Herstellerübersicht. Bei Debian, Fedora oder einer Appliance würde ich nicht einfach die Ubuntu-Versionsnummer übertragen, sondern die jeweilige Herstellerinformation heranziehen. Ein ausgeführter Updatebefehl ist für mich erst dann ein erledigter Arbeitsschritt, wenn sein Ergebnis geprüft wurde.

Container und Jobs bewusst mitnehmen

Meine Empfehlung für kleine Umgebungen: Ergänze die Maschinenliste um die Anwendungen, die tatsächlich HTTPS-Verbindungen aufbauen. Welche Adresse ruft das Backup-Skript auf? Wo läuft der Monitoring-Check? Wer pflegt das verwendete Container-Image? Dokumentiere für jeden wichtigen Ablauf, wo du seinen Zertifikatsspeicher und seinen Updateweg überprüft hast.

Ich würde dabei keine unbekannten Truststores vorsorglich überschreiben und keine eigenen CA-Zertifikate auf Verdacht entfernen. Stattdessen: Anwendung identifizieren, Herstellerhinweise lesen, Änderung an einem geeigneten Testsystem prüfen und erst danach ausrollen. Falls ein Image neu gebaut oder ein Dienst neu gestartet werden soll, gehört auch das ausdrücklich in den Änderungsplan. Dieser Beitrag ist keine Aufforderung, produktive Container ungeprüft auszutauschen.

Nach dem Update zählt die echte Verbindung

Teste anschließend die tatsächlich genutzten Abläufe: einen regulären Backup-Lauf, einen Monitoring-Aufruf oder den Download über den vorgesehenen Client. Ein zusätzlicher Aufruf mit curl -Iv https://dein-dienst.example kann als Diagnose dienen; die Platzhalteradresse musst du durch dein Ziel ersetzen. Ich würde den Test im betroffenen System beziehungsweise Container ausführen, nicht nur vom eigenen Notebook.

Wichtig ist die Fehlerbehandlung. Canonical warnt, dass die Entfernung betroffener Vertrauensanker auch legitime Zertifikate unvertrauenswürdig machen kann.[1] Google kündigt zudem die breitere Entfernung von emSign ECC Root CA - G3 aus dem Chrome Root Store für den 27. Oktober 2026 an und fordert betroffene Websitebetreiber zum Wechsel auf eine andere vertrauenswürdige Zertifikatskette auf.[2] Das ist eine angekündigte Änderung, kein hier bereits nachgewiesener Ausfall.

Bei neuen TLS-Fehlern würde ich deshalb Zertifikatskette, Hostname, Systemzeit und Clientkonfiguration untersuchen. Mein klarer Betriebsgrundsatz: Nicht mit curl -k oder dauerhaft abgeschalteter Zertifikatsprüfung „reparieren“. Für die Abnahme soll die Verbindung mit aktiver Prüfung funktionieren; andernfalls bleibt die Ursache offen und dokumentiert.

Ein überschaubarer Abschluss

Für diese Woche schlage ich vier Häkchen vor: relevante Clients erfasst, Herstellerupdates geprüft, vorgesehene Änderungen kontrolliert umgesetzt und wichtige Verbindungen danach erfolgreich getestet. Dazu eine kurze Notiz über Ausnahmen und ihren nächsten Prüftermin. So wird aus einer großen PKI-Meldung eine begrenzte Wartungsaufgabe.

Der praktische Gedanke dahinter: Vertraue beim Wartungsstatus nicht auf den Eindruck eines einzelnen Browsers. Prüfe dort, wo deine Dienste wirklich arbeiten. Die Fakten dieses Beitrags stammen aus den verlinkten Herstellerinformationen; der vorgeschlagene Ablauf ist eine redaktionelle Empfehlung, keine Behauptung über einen bereits untersuchten oder betroffenen Server.

Quellen

Stand: 21. Oktober 2026. Die verlinkten Meldungen wurden am 20. Oktober veröffentlicht. Praktische Abläufe sind redaktionelle Empfehlungen.