High-Assurance Certificate Transparency Monitoring

EXECUTIVE SUMMARY: Internet-PKI (Public Key Infrastructure) ist ein sensibles und manchmal fragiles Ökosystem. Seit Netscape 1995 den Kern seines Vertrauensmodells entwarf, hat die weltweite Sicherheitscommunity daran gearbeitet, Bedrohungen zu erkennen, im Laufe der Zeit verschiedene Gegenmaßnahmen zu entwickeln und dabei den laufenden Betrieb der Welt rund um diese Veränderungen aufrechtzuerhalten. Red Sift ist diesem Bereich eng verbunden, erforscht den Stand der Technik beim Schutz von PKI und setzt sich für den Schutz unserer Kunden ein.

Dieses Whitepaper bietet einen tiefen Einblick in die Erfahrungen, die wir beim Aufbau von Red Sift Certificates – unserer Vorzeigelösung für das Monitoring der PKI-Posture – gesammelt haben. Wir beginnen mit einem Überblick darüber, wie auf der Welt Vertrauen organisiert wird, und führen immer komplexere Konzepte und Technologien ein, bis wir schließlich die Techniken vorstellen, die wir implementiert haben, um unseren Kunden beim Erreichen ihrer Sicherheitsziele zu helfen. Abschließend stellen wir das High-Assurance Certificate Transparency Monitoring vor, eine unverzichtbare Technik für Organisationen, die höchste öffentliche PKI-Sicherheit benötigen.

Die letzten 15 Jahre waren für das Internet in Bezug auf Transport Layer Security sehr erfolgreich. Nach Jahrzehnten der Vernachlässigung gab es entschlossene Bemühungen, Verschlüsselung korrekt umzusetzen – ein Prozess, der bis heute andauert. Es dauerte viele Jahre, aber die Engineering-Community hat das Transport Layer Protocol (TLS) modernisiert, mit zeitgemäßer Kryptografie ausgestattet, Altlasten entfernt und trotzdem Abwärtskompatibilität erhalten. Ein voller Erfolg.

Und dennoch sind öffentliche PKIs im Grunde immer noch so sicher wie eh und je.

2011 wurde die Sicherheit der kleinen niederländischen Certification Authority (CA) DigiNotar komplett kompromittiert. In den darauffolgenden Tagen wurden Hunderte von Zertifikaten für einige der weltweit bedeutendsten digitalen Assets ausgestellt. Google, Microsoft, Mozilla, Twitter … Sie haben die Wahl – für alle wurden betrügerische Zertifikate generiert.

Schlimmer noch: Diese Zertifikate wurden bei einem gezielten Netzangriff gegen rund 300.000 Nutzer eingesetzt, um Verschlüsselungen zu kompromittieren und deren Geheimnisse und Passwörter zu stehlen. Ein Angriff in dieser Größenordnung war beispiellos und wurde nie zuvor oder danach beobachtet.

Dasselbe könnte auch heute passieren, denn die grundlegenden Schwächen unseres Vertrauensmodells bestehen weiterhin.

Public Key Infrastructure (PKI) bezeichnet das Framework an Technologien, Richtlinien und Prozessen, mit denen digitale Identitäten verwaltet werden. Jedes Webangebot benötigt z. B. eine digitale Identität, die von Nutzern verifiziert werden kann, um einen sicheren verschlüsselten Zugang zu ermöglichen. Diese Identitäten bauen auf privaten Verschlüsselungsschlüsseln auf, die mit passenden öffentlichen Schlüsseln überprüft werden können. In der Praxis bündeln wir diese öffentlichen Schlüssel in Zertifikaten, die alle für die Validierung erforderlichen Informationen enthalten. Aus Sicht eines Endnutzers sind Zertifikate ein technisches Detail zur Gewährleistung von Sicherheit, doch dahinter steht ein komplexes Ökosystem, das genau diese Sicherheit garantiert.

Trotz des Begriffs „öffentlich“ müssen PKIs nicht unbedingt öffentlich sein. Jeder kann eine eigene private PKI aufbauen und beliebige Regeln durchsetzen. Weltweite Sicherheit lässt sich jedoch nur durch öffentliche PKIs erreichen, die nach klar definierten Regeln funktionieren und die jedem die Teilnahme ermöglichen. Web PKI ist eine solche öffentliche PKI – sie wird streng reguliert und von großen Browserherstellern verwaltet, um Webseiten zu schützen. Es gibt außerdem die Internet PKI, die weniger definiert ist, teils innerhalb, teils außerhalb der Web PKI funktioniert. Für unsere Zwecke spielt dieser Unterschied meistens keine Rolle, wir heben ihn nur hervor, wenn nötig.

Wie bereits erwähnt, nutzen wir an der Oberfläche digitale Zertifikate, um Zugriffe auf Websites zu authentifizieren. Das ist recht einfach: Vor dem Zugriff muss die Website ein gültiges Zertifikat vorlegen und den Besitz des entsprechenden privaten Schlüssels nachweisen. Der Ausstellungsprozess für Zertifikate ist jedoch sehr aufwändig.

Zuerst wählen wir eine Gruppe vertrauenswürdiger Organisationen, die wir Certification Authorities (CAs) nennen. Wir stellen sicher, dass sie das nötige Know-how in Netzwerksicherheit und Betrieb haben, und geben ihnen genaue Anweisungen, wie Zertifikate auszusehen haben. Die wichtigste Anforderung ist, dass digitale Zertifikate nur an rechtmäßige Eigentümer ausgegeben werden – ein Vorgang, der Validierung genannt wird.

Und hier wird es knifflig: Eine Validierung im Weltmaßstab ist nicht einfach, da Vertrauensbeziehungen von Grund auf hergestellt werden müssen. Das heute dominierende Verfahren ist der Nachweis der Kontrolle über die Infrastruktur. Praktisch bedeutet das: Wer beispielsweise ein Zertifikat für „google.com“ möchte, muss demonstrieren, dass er die Kontrolle über diese Domain innehat, z. B. durch die Veröffentlichung einer speziellen Datei auf der Website.

Dieses von Netscape in den Anfangstagen des Internets entworfene Modell erlaubte das explosive Wachstum des Web, weil es einfach anzuwenden war. Leider bringt es zwei grundlegende Schwächen mit sich:

• Die Validierung erfolgt über öffentliche Netzwerke ohne kryptografische Authentifizierung. Ein Angreifer, der den Netzwerkverkehr oder DNS manipuliert oder Netzkommunikation kapert, kann die Ausstellung unterlaufen und betrügerische Zertifikate erhalten.
• Domaininhaber haben keine Kontrolle darüber, welche Zertifikate für ihre Assets ausgestellt werden. Anders gesagt: CAs wird vertraut, ihren Job korrekt zu machen. Zwar werden sie auditiert, aber in der Praxis können viele Fehler auftreten, wie im Fall von DigiNotar. Ihr Sicherheitssystem kann gebrochen werden, menschliche Fehler oder Social Engineering können passieren, und sie können von Regierungen zu unerlaubten Handlungen gezwungen werden.

Diese Schwachstellen zu verstehen ist essenziell, wenn wir Strategien entwickeln wollen, um Angriffe zu erkennen oder zu verhindern und Schäden im Fall des Falles zu minimieren.

Wie bereits erläutert, werden Zertifikate nur nach einem erfolgreichen Nachweis der Kontrolle über den relevanten Teil der Netzwerkinfrastruktur ausgestellt. Für Domainnamen läuft dies grob wie folgt ab:

1. Für example.com wird bei einer CA ein Zertifikat beantragt
2. Die CA generiert eine lange Zufallszahl und sendet sie zurück
3. Der Antragsteller veröffentlicht die Zufallszahl auf der Klartextseite von example.com
4. Die CA überprüft, ob die Zahl über HTTP abrufbar ist
5. Die CA stellt das Zertifikat aus

Was lässt sich daraus schließen? Der Validierungsprozess ist von grundlegenden Internet-Technologien wie DNS-Auflösung, IP-Adress-Routing (via BGP-Protokoll) abhängig und setzt voraus, dass die Kommunikation nicht gekapert wird. Heutzutage ist keine dieser Grundlagen wirklich sicher und es gibt vielfältige Angriffsvektoren. Ein BGP-Angriff kann den Datenverkehr auf eine vom Angreifer kontrollierte IP umleiten. Mit DNS-Spoofing lässt sich eine Website auf einen beliebigen Server umleiten. Ein aktiver Netzangriff auf Website oder CA hat denselben Effekt.

Nun, nachdem wir wissen, wie wichtig CAs für Internetsicherheit sind: Was wissen wir tatsächlich über sie? Browserhersteller nutzen ein System namens Common CA Database (CCADB), um CAs und deren digitale Zertifikate zu überwachen, die besondere Berechtigungen zur Ausstellung von Endnutzerzertifikaten besitzen. Diese Datenbank ist öffentlich zugänglich – und ich habe sie mir kürzlich angesehen. Das habe ich herausgefunden:

• Insgesamt sind 94 CA-Organisationen in der Datenbank, die von mindestens einem der vier großen Hersteller (Apple, Google, Microsoft oder Mozilla) akzeptiert werden.
• Davon werden 39 Organisationen von allen vier Herstellern akzeptiert.
• Die 94 Organisationen verteilen sich auf 42 Länder.
• Die kleinere Gruppe von 39 Organisationen stammt aus 22 Ländern.

Was lässt sich daraus ableiten? Zum einen gibt es durch die schiere Anzahl an Organisationen eine große Angriffsfläche. Unsere Sicherheit hängt davon ab, dass sämtliche CAs immer korrekt arbeiten und keine Fehler begehen. Zudem erzeugt die globale Verteilung der CAs über viele Länder sowohl theoretische als auch praktische Risiken für politischen Missbrauch.

Diese Schwächen sind nicht nur theoretisch. Tatsächlich sind sämtliche beschriebenen Szenarien bereits eingetreten.

• 2011 wurde die Sicherheit der CA DigiNotar vollständig kompromittiert, hunderte gefälschte Zertifikate wurden ausgestellt.
• 2021 wurde eine fehlerhafte Nameserver-Konfiguration der .cd Top-Level-Domain entdeckt, mit der ein Forscher 50 % des gesamten .cd-DNS-Traffics (inklusive Subdomains) umleiten konnte.
• 2022 führten Angreifer einen BGP-Angriff auf KLAYswap (eine koreanische Kryptobörse) durch und erbeuteten Kryptowährungen im Wert von 2 Millionen US-Dollar.
• 2023 wurde der Netzwerkzugang zum "jabber.ru"-Webserver angeblich von Strafverfolgungsbehörden in Deutschland gehijackt; so konnte ein Zertifikat ausgestellt werden, mit dem sämtlicher verschlüsselte Zugriff entschlüsselt wurde.
• 2024 wurde erstmals die Aktivität der Salt Typhoon-Spionagegruppe entdeckt; sie soll die Netzwerkkonnektivität von 60 Organisationen in 80 Ländern kompromittiert haben.
• 2025 stellte sich heraus, dass die Fina CA zwölf Zertifikate für die IP-Adresse 1.1.1.1 (Eigentum von Cloudflare) ohne Genehmigung ausgestellt hatte – über 16 Monate hinweg.

Diese Beispiele sind nur eine Auswahl dessen, was wir wissen. Jedes davon verdeutlicht einen bestimmten Angriffsvektor. Wahrscheinlich gab es weitere ähnliche Attacken, die noch unentdeckt sind.

Nach dem DigiNotar-Angriff 2011 wurden viele Vorschläge gemacht, wie sich die Sicherheit öffentlicher PKIs verbessern ließe. Grundlegende Veränderungen im Vergabeverfahren scheiterten, während inkrementelle Verbesserungen wie das Konzept der Certificate Transparency (CT) erfolgreich waren. Hilfreich war, dass die Initiative von Google ausging, das mit seinem Chrome-Browser großen Markteinfluss hatte.

Das Ziel von CT ist es, wie der Name sagt, dem Web-PKI Ökosystem vollständige Sichtbarkeit bei der Zertifikatsausstellung zu geben. Können wir die Grundlagen des Vertrauensmodells (keine technischen Kontrollen über CAs) nicht ändern, konzentrieren wir uns wenigstens darauf, CA-Aktivitäten transparent zu machen.

Mit CT wird Web PKI um CT-Logs erweitert, die als Auditoren fungieren. Vor der Ausstellung eines Zertifikats müssen dessen wesentliche Informationen in mehreren unabhängig betriebenen CT-Logs erfasst werden. Für jede beobachtete Zertifikatsausstellung geben CT-Logs Bestätigungen in Form digitaler Signaturen zurück. Zum Schluss werden diese Signaturen im Zertifikat selbst eingebettet.

Dieser letzte Schritt macht das System wirksam: Da jetzt alle Zertifikate Belege für ihre Aufnahme in CT-Logs enthalten, können Browser die Validierung daraufhin erweitern und jegliche Zertifikate ablehnen, deren CT-Nachweis fehlt. Somit dürfen nur öffentlich protokollierte Zertifikate für Websites verwendet werden.

Hinweis: Hier ist die Unterscheidung zwischen Web PKI und Internet PKI entscheidend. Certificate Transparency ist derzeit nur in der Web PKI umgesetzt und wird von Browsern durchgesetzt. Zertifikate ohne CT-Informationen sind immer noch gültig, funktionieren jedoch nur außerhalb von Websites (Internet PKI). Das könnte sich in Zukunft ändern.

CT ist seit 2018 praktisch verpflichtend. Chrome war der erste Browser, der dies forderte, was aufgrund der Marktmacht bereits ausreichte. Apple, Microsoft und Mozilla folgten später. Die durch CT gewonnene Sichtbarkeit ermöglichte weltweites Monitoring der Zertifikatsausstellung und fortlaufende Optimierungen – ein enormer Fortschritt.

Hinweis: Die technischen Spezifikationen zur Zertifikatsausstellung werden durch ein Branchenforum namens CA/Browser Forum reguliert. Browserhersteller und CAs legen gemeinsam das Verfahren fest, wobei die Browser bestimmen, welchen CAs sie vertrauen – die Machtverhältnisse sind also klar geregelt.

Wie bereits gesehen, ist Certificate Transparency ein wertvolles Werkzeug zur Überwachung des globalen Ökosystems. Es ermöglicht aber auch Domaininhabern, die Zertifikatsausstellung für ihre Domains zu überwachen. Aufgrund der zuvor beschriebenen Schwächen in der öffentlichen PKI ist es möglich, dass Dritte – ob böswillig oder nicht – Zertifikate für fremde Domains beantragen. Mit CT kann jeder für jede Domain Zertifikate überwachen.

Organisationen, die sich vor unbefugten Zertifikatsausstellungen schützen möchten, setzen CT-Monitore ein, um den weltweiten Zertifikatsstrom zu analysieren und für sie relevante Ausstellungen zu erkennen. Das eröffnet zwei spannende Möglichkeiten:

• Domaininhaber können eigene Zertifikate überwachen, um Ausstellungsstellen und Muster zu analysieren und zu verstehen, welche CA von wem genutzt werden.
• Zudem lassen sich unautorisierte Zertifikate identifizieren. Kurz: CT ermöglicht die Erkennung fehlerhaft ausgestellter Zertifikate.

Das aktuelle Certificate Transparency bietet keine vollständige Transparenz über alle Zertifikatsausstellungen weltweit. Grund: Nicht alle Anbieter verlangen die Veröffentlichung von CT im Rahmen ihrer Root Store Policy. Aktuell sieht es folgendermaßen aus:

• Apple fordert CT für alle Zertifikate, sowohl im Browser als auch in weiterer Apple-Software
• Chrome von Google verlangt CT für alle Websites
• Microsoft Edge basiert auf Chromium und verlangt CT
• Mozilla Firefox verlangt ebenfalls CT

Da CT nicht durch Baseline Requirements gefordert wird und Root-Store-Policies nicht vorschreiben, dass alle vertrauenswürdigen CAs alles an CT melden, existieren ausnutzbare Schlupflöcher. Technisch ist die Veröffentlichung in CT nicht verpflichtend. Viele CAs melden standardmäßig an CT, manche bieten ein Opt-out. Zudem könnten sie gesetzlich gezwungen sein, außerhalb von CT zu veröffentlichen.

Solche Zertifikate sind für Websites zwar ungültig, können in manchen Fällen aber trotzdem akzeptiert werden:

• API-Anfragen (außer von Apple-Plattformen)
• Server-zu-Server-Kommunikation, z. B. für E-Mail-Austausch oder XMPP

Wir erwarten, dass CT künftig für alle öffentlichen Zertifikate obligatorisch wird. Bis dahin sollten Sie die Einschränkungen kennen und Ihre Threat Models entsprechend anpassen.

Certification Authority Authorization (CAA) ist ein Standard, der Domaininhabern ermöglicht, die Ausstellung von Zertifikaten für ihre Assets zu kontrollieren. CAA-Policies werden im Domain Name System (DNS) mittels CAA-Resource-Records hinterlegt. Geboten werden u. a. folgende Funktionen:

• Steuerung, welche CAs ausstellen dürfen
• Separate Kontrollen für Standard-, Wildcard-, E-Mail- und BIMI-Zertifikate
• Möglichkeit, fein abgestufte Richtlinien je CA zu kommunizieren
• Bereitstellung von Kontaktinformationen für eventuelle Problemfälle

Ein Beispiel für eine solche Konfiguration:

example.com.  CAA     0 issue "letsencrypt.org"
example.com.  CAA     0 issuewild "digicert.com"
example.com.  CAA     0 issuewild "sectigo.com"
example.com.  CAA     0 issuemail ";"
example.com.  CAA     0 issuevmc ";"
example.com.  CAA     0 iodef "pki@example.com"

CAA greift unmittelbar vor der Ausstellung. Sie wird nicht durch einen starken Kontrollmechanismus durchgesetzt, wurde aber per Baseline Requirements für alle CAs verpflichtend gemacht. Jede Ausstellung, die die CAA-Konfiguration des Besitzers ignoriert, gilt als fehlerhafte Ausstellung.

Kernfunktion von CAA ist die Möglichkeit, festzulegen, welche CAs welche Zertifikate ausstellen dürfen. Gibt es keine CAA-Policy, sind alle CAs und Zertifikattypen erlaubt. Gibt es zumindest eine Anweisung (z. B. „issue“ für Standardzertifikate oder „issuemail“ für S/MIME), dürfen nur die genannten CAs ausstellen. Ist lediglich ein Semikolon gesetzt, ist jegliche Ausstellung untersagt.

Das obige Beispiel verdeutlicht Folgendes:

• Let's Encrypt darf Standardzertifikate ausstellen
• DigiCert und Sectigo dürfen Wildcard-Zertifikate ausstellen
• Niemand darf S/MIME- oder BIMI-Zertifikate ausstellen
• Unter „pki@example.com“ können Probleme gemeldet werden

Die „issue“- und „issuewild“-Tags arbeiten zusammen. Nur „issue“ erlaubt sowohl Standard- als auch Wildcard-Zertifikate. Ist „issuewild“ gesetzt, kontrolliert dieses ausschließlich die Ausstellung von Wildcard-Zertifikaten.

CAA ist flexibel in der Platzierung – jede Domain kann anders konfiguriert werden. Fehlt auf einer Subdomain eine CAA-Regel, gilt die des übergeordneten Namens (sofern vorhanden).

Wir haben erklärt, wie die Einschränkung der CAs funktioniert – aber warum ist das nützlich? Dieser Schritt reduziert tatsächlich die Angriffsfläche. Es gibt zahlreiche Schwächen in der Organisation öffentlicher PKIs, darunter die Vielzahl an CAs, die für eine Domain ausstellen dürfen – und alle müssen stets korrekt arbeiten.

Tatsächlich arbeiten die meisten Organisationen nur mit wenigen CAs. Alle anderen stellen potenzielle Risiken dar. Durch den Einsatz von CAA wird diese Gefahr minimiert.

In der Praxis empfiehlt sich folgendes Vorgehen:

1. Alle eigenen Domains zusammenstellen
2. Mit CT eine Übersicht aller öffentlichen Zertifikate erstellen
3. CT eine Zeit lang überwachen und eingesetzte CAs erfassen
4. CAA so konfigurieren, dass nur die verwendeten CAs ausstellen dürfen

Mit diesem Ansatz lässt sich das Risiko im PKI-Ökosystem mit geringem Aufwand signifikant senken, ohne bestehende Ausstellungsprozesse zu stören. Die gewünschte Konfiguration muss für jede Domain gesetzt werden. Je nach Sicherheitsbedürfnis kann eine einheitliche Liste oder eine pro Domain differenzierte Liste gepflegt werden.

Hinweis: DNS wird häufig genutzt, um Dritten eingeschränkte Kontrolle zu erlauben, z. B. für Managed Services auf der eigenen Domain. Dies erfolgt meist per CNAME-Record. Eine CAA-Policy auf der Hauptdomain bricht die Zertifikatsausstellung durch Dritte nicht, selbst wenn diese eine andere CA nutzen. Denn CNAME gibt die komplette DNS-Verwaltung ab – inkl. CAA-Policy. Wichtig: Die Dritten müssen CAA kennen und eine für sie passende CAA-Policy konfigurieren.

Der CAA-Standard ist ein guter Ausgangspunkt, reicht aber nicht für Unternehmen mit besonders schützenswerten Properties. Denn CAA schränkt zwar ein, welche CAs ausstellen dürfen, verhindert aber nicht, dass andere Kunden dieser CAs Zertifikate beziehen. Das Problem verschärft sich, weil praktisch jeder weltweit Let's Encrypt für kostenlose Zertifikate und Automatisierung nutzt – die Einstiegshürde ist minimal.

Hier kommen die ACME-CAA-Erweiterungen ins Spiel. ACME steht für Automatic Certificate Management Environment und ist der Standard für die automatisierte Zertifikatsausstellung, eingeführt von Let's Encrypt 2015 und inzwischen von allen CAs übernommen. RFC 8657 standardisiert zwei zusätzliche Funktionen an der Schnittstelle zwischen ACME und CAA:

• Einschränkung, von welchen CA-Kundenkonten ausgestellt werden darf
• Einschränkung, welche ACME-Validierungsmethoden zulässig sind

Zum Zeitpunkt dieses Texts ist RFC 8657 noch nicht verpflichtend, es wird aber erwartet, dass sich dies bald ändert. Bisher unterstützt nur Let's Encrypt offiziell diese Erweiterungen. Im Unterschied zur Basis-CAA müssen diese Erweiterungen nicht von allen CAs übernommen werden, sondern lediglich von denen, mit denen Sie zusammenarbeiten. Fragen Sie Ihre CA nach proprietären Alternativen mit ähnlicher Funktionalität.

Mit RFC 8657 können Sie für einen Domainnamen einen CA-Anbieter freigeben, aber so, dass nur das genannte Kundenkonto dieser CA für die Domain Zertifikate beziehen darf. Am Beispiel von Let's Encrypt sieht das so aus:

example.com.  CAA  0  issue "letsencrypt.org;
                             accounturi=https://acme-v02.api.
                             letsencrypt.org/acme/acct/1726001367"

Solange obige Konfiguration gilt, kann nur das Konto „1726001367“ bei Let's Encrypt Zertifikate für die Domain „example.com“ beziehen. Sollten mehrere Konten erforderlich sein, sind mehrere CAA-Tags mit jeweils anderer Kontonummer möglich.

Die zweite RFC-8657-Funktion besteht darin, einzuschränken, welche Validierungsmethoden bei ACME vor der Zertifikatsausstellung zulässig sind. ACME unterstützt verschiedene Methoden, und Kunden können normalerweise wählen. Die beliebteste Methode ist der Besitznachweis – eine Antwort auf die Herausforderung der CA wird auf der Zielwebsite veröffentlicht.

Diese Methode ist praktisch, weil jede Zielmaschine direkt Zertifikate bei der CA anfordern kann. Aus Sicherheitsgründen ist dies jedoch kritisch – wer eine Zielmaschine kontrolliert, kann Zertifikate für beliebige auf sie zeigende Domains erhalten.

Dies lässt sich etwa über eine hängende DNS-Fehlkonfiguration ausnutzen. Für jede Domain müssen im DNS A- und AAAA-Records (IPv4/IPv6) gepflegt werden und zusätzlich der Server auf den entsprechenden IP-Adressen antworten. Wird ein Server abgeschaltet, aber der DNS-Eintrag bleibt, können andere Kunden mit der jeweiligen IP Adresse Zertifikate für die Domain anfordern – gerade bei Cloud-IPs ein typisches Problem. Es gibt weitere DNS-bedingte Angriffsvektoren mit vergleichbarer Wirkung.

Organisationen, die diese Angriffsart vermeiden möchten, können ihre Zertifikatsausstellung zentralisieren und ausschließlich die DNS-basierte ACME-Validierung erlauben. Dafür müssen alle anderen Methoden deaktiviert werden. So kann eine RFC-8657-Konfiguration aussehen:

example.com.    CAA    0    issue "letsencrypt.org;
                                   validationmethods=

                                  dns-01"

Damit darf die Zertifikatsausstellung nur durch Änderungen an der DNS-Konfiguration der betreffenden Domains genehmigt werden.

Die RFC-8657-Beschränkungen verfolgen jeweils ein ähnliches Ziel, unterscheiden sich aber im Detail. Sie sollten abwägen, was wann geeignet ist.

• Validierungsmethoden-Beschränkung ohne Authentisierung der Anfrage. Ist die Ausstellung etwa auf „dns-01“ begrenzt, können nur Parteien mit Kontrolle über das DNS die Anforderung erfüllen. Die Angriffsfläche schrumpft, aber die Anfrage selbst ist nicht authentisiert; etwaige DNS-Fehlkonfigurationen bleiben ausnutzbar.
• Kontenbeschränkung erzwingt starke Authentifizierung. Ist die Ausstellung nur für ausgewählte Konten zugelassen, ist die Anfrage von vornherein kryptografisch zu authentisieren. Bei ACME beispielsweise erzeugt das Client-Konto eine kryptografische Identität, die bei jeder Ausstellung genutzt wird. Ist die Kontenbeschränkung aktiv, wird schon mit dem ersten Schritt die Verbindung zum Konto aus der CAA-Konfiguration bewiesen.

Hinweis: Im Juni 2025 beschloss das CA/Browser-Forum (Ballot SC-085v2), dass bei CAA-Lookups und DCV (Domain Control Validation) DNSSEC validiert werden muss. Ab März 2026 ist das für alle CAs verpflichtend. Domains mit DNSSEC sind dann nicht mehr für DNS-Spoofing angreifbar.

Die in RFC 8657 definierten Erweiterungen ermöglichen es, strengere Sicherheitskontrollen für die Zertifikatsausstellung umzusetzen. Das ist aber mit Aufwand verbunden: Es kostet Zeit und Ressourcen, Prozesse entsprechend umzubauen und so abzusichern. Für sämtliche Domains eines Unternehmens ist das selten wirtschaftlich. Für besonders sensible Assets empfiehlt sich diese Vorgehensweise aber sehr wohl. Für alle übrigen reicht meist die einfache Beschränkung auf wenige CAs.

Für Ihre High-Value-Properties empfiehlt sich folgendes Vorgehen:

1. Wählen Sie zwei oder drei kompetente CAs aus. Mindestens zwei sind nötig, um Single Points of Failure zu vermeiden. Für hochwertige Assets empfiehlt sich außerdem stets ein Backup-Zertifikat. Die gewählten CAs sollten RFC 8567 unterstützen oder entsprechende proprietäre Features bieten.
2. Setzen Sie eine strikte CAA-Konfiguration auf der Hauptdomain, so dass nur die ausgewählten CAs – und konkret nur die freigegebenen Accounts – ausstellen dürfen. Dies ermöglicht starke kryptografische Validierung.
3. Überwachen Sie Ihre DNS-Konfiguration daraufhin, a) dass keine hängenden DNS-Einträge existieren und b) ob CNAME-Delegationen an Dritte erfolgen (die ggf. eigene CAA-Konfiguration setzen).

Certificate Transparency hat enorme Fortschritte beim Monitoring von CA-Aktivitäten gebracht, dennoch gibt es einige Herausforderungen:

• Es ist weiterhin möglich, öffentliche Zertifikate an CT vorbei auszustellen, wie bereits zuvor beschrieben.
• CT Monitoring ist noch nicht weit verbreitet. Trotz Verpflichtung nutzen die wenigsten Unternehmen ausreichende Ressourcen, um Zertifikatsausstellungen auf ihren eigenen Assets zu überwachen.
• Signal von Rauschen zu unterscheiden ist schwierig. Zertifikate enthalten oft zu wenige Informationen, um reguläre von betrügerisch angeforderten Zertifikaten zu unterscheiden. Fortgeschrittene Monitoring-Tools sind nötig, die den meisten Unternehmen noch nicht bekannt sind.

Auch wenn dieses Dokument das technisch Machbare aufzeigen will, erkennen wir an, dass viele Organisationen keine State-of-the-Art-Sicherheit benötigen. Selbst wer höchste Sicherheit braucht, setzt diese selten für den kompletten Domainbestand um.

Unterteilen Sie Ihre Domains in drei Gruppen, basierend auf dem Risikoprofil:

• Sehr geringes Risiko: Hier landen alle geparkten und ungenutzten Domains. Je nach Unternehmensgröße existieren davon wenige oder Hunderte. Ohne perfekte DNS-Automatisierung ist es meist nicht sinnvoll, hier weitergehende Maßnahmen zu treffen. 
• Geringes Risiko: Hierzu gehören Domains mit realen Websites oder Applikationen. Für diese sollten Sie eine einfache CAA-Konfiguration zur Einschränkung auf wenige CAs umsetzen. Diese Domains sind selten Ziel von Angriffen, entsprechend dient CAA vor allem Ihrer eigenen CA-Auswahlpolitik.
• Hohes Risiko: Hierzu zählen alle sensiblen Assets – etwa Websites und Anwendungen für Finanzen, Behörden, Kommunikation oder überall dort, wo aktive Netzwerkangriffe zu erwarten sind. Dieser Gruppe sollten sämtliche technischen Schutzmaßnahmen zuteilwerden.

High-Assurance CT Monitoring ist ein Ansatz, bei dem Sie mit hoher Sicherheit einen Strom von Zertifikaten aus Certificate Transparency überwachen und dabei zwischen Zertifikaten unter Ihrer Kontrolle und solchen von unbefugten Dritten unterscheiden.

Konzeptionell ist der Ansatz einfach und basiert darauf, bekannte „gute“ Zertifikate abzugleichen – alles andere ist potenziell „schlecht“:

1. Halten Sie ein Inventar aller Zertifikate vor, die nachweislich unter Ihrer Kontrolle stehen
2. Überwachen Sie Certificate Transparency auf Ihnen unbekannte Zertifikate

Mehr ist nicht nötig. Zwei Schritte – allerdings erfordert Schritt eins durchaus Aufwand, je nach Stand Ihrer Abläufe. Dies sollten Sie ohnehin nur für besonders schützenswerte (high-risk) Assets tun, nicht für die Gesamtheit.

• Arbeiten Sie mit einem Certificate Lifecycle Management (CLM) Tool oder ACME mit einer kommerziellen CA, gibt es meist ein eingebautes Zertifikatsinventar. Der Export ist in der Regel unkompliziert, erfordert aber Programmierung gegen die jeweilige API.
• Nutzen Sie ACME mit einer freien CA (z. B. Let's Encrypt), gibt es evtl. kein zentrales Inventar. Dann braucht es eine eigene Lösung, um ausgestellte Zertifikate zu sammeln und zentral abzuspeichern. Sind alle Zertifikate von einem Server ausgestellt, ist das einfach – andernfalls erfordert es etwas mehr Aufwand, bleibt aber machbar.

Meist werden Sie ein separates Datenbanksystem pflegen müssen, in dem Sie Ihre eigenen Zertifikate erfassen. Zentralisierte Ausstellung ist in der Praxis selten, v. a. in großen Organisationen. Spezielle Situationen wie PKI-Delegation an Dritte sind ebenfalls zu berücksichtigen. Perfektes Monitoring erfordert die Anbindung verschiedener Datenquellen für den vollständigen Überblick.