Das Chrome-Sicherheitsteam meldete den Vorgang am 6. Oktober 2026 – betroffen sind nach seinen Angaben auch weitere große Marken und Onlinedienste
Das Wichtigste in Kürze
- Angreifer haben nach Darstellung des Chrome-Sicherheitsteams die Verwaltung der Länderendungen .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa) übernommen. Google veröffentlichte den Vorgang am 6. Oktober 2026 um 11:53 Uhr UTC, also 13:53 Uhr deutscher Zeit.
- Damit erhielten die Angreifer nach Angaben des Unternehmens unberechtigte HTTPS-Zertifikate für mehrere Google-Domains. Über die Protokolle der Certificate Transparency fanden sich Hinweise auf weitere betroffene Organisationen.
- Google nennt weder die Zahl der ausgestellten Zertifikate noch eine beteiligte Zertifizierungsstelle beim Namen und erklärt ausdrücklich, es gebe keinen Anhaltspunkt für ein Fehlverhalten der ausstellenden Stellen.
Wer in Deutschland eine Internetseite aufruft und das Schloss-Symbol in der Adresszeile sieht, verlässt sich auf eine Kette, die kaum jemand im Alltag bemerkt: Eine Zertifizierungsstelle hat vorher geprüft, ob die Gegenstelle wirklich zu der Adresse gehört, die im Browser steht. Genau diese Prüfung ist nach Darstellung von Google in den vergangenen Tagen bei drei Länderendungen ins Leere gelaufen.
Das Chrome-Sicherheitsteam des US-Konzerns beschreibt in einem Beitrag vom 6. Oktober 2026, Angreifer hätten die zuständigen Verwaltungsstellen der Endungen .gh, .sl und .as kompromittiert. In der Formulierung des Unternehmens stand damit „jede Domain, die auf .gh, .sl oder .as endet“, unter Risiko (alle Zitate aus dem Englischen übersetzt) – nicht nur Seiten, die inhaltlich etwas mit den drei Ländern zu tun haben. Als Zeitpunkt nennt der Beitrag lediglich „vergangene Woche“; ein genaues Datum des Einbruchs teilt Google nicht mit. Die Betreiber der drei Endungen werden in dem Beitrag nicht benannt; eigene Stellungnahmen von ihnen waren bis Redaktionsschluss nicht auffindbar.
Was die Angreifer damit erreichten
Der Zugriff auf eine Registry ist deshalb so wirksam, weil dort die oberste Ebene des Adressbuchs im Netz geführt wird. Wer sie kontrolliert, bestimmt, welche Nameserver für eine Domain zuständig sind – und damit, welche Antworten das Domain Name System auf Anfragen zu dieser Adresse gibt.
Nach Angaben von Google nutzten die Angreifer das aus, um „unberechtigte HTTPS-Zertifikate zu erhalten, die mehrere Google-Domains abdecken, sowie Domains, die anderen Organisationen gehören“. Dass Google die Papiere eigens über Sperrlisten blockieren musste, zeigt den Kern des Problems: Für den Browser ist ein so entstandenes Zertifikat zunächst nicht von einem rechtmäßig beantragten zu unterscheiden.
Warum eine Zertifizierungsstelle das nicht bemerkt
Bevor eine Zertifizierungsstelle ein Zertifikat ausstellt, prüft sie, ob die beantragende Seite die Domain tatsächlich kontrolliert. In der Regel läuft dieser Nachweis über das Domain Name System – etwa über einen Eintrag, den nur setzen kann, wer Zugriff auf die Verwaltung der Domain hat.
Diese Prüfung misst Kontrolle, nicht Eigentum. Wer die Registry einer Endung übernimmt, hat genau diese Kontrolle – und besteht die Prüfung regulär. Das ist auch die Begründung dafür, dass Google in seinem Beitrag erklärt, es habe „keinen Grund zu der Annahme, dass die Zertifizierungsstellen, die die betroffenen Zertifikate ausgestellt haben, etwas falsch gemacht haben“.
Chrome sperrte die Zertifikate nachträglich
Google beschreibt die eigene Reaktion in zwei Schritten. Zunächst habe man „sofort gehandelt, um Nutzer zu schützen, indem die Verwendung unberechtigter Zertifikate für Google-Dienste in Chrome über CRLSets blockiert wurde“. CRLSets sind Sperrlisten, die der Browser mit seinen regelmäßigen Aktualisierungen bezieht. Anschließend habe das Unternehmen dieselbe Sperre vorsorglich auf die Zertifikate weiterer Organisationen ausgedehnt und mit den ausstellenden Stellen daran gearbeitet, die Zertifikate zurückzuziehen.
Wie viele andere Organisationen betroffen sind, sagt Google nicht. Der Beitrag spricht davon, dass die Daten der Certificate-Transparency-Protokolle „weitere Organisationen“ erkennbar gemacht hätten, „darunter mehrere führende globale Marken und weitverbreitete Onlinedienste“. Namen fallen keine.
| Frage | Angabe im Google-Beitrag |
|---|---|
| Welche Endungen sind betroffen? | .gh, .sl und .as |
| Wann geschah der Einbruch? | „vergangene Woche“ – kein Datum |
| Wie viele Zertifikate wurden ausgestellt? | keine Angabe |
| Welche Zertifizierungsstellen waren beteiligt? | nicht genannt |
| Welche weiteren Organisationen sind betroffen? | „mehrere führende globale Marken“ – ohne Namen |
| Wurden Daten abgegriffen? | keine Angabe |
Der blinde Fleck liegt eine Ebene über der eigenen Domain
Für Fachleute ist der Vorgang kein neuer Angriffstyp, wohl aber eine unangenehme Erinnerung: Die Sicherheit einer Adresse hängt nicht nur davon ab, wie gut ihr Inhaber sein eigenes Konto schützt, sondern auch davon, wie gut die Verwaltung der Endung darüber geschützt ist. Ein Unternehmen kann starke Passwörter, Mehrfaktoranmeldung und eine gesperrte Domain verwenden – gegen einen Einbruch in die Registry selbst hilft davon nichts.
Genau an diesem Punkt setzen die beiden Empfehlungen an, die Google am Ende seines Beitrags gibt. Erstens: die Protokolle der Certificate Transparency für alle eigenen Domains dauerhaft zu beobachten (Empfehlung im Google-Beitrag). In diesen öffentlichen Protokollen muss jedes ausgestellte Zertifikat eingetragen werden, sodass ein unberechtigtes Zertifikat zumindest nachträglich sichtbar wird – über diesen Weg hat Google nach eigener Darstellung auch die weiteren Betroffenen gefunden. Zweitens: restriktive CAA-Einträge zu veröffentlichen, zusätzlich gebunden an das jeweilige Antragskonto. Ein CAA-Eintrag legt im Adressbuch des Netzes fest, welche Zertifizierungsstelle für eine Domain überhaupt ausstellen darf.
Beides begrenzt den Schaden, es verhindert ihn nicht. Auch CAA-Einträge stehen im Domain Name System – also dort, wo ein Angreifer mit Kontrolle über die Registry ebenfalls hineinreicht.
Was das für Deutschland bedeutet
Deutsche Adressen sind von diesem Vorgang nach allem, was Google mitteilt, nicht betroffen: Der Beitrag nennt ausschließlich die drei Endungen .gh, .sl und .as. Die Frage, die er aufwirft, trifft die deutsche Netzinfrastruktur trotzdem, weil sie dieselbe Bauform hat. Die Endung .de wird von der Genossenschaft DENIC verwaltet; nach deren eigener Zählung waren beim Abruf am 7. Oktober 2026 rund 18,28 Millionen .de-Domains registriert. Hinweise auf einen vergleichbaren Vorfall bei .de gibt es nicht. Hinter einer einzigen Verwaltungsstelle steht damit praktisch der gesamte deutschsprachige Webauftritt von Unternehmen, Behörden, Vereinen und Praxen.
Auf der Regelungsebene hat die Europäische Union genau diesen Punkt adressiert. In Erwägungsgrund 32 der Richtlinie (EU) 2022/2555, bekannt als NIS-2-Richtlinie, heißt es, die Richtlinie solle „für Namenregister der Domäne oberster Stufe (top-level-domain — TLD) und DNS-Diensteanbieter gelten“. Registries sind damit europarechtlich keine gewöhnlichen Dienstleister, sondern Teil der kritischen digitalen Infrastruktur – jener Bereich, in dem die deutsche Finanzaufsicht BaFin zuletzt 733 gemeldete IKT-Vorfälle verzeichnete. In Deutschland läuft die Umsetzung bereits: Die gesetzliche Registrierungsfrist für die regulierten Unternehmen ist nach Angaben des Bundesamts für Sicherheit in der Informationstechnik bereits abgelaufen.
Für Registries außerhalb der EU gilt davon nichts. Die drei betroffenen Endungen gehören zu Ghana, Sierra Leone und Amerikanisch-Samoa – und die Zertifikate, die dort erschlichen werden können, wirken trotzdem in jedem Browser in Deutschland. Das ist die eigentliche Lehre des Vorgangs: Das Vertrauensmodell des verschlüsselten Webs ist global, die Aufsicht über seine Bausteine ist es nicht.
Was Betroffene jetzt tun können
Praxishinweis
- Beim Surfen: Schutz entsteht hier allein über den Browser. Die Sperrlisten, die Google beschreibt, erreichen ein Gerät erst mit der nächsten Aktualisierung – ein veralteter Browser blockiert ein gesperrtes Zertifikat nicht. Ein eigenes Erkennungsmerkmal gibt es nicht: Das Schloss-Symbol sieht in beiden Fällen gleich aus.
- Für Betriebe mit eigenen Domains: Die beiden Empfehlungen aus dem Google-Beitrag sind unabhängig von diesem Fall sinnvoll – laufende Beobachtung der Certificate-Transparency-Protokolle und restriktive CAA-Einträge.
- Bei Adressen unter .gh, .sl oder .as: Hier lohnt der Blick in die Protokolle besonders, weil Google ausdrücklich jede Domain unter diesen Endungen als gefährdet bezeichnet.
Die Protokolle der Certificate Transparency sind öffentlich einsehbar. Für private Haushalte bleibt es dagegen bei einer unbefriedigenden Lage: Gegen ein technisch gültiges Zertifikat lässt sich mit Bordmitteln nichts ausrichten. Dass der Schutz in diesem Fall vom Hersteller des Browsers kam und nicht von einer Aufsichtsbehörde, gehört zu den Punkten, die der Vorgang offenlegt – eine Lücke, die in anderen Feldern längst zu Rufen nach einer eigenen europäischen Aufsicht geführt hat.
Was offen bleibt
Google beantwortet in seinem Beitrag die Frage, was Chrome getan hat. Es beantwortet nicht, wie die drei Registries übernommen wurden, wie lange die Angreifer Zugriff hatten, wie viele Zertifikate entstanden sind und ob mit ihnen tatsächlich Datenverkehr abgefangen wurde. Auch dazu, ob andere Browserhersteller dieselben Zertifikate sperren, steht im Beitrag nichts; Chrome-Sperrlisten gelten zunächst nur für Chrome.
Belegbar absehbar ist damit vor allem eines: Weil jedes ausgestellte Zertifikat in den Certificate-Transparency-Protokollen steht, lässt sich der Umfang des Vorfalls auch von außen weiter aufklären – und die Zahl der bekannt betroffenen Organisationen kann noch wachsen.
Wie sichern Sie Ihre eigenen Domains gegen unberechtigte Zertifikate ab – und haben Sie die Certificate-Transparency-Protokolle schon einmal geprüft? Schreiben Sie uns Ihre Meinung gerne in die Kommentare.
Quellen
- Google, Chrome Secure Web and Networking Team: „Chrome’s Response to Recent ccTLD Registry Hijacks“, 6. Oktober 2026, 11:53 Uhr UTC
- Europäische Union: Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), Erwägungsgrund 32
- Bundesamt für Sicherheit in der Informationstechnik: NIS-2-regulierte Unternehmen, abgerufen am 7. Oktober 2026
- DENIC eG: Zahl der registrierten .de-Domains, abgerufen am 7. Oktober 2026
Transparenzhinweis: Bei Recherche, Strukturierung und Erstellung dieses Beitrags kamen KI-gestützte Werkzeuge zum Einsatz. Die verwendeten Quellen sind im Artikel aufgeführt. Die Veröffentlichung erfolgt erst nach manueller redaktioneller Freigabe.
