Chrome blockierte die unberechtigten Zertifikate für Googles Domains über CRLSets, den Mechanismus des Browsers, um Zertifikate im Notfall schnell zu sperren. Zusätzlich arbeitete Google mit den ausstellenden Zertifizierungsstellen (CAs) zusammen, um die Zertifikate widerrufen zu lassen – ein Schritt, der Nutzer anderer Browser und Anwendungen schützen soll.

Google nannte die betroffenen Domains nicht. Die öffentlichen Certificate-Transparency-Logs (CT), in denen von CAs ausgestellte Zertifikate protokolliert werden, weisen mindestens zwölf Zertifikate aus, die zwischen dem 22. und 27. September für Google- und YouTube-Namen unter den drei ccTLDs ausgestellt wurden, darunter google.com.gh, google.sl und google.as.

Eine CA stellt ein Zertifikat aus, sobald der Antragsteller die Kontrolle über die Domain nachweist, etwa durch einen Eintrag im DNS der Domain. Die Angreifer veränderten während der Übernahmen die autoritativen DNS-Einträge; Google sieht keinen Anlass zu der Annahme, dass die CAs fehlerhaft gehandelt hätten.

Was die Zertifikatslogs zeigen

Die zwölf Zertifikate, aufgefunden am 7. Oktober über die CT-Suchdienste ctlogs.dev und Cert Spotter, verteilen sich auf sieben Domains. Elf davon stellte Let’s Encrypt aus, eines ZeroSSL. Die Protokollierung erfolgte an drei Tagen, jeweils für eine ccTLD: .gh am 22. September, .sl am 25. September und .as am 27. September.

Alle zwölf sind domainvalidierte Zertifikate, also solche, die nach einer Prüfung der Domainkontrolle ausgestellt werden. In den eingesehenen Einträgen, die mindestens bis zum 10. September zurückreichen, stammte jedes andere Zertifikat für google.com.gh, google.sl und google.as von Google Trust Services, der hauseigenen CA des Konzerns.

“Ja, es wurden Zertifikate für Google und YouTube ausgestellt, und sie wurden widerrufen”, schrieb Matthew McPherrin, Mitarbeiter von Let’s Encrypt, am 7. Oktober im Community-Forum der CA auf die Frage eines Nutzers, ob während der Hijacks Let’s-Encrypt-Zertifikate ausgestellt worden seien.

Gesucht wurde nur nach einer kleinen Auswahl von Google- und YouTube-Namen, die tatsächliche Zahl könnte also höher liegen. Google erklärte, die CT-Daten wiesen auch auf weitere Organisationen hin, die nach Einschätzung des Unternehmens von denselben Angriffen betroffen waren, darunter bekannte globale Marken und weit verbreitete Onlinedienste. Namen nannte Google nicht.

Umfang der Reaktion

Am 7. Oktober wiesen die Einträge von Cert Spotter alle zwölf Zertifikate als widerrufen aus. Die beiden .gh-Zertifikate und das ZeroSSL-Zertifikat wurden am 26. September widerrufen, die übrigen neun am 1. Oktober. Der kürzeste Abstand zwischen dem ersten Logeintrag eines Zertifikats und seinem Widerruf betrug etwa anderthalb Tage, der längste knapp eine Woche. Das erste .as-Zertifikat wurde am 27. September protokolliert, rund einen Tag nach dem Widerruf der .gh-Zertifikate.

Google erfuhr nach eigenen Angaben in der Woche vor der Veröffentlichung vom 6. Oktober von den Übernahmen und reagierte sofort. Daten zu den Hijacks selbst oder zu den eigenen Maßnahmen nannte das Unternehmen nicht. In Chrome blockierte Google auch die Zertifikate, die es für andere Organisationen fand, und kontaktierte diese Organisationen, soweit möglich.

Chrome-Nutzer müssen laut Google nichts unternehmen. Domaininhaber sollten sich jedoch nicht darauf verlassen, dass der Browser ihre Nutzer schützt. Da DNS-Hijacks komplex seien, “können wir nicht garantieren, dass unsere Analyse jede betroffene Domain erfasst hat”, schrieb das Chrome Secure Web and Networking Team; die Sperren in Chrome schützten Nutzer anderer Browser nicht zuverlässig.

Ob eines der Zertifikate tatsächlich genutzt wurde, um sich als Google-Website auszugeben oder Nutzerdaten mitzulesen, geht aus Googles Veröffentlichung nicht hervor. Auch Angreifer, Vorgehen bei der Kompromittierung der ccTLDs und deren aktueller Sicherungsstand bleiben offen.

Was Domaininhaber tun sollten

Google nennt zwei Schritte, die Regeln der CAs erlauben einen dritten:

  • CT-Logs für jede eigene Domain beobachten, einschließlich geparkter Domains und regionaler ccTLD-Namen. CT-Monitoring-Dienste alarmieren bei jeder Zertifikatsausstellung. Wer eine Domain unter .gh, .sl oder .as betreibt, sollte die jüngsten Logeinträge auf nicht angeforderte Zertifikate prüfen.
  • Einen strikten CAA-Eintrag veröffentlichen. Ein CAA-Eintrag ist ein DNS-Record, der die zur Ausstellung berechtigten CAs benennt und von der CA vor der Ausstellung geprüft werden muss. Google empfiehlt, den Eintrag an das eigene Konto bei der CA zu binden – was nur funktioniert, wenn die CA diese Option unterstützt.
  • Nicht angeforderte Zertifikate der ausstellenden CA melden. Nach den Baseline Requirements kann jeder einen Certificate Problem Report einreichen; die CA muss den Fall untersuchen und innerhalb von 24 Stunden erste Ergebnisse berichten.

Ein CAA-Eintrag kann die Ausstellung während eines laufenden DNS-Hijacks nicht verhindern: Wer den Eintrag entfernen oder einen falschen einfügen kann, erhält laut CAA-Standard dennoch ein Zertifikat. Seine Wirkung entfaltet der Eintrag, sobald der Inhaber die DNS-Kontrolle zurückhat. Denn CAs dürfen eine abgeschlossene Domainprüfung für spätere Zertifikate wiederverwenden – ein Angreifer, der die Prüfung während des Hijacks bestanden hat, könnte also auch danach weitere Zertifikate anfordern, so Google. Ein strikter CAA-Eintrag unterbindet das.

Die Baseline Requirements erlauben derzeit eine Wiederverwendung der Domainprüfung für bis zu 200 Tage. Nach einem im April 2025 vom CA/Browser Forum, dem Zusammenschluss von CAs und Browserherstellern, beschlossenen Zeitplan sinkt die Grenze im März 2027 auf 100 Tage und im März 2029 auf zehn Tage. Let’s Encrypt erklärte im Dezember 2025, man verwende eine Domainprüfung 30 Tage lang wieder und plane eine Verkürzung auf sieben Stunden bis 2028.

Jede der sieben Domains trug am 7. Oktober einen strikten CAA-Eintrag: Google Public DNS lieferte für jede von ihnen einen Record, der ausschließlich pki.goog nennt, die Domain von Google Trust Services.

Zertifikats-Fingerabdrücke

Jedes Zertifikat lässt sich über seinen SHA-256-Fingerabdruck in einem CT-Suchdienst nachschlagen:

  • 0357032e1214ae11d7da8e00f6b89fb7694e240b17d05f2f47feaf43e96aa7d8
  • 8886ca2b71501a6729f1ae868bd7d7b9b53c5cb6b5c7d851d041db4d6206945d
  • 986d36b1c68c3e800596c4680dd6c67c42118955e08b472f641793c59dcd347b
  • 2e1f6d7f24650b0720636efe48f2ccf59704ee6f11ffa52b5a4c4afcc474fe91
  • e1667fe4e4ea98427960ea2eda7c53af1246ec58ac22282a6877d394a0957065
  • e1e4fd74f673f1df9c039ae6424b36868a0475a043abea2dedd1f6f12a365ebf
  • 5b7c491c8784eb438b1634981f1ea6333d3557431268233c2a7a92173ca17122
  • a10d3b5dbc142d040e6ae772ab41dc44b0e94659237709d1241fdefdd36f7b35
  • 491f453d208bbb7923626c208df93c95fdfae3b78b738b996c8dafda9d00619a
  • 798079c762496d26ce99d3a9113cb24715e31ec8a69a6cdcffa70f5001e19df0
  • 607afd2745b84c4332e028262937be35f25316aadf584340269d23a3dbcd37ef
  • b7ea8c77695cf9791a9d45f17c33ebb9bd5f68d4c96df6f56136dc6a834576d2