ccTLD-Hijacking bei .gh, .sl und .as: Was Du jetzt an Deinen Domains prüfen solltest

Am 6. Oktober 2026 hat Googles Chrome-Team einen Beitrag mit dem nüchternen Titel “Chrome’s Response to Recent ccTLD Registry Hijacks” veröffentlicht. Ich habe ihn zweimal gelesen, weil die Kernaussage so unscheinbar daherkommt: Angreifer haben nicht Google gehackt und auch keine Zertifizierungsstelle. Sie haben die Registry-Infrastruktur von drei Länderendungen übernommen, .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa). Damit bekamen sie völlig regulär ausgestellte HTTPS-Zertifikate für google.com.gh, google.sl, youtube.as und weitere Namen.

Das Unangenehme daran: Kein Zertifikat war gefälscht. Let’s Encrypt und ZeroSSL haben genau das getan, was sie tun sollen. Sie haben geprüft, ob der Antragsteller die Domain kontrolliert, und die DNS-Antwort sagte ja. Wenn Du Domains betreust, egal unter welcher Endung, lohnt sich ein genauer Blick auf diesen Fall. Am Ende dieses Artikels weißt Du, wie Du in zehn Minuten prüfst, ob für Deine Domains Zertifikate existieren, die Du nie bestellt hast, und mit welchem DNS-Eintrag Du die Tür nach einem Angriff wieder schließt.

Was zwischen dem 22. und 27. September passiert ist

Google selbst nennt in seinem Beitrag keine Domainnamen und keine Stückzahlen. Die Details stehen trotzdem öffentlich im Netz, nämlich in den Certificate-Transparency-Logs. Jede vertrauenswürdige CA muss dort jedes ausgestellte Zertifikat eintragen.The Hacker News hat die Logs am 7. Oktober über ctlogs.dev und Cert Spotter durchsucht und mindestens zwölf Zertifikate für sieben Google- und YouTube-Domains gefunden. Elf stellte Let’s Encrypt aus, eines ZeroSSL.

Auffällig ist das Muster. Die Angreifer arbeiteten die Endungen nacheinander ab, an jedem Tag eine:

Das erste .as-Zertifikat tauchte etwa einen Tag nach dem Widerruf der .gh-Zertifikate auf. Die Angreifer haben also weitergemacht, während die Gegenseite schon reagierte. Zwischen Logeintrag und Widerruf lagen je nach Zertifikat zwischen eineinhalb Tagen und fast einer Woche.

Die zwölf Zertifikate sind nur das, was bei einer gezielten Suche nach Google-Namen auftaucht. Die australische iTnews hat die Logs mit der Chrome-Sperrliste abgeglichen und kam auf 32 Zertifikate. Google selbst schreibt laut BleepingComputer, dass auch andere bekannte internationale Marken und Onlinedienste betroffen sind, nennt aber keine Namen. Offen ist bis heute, wer hinter dem Angriff steckt, wie die Registries kompromittiert wurden und ob eines der Zertifikate tatsächlich für einen Angriff auf Nutzer eingesetzt wurde.

Wie man an ein echtes Zertifikat für eine fremde Domain kommt

Wer ein Zertifikat beantragt, muss der CA beweisen, dass er die Domain kontrolliert. Das heißt Domain Control Validation, kurz DCV. Bei Let’s Encrypt läuft das meist automatisch über das ACME-Protokoll: Die CA gibt Dir einen Zufallswert (Zeichenkette), und Du legst ihn als TXT-Record im DNS ab oder als Datei auf dem Webserver. Findet die CA den Wert, stellt sie das Zertifikat aus.

Die CA fragt dafür das DNS. Und das DNS fragt am Ende immer die Registry der jeweiligen Endung, welcher Nameserver für eine Domain zuständig ist. Wer die Registry von .sl kontrolliert, kann für google.sl einfach eigene Nameserver eintragen. Ab diesem Moment beantworten diese Server jede Frage zu google.sl, auch die der CA.

Deshalb trifft Let’s Encrypt und ZeroSSL hier keine Schuld, und das sagt auch Google ausdrücklich. Die CAs haben korrekt validiert, nur war die Antwort, die sie bekamen, manipuliert. Für Dich als Domaininhaber heißt das: Deine Domain ist nur so sicher wie die schwächste Stelle in der Kette über ihr. Bei einer .de-Domain ist das die DENIC, bei einer .as-Domain eben ein kleiner Betreiber im Pazifik.

Mit einem solchen Zertifikat kann ein Angreifer, der zusätzlich den Datenverkehr umleiten kann, eine verschlüsselte Verbindung aufbauen, bei der das Schloss im Browser ganz normal erscheint. Alles, was Nutzer dann eingeben, landet bei ihm.

Wie Chrome reagiert hat

Google hat die Zertifikate für die eigenen Domains in Chrome über CRLSets gesperrt. Das ist eine Sperrliste, die Chrome im Hintergrund aktualisiert, ohne dass Du den Browser updaten musst. Google nutzt sie für Notfälle, in denen ein normaler Widerruf zu langsam wäre.

Parallel hat Google die ausstellenden CAs kontaktiert, damit die Zertifikate offiziell widerrufen werden. Das ist der Schritt, der auch Firefox, Safari und andere Programme erreicht, zumindest wenn sie den Widerrufsstatus überhaupt prüfen. Anschließend hat das Chrome-Team die CT-Logs nach weiteren auffälligen Zertifikaten unter den drei Endungen durchsucht, auch diese in Chrome blockiert und die betroffenen Unternehmen informiert, soweit es sie erreichen konnte.

Für Chrome-Nutzer war damit nichts zu tun. Bemerkenswert ist, wie Let’s Encrypt reagiert hat: Ein Mitarbeiter bestätigte am 7. Oktober im Community-Forum der CA öffentlich, dass Zertifikate für Google und YouTube ausgestellt und inzwischen widerrufen wurden. So viel Transparenz ist bei Sicherheitsvorfällen nicht selbstverständlich.

Warum Du Dich nicht auf den Browser verlassen solltest

Google schreibt selbst sehr deutlich, dass Domaininhaber sich nicht auf Eingriffe im Browser verlassen sollen. Dafür nennt das Chrome-Team zwei Gründe. Erstens kann es nicht garantieren, bei der Auswertung wirklich jede betroffene Domain gefunden zu haben. Zweitens schützen die Sperren in Chrome Nutzer anderer Browser, Apps und Schnittstellen nicht zuverlässig.

Denk an die API, die Dein Shop-Backend bei einem Zahlungsdienstleister aufruft, an eine Smartphone-App oder an ein Monitoring-Skript per curl. Keines davon kennt Chromes CRLSets. Ob diese Clients einen Widerruf mitbekommen, hängt von ihrer Konfiguration ab, und viele prüfen ihn gar nicht.

Ein Blick zurück zeigt, wie sich die Angriffsfläche verschoben hat. 2011 wurde die niederländische CA DigiNotar gehackt, damals entstanden rund 531 betrügerische Zertifikate für *.google.com. Damals saß das Problem bei der CA, die anschließend aus allen Browsern flog.

Diesmal hat keine CA versagt, und genau deshalb liegt ein Teil der Verantwortung bei Dir.

Schritt 1: Prüf die CT-Logs für Deine Domains

Certificate Transparency ist der Grund, warum wir über diesen Vorfall überhaupt so genau Bescheid wissen. Jedes öffentlich vertrauenswürdige Zertifikat landet in diesen Logs, und jeder kann sie durchsuchen. Genau das solltest Du für Deine eigenen Domains tun.

Am schnellsten geht es mit crt.sh. Du gibst dort Deine Domain ein, für Subdomains mit vorangestelltem Prozentzeichen, also %.beispiel.de, und bekommst alle jemals geloggten Zertifikate mit Aussteller und Datum.

Einmal nachschauen reicht aber nicht. Du brauchst einen CT-Monitoring-Dienst mit automatischer Benachrichtigung, sobald ein neues Zertifikat auftaucht:

Nimm in das Monitoring wirklich alle Domains auf, auch geparkte Domains, Tippfehler-Varianten und regionale Endungen, die nur auf Deine Hauptseite weiterleiten. Gerade die ccTLD-Varianten, die Du einmal zum Markenschutz registriert und dann vergessen hast, schaut sich sonst niemand an. Betreibst Du Domains unter .gh, .sl oder .as, prüf die Einträge seit Anfang September jetzt sofort.

Findest Du ein Zertifikat, das Du nicht bestellt hast, melde es der ausstellenden CA als Certificate Problem Report. Nach den Baseline Requirements des CA/Browser Forums muss sie innerhalb von 24 Stunden erste Ergebnisse liefern.

Schritt 2: Setz restriktive CAA-Records mit Kontobindung

Mit einem CAA-Record (Certification Authority Authorization) legst Du im DNS fest, welche CAs überhaupt Zertifikate für Deine Domain ausstellen dürfen. Jede CA muss diesen Eintrag vor der Ausstellung prüfen.

Damit keine falschen Erwartungen entstehen: Während eines laufenden DNS-Hijacks hilft CAA nicht. Wer die Registry kontrolliert, kontrolliert auch, was die CA als CAA-Record zu sehen bekommt. Der Nutzen kommt danach. CAs dürfen eine erfolgreiche Domain-Validierung zwischenspeichern und für spätere Zertifikate wiederverwenden. Ein Angreifer, der während des Hijacks validiert hat, könnte also noch Wochen später neue Zertifikate bestellen, obwohl Deine DNS längst wieder sauber ist. Ein CAA-Record, der die Ausstellung an Dein eigenes CA-Konto bindet, macht diese gespeicherte Validierung wertlos.

So sieht das für eine Domain aus, die ihre Zertifikate ausschließlich über Let’s Encrypt bezieht:

beispiel.de. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"

beispiel.de. IN CAA 0 issuewild ";"

beispiel.de. IN CAA 0 iodef "mailto:security@beispiel.de"

Die erste Zeile erlaubt nur Let’s Encrypt, und dort nur Dein Konto. Der Parameter accounturi ist in RFC 8657 definiert. Die Konto-URL findest Du in der Konfiguration Deines ACME-Clients, bei Certbot etwa unter /etc/letsencrypt/accounts/. Die zweite Zeile verbietet Wildcard-Zertifikate komplett, was sinnvoll ist, wenn Du keine brauchst. Die Angreifer im aktuellen Fall haben übrigens gezielt Wildcards bestellt. Die dritte Zeile nennt eine Adresse, an die CAs abgelehnte Anträge melden können.

Zwei Dinge solltest Du vorher prüfen. Nicht jede CA unterstützt accounturi, Let’s Encrypt tut es. Und wenn Du mehrere CAs nutzt, zum Beispiel ein kommerzielles Zertifikat für den Shop und Let’s Encrypt für Subdomains, braucht jede CA eine eigene issue-Zeile, sonst bricht die nächste Verlängerung.

Wie viel Zeit ein Angreifer nach einem Hijack hätte, hängt von der Wiederverwendungsfrist ab:

Ein Detail aus den Logs hat mir gezeigt, dass Google diese Empfehlung selbst ernst nimmt. Alle sieben betroffenen Google-Domains hatten am 7. Oktober einen CAA-Record, der ausschließlich pki.goog erlaubt, also Googles eigene CA.

In der DNS-Verwaltung bei hosting.de legst Du CAA-Records wie jeden anderen Eintrag an. Beziehst Du Dein SSL-Zertifikat über uns, trage die dazugehörige CA ebenfalls in den CAA-Record ein.

Was sich am HTTPS-System ändern wird

Google kündigt an, über das Chrome Root Program weiter auf kürzere Zertifikatslaufzeiten und kürzere Wiederverwendungsfristen für Domain-Validierungen zu drängen. Dazu kommt das neu gestartete Chrome Quantum-resistant Root Program, das die Zertifikatsinfrastruktur auf Post-Quanten-Kryptografie vorbereitet. Beides verkleinert das Zeitfenster, in dem ein einmal erschlichenes Zertifikat oder eine gespeicherte Validierung nützlich ist. Am Grundproblem ändert es nichts, denn eine kompromittierte Registry liefert weiterhin gültige Validierungen.

Für Dich bedeutet die Entwicklung vor allem: Zertifikate werden häufiger erneuert, Automatisierung per ACME wird Pflicht, und ein sauber gepflegter CAA-Record mit Kontobindung muss zu dieser Automatisierung passen.

Fazit

Nach dem Lesen von Googles Beitrag habe ich zwei Dinge auf meine Liste gesetzt, und ich empfehle Dir dieselben. Richte für jede Domain, die Du besitzt, ein CT-Monitoring mit Benachrichtigung ein, auch für die vergessenen. Und setz CAA-Records, die nur Deine CA und nur Dein Konto zulassen. Beides kostet Dich eine Stunde und schützt Dich genau in dem Moment, in dem der Browser-Hersteller nicht mehr hinschaut. Wenn Dir für solche Aufgaben die Zeit im Betrieb fehlt, nimmt Dir ein Managed Cloud Server einen Teil der Administration ab.

Häufige Fragen

Was ist ein ccTLD-Hijack? Bei einem ccTLD-Hijack übernehmen Angreifer die Registry-Infrastruktur einer Länderendung wie .gh oder .sl. Sie können dann für jede Domain unter dieser Endung eigene Nameserver eintragen und so DNS-Antworten fälschen.

Waren die Zertifikate aus dem Vorfall gefälscht? Nein. Let’s Encrypt und ZeroSSL haben echte Zertifikate ausgestellt, weil die manipulierten DNS-Antworten die Domain-Validierung bestanden. Google sieht keine Schuld bei den CAs.

Muss ich als Chrome-Nutzer etwas tun? Nein. Chrome hat die unautorisierten Zertifikate per CRLSet gesperrt, und die CAs haben sie widerrufen. Andere Browser und Apps schützt das nicht in jedem Fall.

Verhindert ein CAA-Record einen DNS-Hijack? Nein. Ein CAA-Record verhindert keine Ausstellung während eines laufenden Hijacks. Er verhindert aber, dass Angreifer nach dem Ende des Hijacks gespeicherte Validierungen nutzen, um weitere Zertifikate zu bestellen.

Wie finde ich heraus, ob für meine Domain unbekannte Zertifikate existieren? Durchsuche die Certificate-Transparency-Logs, zum Beispiel mit crt.sh, und richte einen Dienst wie Cert Spotter ein, der Dich bei jedem neuen Zertifikat benachrichtigt.

Artikel von

Frederick Schiwek

Hallo! Ich bin Freddy, Autor und Mitglied des Teams von hosting.de. Mit über 20 Jahren Erfahrung im Hosting-Business schreibe ich über Technologie, das Internet und die Zukunft der digitalen Infrastruktur. Ob Domains, Hosting oder Cloud-Dienste – ich bin hier, um Einblicke und Ideen zu teilen!