Warum ein „Testfehler“ einer CA das Fundament verschlüsselter DNS-Verbindungen erschüttert
Ein Vorfall rund um Cloudflares populären DNS-Resolver 1.1.1.1 zeigt, wie fragil das Vertrauensmodell des öffentlichen Schlüsselinfrastruktur-Ökosystems (PKI) sein kann: Eine Zertifizierungsstelle (CA) aus Kroatien – Fina – hat zwischen Februar 2024 und August 2025 insgesamt zwölf TLS-Zertifikate ausgestellt, in deren Subject Alternative Name (SAN) die IP-Adresse 1.1.1.1 auftauchte – ohne Erlaubnis des Rechteinhabers Cloudflare. Entdeckt wurde die Serie von Zertifikaten Anfang September 2025 über Certificate Transparency (CT), woraufhin Cloudflare die Angelegenheit öffentlich machte und die betroffenen Zertifikate widerrufen wurden. Brisant: Der zugehörige Fina-Root ist im Microsoft-Root-Programm verankert, sodass Windows-basierte Clients die Kette grundsätzlich vertrauen konnten. Für Browser war die unmittelbare Gefahr begrenzt, für verschlüsseltes DNS (DoH/DoT) aber keineswegs theoretisch.
Was genau passiert ist – und warum 1.1.1.1 besonders heikel ist
Cloudflare beschreibt in seiner technischen Einordnung, dass Fina von Februar 2024 bis August 2025 zwölf Zertifikate mit 1.1.1.1 im SAN ausstellte. Die Zertifikate waren teils für ein Jahr gültig und enthielten neben 1.1.1.1 diverse Test-Domains wie testssl.finatest.hr. Interne Alarme bei Cloudflare griffen nicht, unter anderem weil IP-Zertifikate in der CT-Überwachung nicht korrekt gefiltert wurden – ein Versäumnis, das der Anbieter selbstkritisch offenlegt und abstellen will. DoH-/DoT-Clients verifizieren Resolver-Identitäten häufig über IP-basierte Zertifikate (SAN-Eintrag iPAddress), weil zu Beginn der Verbindung keine auflösbare Domain zur Verfügung steht. Damit ist ein Zertifikat auf eine Resolver-IP – hier 1.1.1.1 – ein besonders mächtiges Artefakt.
Die Sicht der CA: „interner Test“ – Widerruf und Zerstörung der Schlüssel
Fina veröffentlichte am 4. September 2025 eine Stellungnahme: Bei einem internen Test im Produktionsumfeld sei es zu einer fehlerhaften Eingabe von IP-Adressen gekommen. Man habe die Zertifikate in CT geloggt, um Unregelmäßigkeiten erkennen zu können; nach Entdeckung seien die Zertifikate widerrufen und die privaten Schlüssel direkt nach Abschluss der Tests vernichtet worden. Fina betont, dass Nutzer nicht gefährdet gewesen seien und kündigt Maßnahmen an, um derartige Fehler künftig auszuschließen. Diese Kommunikation ist wichtig – ändert aber nichts daran, dass das Ausstellen „echter“ Produktionszertifikate für fremde, globale sensible Ziele wie 1.1.1.1 ein klarer Verstoß gegen etablierte Regeln ist.
Warum das im Microsoft-Ökosystem besonders weh tut
Der Fina-Root ist im Microsoft Trusted Root Program verankert. Praktisch bedeutet das: Anwendungen, die auf den Windows-Root-Store setzen (u. a. Microsoft Edge und viele Systemkomponenten), konnten einer von Fina signierten Kette grundsätzlich vertrauen. Chrome, Firefox und Safari nutzen eigene Root-Stores (bzw. die jeweilige Programmpolitik) und vertrauten Fina nicht, weshalb die unmittelbare Angriffsoberfläche in klassischen HTTPS-Browser-Szenarien kleiner war. Für verschlüsseltes DNS unter Windows bleibt das ein relevanter Unterschied – genau hier lag die Sprengkraft der missausgestellten Zertifikate.
Vom „Papier-GAU“ zum echten Risiko: Wie ein Angriff ablaufen könnte
Cloudflare betont, dass es keine Hinweise auf eine Ausnutzung gibt und auch keine korrespondierenden Routing-Anomalien (BGP-Hijacks) beobachtet wurden. Dennoch ist das Angriffsszenario konkret: Ein Angreifer mit on-path-Position oder nach erfolgreichem BGP-Hijack präsentiert einem DoH/DoT-Client ein formal vertrauenswürdiges Zertifikat für 1.1.1.1 und kann dadurch DNS-Anfragen abgreifen oder manipulieren, bevor Tunnel und Authentizität korrekt etabliert sind. Genau diese Kombination – Routing-Manipulation plus gültige, aber unberechtigte Zertifikate – verwandelt ein Netzwerkproblem in einen echten Man-in-the-Middle. Die Gefahr ist nicht hypothetisch: BGP-Hijacks sind keine Seltenheit, und ohne strikte CT-Durchsetzung für DNS-Clients (die heute meist fehlt) bleibt die Erkennung schwierig.
Regelwerk gebrochen: CA/B-Forum-Pflichten und Certificate Transparency
Die CA/Browser-Forum „Baseline Requirements“ schreiben eine valide Kontrolle über die beantragten Identitäten vor – das gilt explizit auch für SAN-Einträge, egal ob Domainname oder IP-Adresse. Cloudflare verweist darauf, dass die Fina-Zertifikate diese Grundanforderungen verletzen. Dass die Zertifikate überhaupt entdeckt wurden, ist CT zu verdanken: Moderne Browser verlangen SCT-Belege, doch viele DNS-Clients fordern sie nicht. Genau das will Cloudflare nun adressieren, indem mehr Transparenz und Alarmierung für IP-basierte Zertifikate eingeführt wird. Die erste öffentliche Spur der Affäre waren Hinweise in der CT-Community sowie Mails auf Mozillas dev-security-policy-Liste; von dort schwappte der Vorfall in die Medien.
Wie groß war/ ist die Gefahr wirklich?
Heise ordnet die unmittelbare Gefahr für „die meisten Internetnutzer“ als gering ein – unter anderem, weil Browser nicht betroffen waren und die Zertifikate widerrufen wurden. Aber „gering“ ist nicht „null“: In Nischen- oder Unternehmens-Setups, die DoH/DoT mit Windows-Truststore nutzen, hätte eine Kombination aus on-path-Angreifer und dem Besitz des passenden privaten Schlüssels potenziell gereicht, um verschlüsselte DNS-Anfragen mitzulesen oder umzubiegen. Cloudflare schreibt, es gebe keine Anzeichen für Missbrauch; gleichwohl ist der Vorfall ein „Weckruf“, denn er zeigt, dass ein einzelnes schwaches Glied im CA-Ökosystem Auswirkungen auf globale Infrastrukturen haben kann.
Die Rolle der Root-Programme – und warum Asymmetrien wehtun
Root-Programme definieren, welchen CAs Betriebssysteme und Anwendungen vertrauen. Unterschiedliche Programmpolitiken führen zu Asymmetrien, wie das Fina-Beispiel zeigt. Microsofts Root-Programm ist oft breiter, Mozilla/Chrome/Apple agieren restriktiver. Solche Divergenzen sind an sich legitim, erhöhen aber die Komplexität und den „Blast Radius“, wenn einzelne CAs Fehler machen. Das gilt umso mehr für IP-basierte Zertifikate, die in DoH/DoT-Kontexten eine Identitätsankerrolle haben. In der Folge läuft die Diskussion nicht nur auf die Fina-Causa hinaus, sondern auch auf Governance-Fragen: Wie streng müssen Root-Programme auditieren, wie schnell müssen sie auf Vorfälle reagieren, und wie lassen sich externe Sub-CAs besser kontrollieren?
Cloudflares Selbstkritik – und was sich technisch ändern muss
Cloudflare nimmt sich selbst in die Pflicht: IP-Zertifikate sollen künftig besser überwacht und Alarme verlässlich eskaliert werden, außerdem will der Anbieter Transparenzmechanismen aus der Web-Welt auf DNS-Clients tragen. Denn während CT im Browser de facto Pflicht ist, bleibt DoH/DoT diesbezüglich oft blind. Die Lektion: Monitoring darf nicht allein auf Domainnamen fokussieren; Resolver-IPs sind hochkritische Identitätsanker und müssen in jeder CT-Pipeline besondere Aufmerksamkeit erhalten.
Was Admins und Unternehmen jetzt pragmatisch tun können
Erstens sollten Betreiber prüfen, welche Root-Stores ihre Anwendungen für DoH/DoT nutzen, und ob der Fina-Root dort als vertrauenswürdig geführt wird. In Windows-Umgebungen lässt sich der Trusted-Root-Store zentral via Gruppenrichtlinien verwalten; Unternehmen können problematische Roots temporär entvertrauen, bis Klarheit und ggf. offizielle Maßnahmen vorliegen – mit Bedacht, um keine legitimen Ketten zu brechen. Zweitens lohnt es sich, für eigene, kritische IP-Adressen und Domains CT-Monitoring mit aussagefähigen Filtern zu etablieren, die auch iPAddress-SANs abdecken. Drittens sollten DoH-Implementierungen bevorzugt Domain-basierte Endpunkte mit strikter SNI/Hostname-Validierung nutzen, wo praktikabel, und parallel RPKI/ROV in der eigenen Netzdomäne fördern, um Routing-Hijacks zu erschweren. Viertens: Härtung der Telemetrie – wer Resolver-Anomalien (Latenz, Zertifikatswechsel, SCT-Abweichungen) schneller sieht, reagiert schneller. Für Windows-Admins hält Microsoft ausführliche Dokumentation zur Verwaltung des Trusted-Root-Stores und der Programmanforderungen bereit; diese sollte als Referenz für sauber gesteuerte Ausnahmeregeln dienen.
Zeitstrahl und Einordnung
Februar 2024: Erstes Fina-Zertifikat mit 1.1.1.1-SAN, 33 Minuten später widerrufen (laut CT/Cloudflare). Mai 2025 bis August 2025: weitere Ausstellungen. 3. September 2025: Öffentliche Hinweise in CT-Foren und auf Mozillas dev-security-policy. 4. September 2025: Cloudflare veröffentlicht Analyse; Fina bestätigt Testfehler und Widerruf. Seitdem: Breite Diskussion in der Sicherheitscommunity und in den Medien – inklusive Kritik an Root-Governance und Forderungen nach CT-Pflichtsignalen in DNS-Clients.
Fazit: Ein kleiner Eintrag, ein großer Weckruf
Selbst wenn dieser Vorfall keine nachweisbaren Schäden verursacht hat: Er zeigt, dass „Testen im Produktions-PKI-Strahlengang“ nicht nur unprofessionell ist, sondern in der Kombination aus Root-Asymmetrien, IP-basierten Zertifikaten und fehlender CT-Durchsetzung im DNS-Bereich ein systemisches Risiko erzeugt. Cloudflares Bereitschaft zur Selbstkritik und zu technischen Korrekturen ist zu begrüßen. Doch nachhaltige Resilienz verlangt mehr: strengere Root-Governance, verpflichtende Transparenzsignale in DoH/DoT-Clients, bessere CT-Alarme für iPAddress-SANs – und bei allen Beteiligten die Einsicht, dass 1.1.1.1 & Co. keine „Testdaten“ sind, sondern kritische Infrastruktur.
Quellen & weiterführende Links
- Cloudflare: Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1 (04.09.2025)
- Heise: CA in der Kritik – Zertifikate für 1.1.1.1 bringen Cloudflare auf die Palme (05.09.2025)
- Fina: SSL/TLS certifikati opozvani po otkrivanju tehničke pogreške (04.09.2025)
- Mozilla dev-security-policy: Mis-issued Certificates for SAN iPAddress:1.1.1.1 by Fina RDC 2020 (03.–04.09.2025)
- Google Group „certificate-transparency“: Rogue-looking 1.1.1.1 certificate in CT Log (03.–04.09.2025)
- Ars Technica: Mis-issued certificates for 1.1.1.1 DNS service pose a threat to the Internet (03.09.2025)
- Ars Technica: The number of mis-issued 1.1.1.1 certificates grows (04.09.2025)
- Unmitigated Risk (Ryan Sleevi): Microsoft’s Root Program and the 1.1.1.1 Certificate Slip (03.09.2025)
- Microsoft Docs: Trusted Root Certification Authorities Certificate Store
- Microsoft Trusted Root Program – Program Requirements
- Cloudflare: Announcing 1.1.1.1 – Privacy-first consumer DNS (2018, Hintergrund)
Über den Autor
Letzte Aktualisierung am 5.02.2026 / Affiliate Links / Bilder von der Amazon Product Advertising API. Alle hier angezeigten Preise und Verfügbarkeiten gelten zum angegebenen Zeitpunkt der Einbindung und können sich jederzeit ändern. Der Preis und die Verfügbarkeit, die zum Kaufzeitpunkt auf Amazon.de angezeigt werden, sind maßgeblich. Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.
