Letzte Aktualisierung: 5. Januar 2025

EXECUTIVE SUMMARY: Internet PKI (Public Key Infrastructure) ist ein sensibles und manchmal fragiles Ökosystem. Seit Netscape 1995 den Grundstein seines Vertrauenssystems entwickelt hat, arbeitet die globale Sicherheits-Community daran, die Bedrohungen zu verstehen und verschiedene Gegenmaßnahmen zu entwickeln, während sich die Welt parallel zu diesen Veränderungen weiterentwickelte. Red Sift ist in diesem Bereich stark engagiert, erforscht den Stand der Technik im PKI-Schutz und setzt sich für die Sicherheit unserer Kunden ein.

Dieses Whitepaper bietet einen tiefen Einblick in die Erfahrungen, die wir beim Aufbau von Red Sift Certificates, unserer führenden Lösung für das Monitoring der PKI-Landschaft, gesammelt haben. Wir starten mit einer Übersicht darüber, wie weltweit Vertrauen organisiert wird, und führen zunehmend komplexere Konzepte und Technologien ein, bis wir schließlich die von uns entwickelten Techniken vorstellen, mit denen wir unsere Kunden beim Erreichen ihrer Sicherheitsziele unterstützen. 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 die Transportschichtsicherheit sehr erfolgreich. Nach jahrzehntelanger Vernachlässigung gab es gezielte Anstrengungen, Verschlüsselung richtig einzusetzen – Bemühungen, die bis heute andauern. Es dauerte viele Jahre, aber die Engineering-Community arbeitete daran, das Transport Layer Protocol (TLS) mit moderner Kryptografie zu erweitern, Altlasten zu entfernen und gleichzeitig die Abwärtskompatibilität zu erhalten. Ein voller Erfolg.

Und dennoch sind öffentliche PKIs im Grunde genommen noch genauso sicher wie zuvor.

2011 wurde eine kleine niederländische Certification Authority (CA) namens DigiNotar kompromittiert und ihre Sicherheit vollkommen unterlaufen. In den darauffolgenden Tagen wurden Hunderte von Zertifikaten für einige der wichtigsten Properties weltweit ausgestellt. Google, Microsoft, Mozilla, Twitter … Sie können sich einen aussuchen – für alle wurden betrügerische Zertifikate ausgestellt.

Noch schlimmer war, dass diese Zertifikate gegen etwa 300.000 Benutzer bei einem aktiven Netzwerkangriff eingesetzt wurden, der die Verschlüsselung kompromittieren und deren Geheimnisse sowie Passwörter abgreifen sollte. Ein Angriff dieses Ausmaßes war beispiellos; so etwas wurde zuvor und seither nicht mehr in dieser Größe beobachtet.

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

Public Key Infrastructure (PKI) bezeichnet das Rahmenwerk von Technologien, Richtlinien und Verfahren, die zur Verwaltung von digitalen Identitäten eingesetzt werden. Zum Beispiel benötigt jede Website eine digitale Identität, die von Nutzern überprüft werden kann, um einen sicheren verschlüsselten Zugriff zu gewährleisten. Diese Identitäten basieren auf privaten Verschlüsselungsschlüsseln, die mit passenden öffentlichen Schlüsseln überprüft werden können. In der Praxis werden diese öffentlichen Schlüssel in Zertifikaten zusammengefasst, die alle nötigen Informationen zur Validierung enthalten. Für Endnutzer sind Zertifikate ein technisches Detail, das Sicherheit garantiert – aber dahinter steht ein komplexes Ökosystem, das für die notwendige Sicherheit sorgt.

Trotz des Begriffs „öffentlich“ müssen PKIs nicht öffentlich sein. Jeder kann seine eigene private PKI erstellen und eigene Regeln aufstellen. Globale Sicherheit lässt sich jedoch nur durch öffentliche PKIs gewährleisten, die auf klar definierten Regeln basieren und jedem die Teilnahme ermöglichen. Web PKI ist ein Beispiel dafür – sie wird streng reguliert und von großen Browserherstellern verwaltet, um Websites zu schützen. Es gibt auch die Internet PKI, die weniger definiert ist, teilweise mit Web PKI zusammenarbeitet und manchmal unabhängig davon funktioniert. Für unsere Zwecke ist dieser Unterschied meist nicht relevant, wir weisen aber bei Bedarf darauf hin.

Wie bereits erwähnt, dienen digitale Zertifikate an der Oberfläche zur Authentifizierung des Zugriffs auf Websites. Das ist recht einfach: Bevor Sie auf Ihr Ziel zugreifen können, muss die Website ein gültiges Zertifikat vorlegen und den Besitz des entsprechenden privaten Schlüssels nachweisen. Der Prozess zur Ausstellung von Zertifikaten ist jedoch sehr vielschichtig.

Zunächst wählen wir eine Gruppe vertrauenswürdiger Organisationen, die wir Certification Authorities (CAs) nennen. Wir stellen sicher, dass diese Organisationen über das nötige Know-how in Bezug auf Netzwerksicherheit und Gesamtkompetenz verfügen und geben ihnen genaue Anweisungen, wie Zertifikate beschaffen sein sollen. Wichtigste Anforderung ist, dass digitale Zertifikate ausschließlich an ihre rechtmäßigen Besitzer ausgestellt werden – dies erfolgt durch ein Verfahren, das Validierung genannt wird.

Hier wird es knifflig: Eine Validierung im weltweiten Maßstab durchzuführen ist nicht einfach, da Vertrauensverhältnisse von Grund auf geschaffen werden müssen. Der heute dominierende Ansatz ist der Nachweis der Kontrolle über die Infrastruktur. In der Praxis bedeutet das: Wer ein Zertifikat für „google.com" erhalten möchte, muss nur Kontrolle über diese Domain nachweisen, z. B. durch das Veröffentlichen einer speziellen Datei auf der Website.

Dieses von Netscape in den Anfangszeiten des Internets entworfene Modell hat das explosive Wachstum des Webs ermöglicht, da es für jedermann einfach zu nutzen war. Leider gibt es dabei zwei grundlegende Schwächen:

• Die Validierung findet über öffentliche Netzwerke ohne kryptografische Authentifizierung statt. Ein Angreifer, der Routing, DNS oder die Netzkommunikation angreifen oder kapern kann, ist in der Lage, die Ausstellung zu unterlaufen und betrügerische Zertifikate zu erhalten.
• Domain-Inhaber haben keine Kontrolle darüber, für welche ihrer Properties Zertifikate ausgestellt werden. Die CAs werden als vertrauenswürdig vorausgesetzt, dass sie ihre Aufgaben korrekt erfüllen. Zwar auditieren wir sie, um ihre Kompetenz festzustellen, aber in der Praxis gibt es viele Dinge, die schiefgehen können und bereits schiefgelaufen sind. Wie am Beispiel DigiNotar zu sehen, kann ihre eigene Sicherheit kompromittiert werden. Sie können Fehler in ihrem Betrieb machen oder Opfer von Social Engineering werden, oder sie können durch ihre Regierungen zu Dingen gezwungen werden, die eigentlich nicht erlaubt sind.

Diese Schwächen zu verstehen, ist wesentlich, um Strategien zur Erkennung oder Verhinderung von Angriffen zu entwickeln und mögliche Schadensauswirkungen zu minimieren.

Wie bereits besprochen, werden Zertifikate erst nach erfolgreichem Nachweis der Kontrolle über den jeweiligen Teil der Netzwerkinfrastruktur ausgestellt. Für Domainnamen läuft der Prozess etwa so ab:

1. Ein Zertifikat für example.com wird bei einer CA angefordert
2. Die CA erstellt eine lange Zufallszahl und sendet diese zurück
3. Der Antragsteller veröffentlicht die Zufallszahl auf der unverschlüsselten example.com-Website
4. Die CA prüft, ob die Zufallszahl über HTTP sichtbar ist
5. Die CA stellt das Zertifikat aus

Was folgt daraus? Der Validierungsprozess verlässt sich auf grundlegende Internet-Komponenten wie DNS-Auflösung, IP-Adress-Routing (via BGP-Protokoll) und setzt voraus, dass die Kommunikation nicht übernommen wird. Heutzutage arbeitet keiner dieser Dienste verbindlich sicher und es gibt diverse Angriffsvektoren. Ein BGP-Angriff kann z. B. den Verkehr für eine IP-Adresse auf den Angreifer umleiten. DNS-Spoofing kann genutzt werden, um den Website-Verkehr auf eine vom Angreifer kontrollierte IP-Adresse umzuleiten. Ein aktiver Angriff auf eine der beiden Seiten (Website oder CA) kann denselben Effekt haben.

Jetzt, wo wir verstanden haben, wie wichtig CAs für die Internetsicherheit sind: Was wissen wir über sie? Browserhersteller verlassen sich auf ein System namens Common CA Database (CCADB), um CAs und deren digitale Zertifikate zu verwalten, die besondere Rechte zur Ausstellung von Endnutzerzertifikaten haben. Diese Datenbank ist öffentlich verfügbar, weshalb ich sie mir kürzlich angesehen habe. Hier meine Feststellungen:

• Es gibt 94 CA-Organisationen in der Datenbank, denen mindestens einer der vier großen Anbieter (Apple, Google, Microsoft oder Mozilla) vertraut.
• Von diesen werden 39 Organisationen von allen vier Anbietern akzeptiert.
• Die 94 Organisationen sind auf 42 Länder verteilt.
• Die kleinere Gruppe der 39 Organisationen verteilt sich auf 22 Länder.

Was kann man daraus schließen? Zunächst gibt es schon allein durch die Anzahl der Organisationen eine beträchtliche Angriffsfläche. Damit unsere Sicherheit erhalten bleibt, müssen sie alle stets alles richtigmachen und operative Fehler vermeiden. Zweitens schaffen die komplexen politischen Verhältnisse durch die Verteilung der CAs auf viele Länder sowohl theoretisch als auch praktisch Möglichkeiten für politischen Missbrauch.

Diese Schwächen sind nicht nur theoretischer Natur – es gab tatsächlich zu verschiedenen Zeiten entsprechende Vorfälle.

• 2011 wurde die Sicherheit der DigiNotar-CA komplett kompromittiert und Hunderte gefälschter Zertifikate ausgestellt.
• 2021 wurde bei der Top-Level-Domain .cd ein falsch konfigurierter Nameserver entdeckt, der es Forschern ermöglichte, 50 % des gesamten .cd-DNS-Verkehrs (inklusive Subdomains) umzuleiten.
• 2022 führten Angreifer einen BGP-Angriff auf KLAYswap, eine koreanische Kryptobörse, aus und entwendeten Krypto im Wert von 2 Mio. US-Dollar.
• 2023 wurde der Netzwerkzugang zum Webserver „jabber.ru" übernommen, angeblich von der deutschen Strafverfolgung. So konnte ein Zertifikat ausgestellt werden, mit dem sämtlicher verschlüsselter Zugriff entschlüsselt wurde.
• 2024 wurde die Aktivität der Spionagegruppe Salt Typhoon entdeckt; sie soll die Netzwerkverbindungen von 60 Organisationen in 80 Ländern kompromittiert haben.
• 2025 wurde bekannt, dass die Fina-CA in 16 Monaten zwölf Zertifikate für die IP-Adresse 1.1.1.1 (Eigentum von Cloudflare) ohne Erlaubnis ausgestellt hat.

Diese Beispiele sind nur eine Auswahl der bekannten Vorfälle. Jedes Beispiel soll einen bestimmten Angriffsvektor verdeutlichen. Es ist gut möglich, dass weitere ähnliche Angriffe unerkannt geblieben sind.

Nach dem DigiNotar-Angriff 2011 wurden zahlreiche Vorschläge gemacht, wie die Sicherheit öffentlicher PKIs verbessert werden kann. Diejenigen, die wesentliche Änderungen am Ausstellungsprozess forderten, scheiterten. Die, die auf inkrementelle Verbesserungen setzten, hatten Erfolg – so auch Certificate Transparency (CT). Das lag auch daran, dass diese Initiative von Google ausging, die mit ihrem Chrome-Browser großen Einfluss hatte.

Ziel von CT, wie der Name andeutet, ist die Erweiterung der Web PKI um Systeme, die volle Transparenz bei der Zertifikatsausstellung schaffen. Wenn wir die Grundlagen des Vertrauens nicht ändern können (es gibt keine technischen Kontrollen über die Aktivitäten der CAs), können wir zumindest fokussieren, deren Aktivitäten sichtbar zu machen.

Mit CT wird die Web PKI um CT-Logs ergänzt, die als Prüfer dienen. Bevor ein Zertifikat ausgestellt werden kann, müssen die wichtigsten Informationen in mehreren unabhängig betriebenen CT-Logs aufgezeichnet werden. Für jedes bevorstehende Zertifikat geben die CT-Logs Bestätigungen in Form von digitalen Signaturen zurück. Im letzten Schritt werden diese Signaturen in das Zertifikat selbst eingebettet.

Dieser letzte Schritt ist entscheidend: Da jetzt alle Zertifikate Nachweise ihrer Aufnahme in CT-Logs enthalten, können Browser ihre Validierung anpassen und Zertifikate ablehnen, deren Aufnahme nicht nachgewiesen werden kann. Folge: Es können nur öffentlich protokollierte Zertifikate für Websites verwendet werden.

Hinweis: Hier ist die Unterscheidung zwischen Web PKI und Internet PKI relevant. Certificate Transparency ist bisher ausschließlich Teil der Web PKI und wird von Browsern erzwungen. Zertifikate ohne CT-Informationen sind weiterhin gültig – sie funktionieren für Internet PKI-Zwecke, aber nicht für Websites. Das kann sich zukünftig ändern.

CT ist de facto seit 2018 verpflichtend. Chrome war der erste Browser, der sie verlangt hat, und aufgrund seiner Marktmacht reichte das bereits aus. Apple, Microsoft und Mozilla folgten nach. Die durch CT gewonnene Transparenz ist von großem Wert, da damit ein weltweites Monitoring der Zertifikatsausstellung möglich wurde – kontinuierliche Verbesserungen inklusive.

Hinweis: Die technischen Spezifikationen für die Zertifikatsausstellung werden vom CA/Browser Forum festgelegt – einem Zusammenschluss der Browserhersteller und CAs. Sie bestimmen gemeinsam, wie validiert und ausgestellt wird. Das Kräfteverhältnis ist nicht symmetrisch: Die Browser kontrollieren, welchen CAs sie vertrauen, und haben daher das letzte Wort.

Wie gesehen ist Certificate Transparency ein wirksames Werkzeug für das weltweite Ökosystem-Monitoring – und es ermöglicht Domain-Inhabern, die Ausstellung von Zertifikaten für ihre Properties zu überwachen. Sie erinnern sich: Die Schwächen öffentlicher PKIs erlauben Dritten – böswillig oder nicht –, Zertifikate für Domains auszustellen, die ihnen nicht gehören. Mit CT kann jeder Zertifikate für beliebige Domains überwachen.

Organisationen, die sich vor unautorisierten Aktivitäten schützen wollen, können CT-Monitore einsetzen, um den globalen Zertifikatsstrom zu analysieren und die für sie relevanten Zertifikate zu identifizieren. Daraus ergeben sich zwei spannende Möglichkeiten:

• Domain-Inhaber können ihre eigenen Zertifikate überwachen, um Vergabestellen, Muster und die von wem genutzten CAs nachzuvollziehen.
• Außerdem ist es möglich, nicht autorisierte Zertifikate zu entdecken. CT macht es möglich, falsch ausgestellte Zertifikate zu erkennen.

Certificate Transparency gewährleistet derzeit keine lückenlose Einsicht in alle Zertifikatsausstellungen weltweit. Das liegt daran, dass nicht alle Anbieter verlangen, dass Zertifikate gemäß ihrer Root Store Policy in CT-Logs veröffentlicht werden. Aktuell gilt:

• Apple verlangt CT für alle Zertifikate, sowohl im Browser als auch für andere Anwendungen, die auf deren Bibliotheken aufbauen
• Chrome von Google verlangt CT für alle Websites
• Edge von Microsoft basiert auf Chromium und verlangt CT
• Mozilla Firefox verlangt ebenfalls CT

Da CT nicht in den Baseline Requirements vorgeschrieben ist und die Root Store Policies keinen vollständigen Eintrag aller CAs verlangen, gibt es Lücken, die ausgenutzt werden könnten. Technisch gesehen ist das Veröffentlichen in CT nicht verpflichtend. Zwar protokollieren die meisten CAs standardmäßig in CT, einige bieten aber eine Opt-out-Funktion. Außerdem könnten CAs gesetzlich gezwungen werden, außerhalb von CT auszustellen.

Solche Zertifikate werden zwar für Websites ungültig sein, könnten aber in diesen Fällen akzeptiert werden:

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

Es ist zu erwarten, dass CT in Zukunft auf alle öffentlichen Zertifikate ausgeweitet wird. Bis dahin sollten Sie seine Grenzen kennen und Ihre Bedrohungsmodelle entsprechend anpassen.

Certification Authority Authorization (CAA) ist ein Standard, der Domain-Inhabern ermöglicht, die Ausstellung von Zertifikaten für ihre Properties zu kontrollieren. CAA-Richtlinien werden im Domain Name System (DNS) als CAA-Resource-Record gespeichert. Es gibt mehrere Funktionen:

• Steuerung, welche CAs ausstellen dürfen
• Separate Einstellungen für normale Zertifikate, Wildcards sowie E-Mail- und BIMI-Zertifikate
• Möglichkeit zur Formulierung feingranularer Richtlinien pro CA
• Bereitstellung von Kontaktinformationen für Rückfragen oder Vorfälle

Folgende Beispielkonfiguration:

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 wird direkt vor der Zertifikatsausstellung geprüft. Es handelt sich nicht um eine starke technische Beschränkung, wurde aber für alle CAs gemäß Baseline Requirements vorgeschrieben. Jede Ausstellung, die die CAA-Konfiguration missachtet, gilt als Fehlvergabe.

Die wesentliche Fähigkeit von CAA besteht darin, einschränken zu können, welche CAs welche Arten von Zertifikaten ausstellen dürfen. Fehlt eine CAA-Richtlinie, dürfen alle CAs und Zertifikatstypen ausstellen. Gibt es aber zumindest eine Vorgabe für einen Typ (z. B. „issue“ für Standardzertifikate oder „issuemail“ für S/MIME), dürfen nur die gelisteten CAs ausstellen. Ein einzelnes Semikolon bedeutet, dass keine Ausstellung erfolgen darf.

Entschlüsseln wir die Beispielkonfiguration:

• Let's Encrypt darf Standardzertifikate ausstellen
• DigiCert und Sectigo dürfen Wildcard-Zertifikate ausstellen
• Für S/MIME oder BIMI-Zertifikate ist die Ausstellung durch niemanden erlaubt
• Unter „pki@example.com" können Probleme gemeldet werden

Die „issue“- und „issuewild“-Tags arbeiten zusammen. Steht nur „issue“ drin, ist sowohl die Ausstellung von Standard- als auch von Wildcard-Zertifikaten erlaubt. Ist „issuewild“ enthalten, steuert dieses ausschließlich die Wildcard-Ausstellung.

CAA ist flexibel hinsichtlich des Speicherortes: Jede Domain kann eine andere Konfiguration haben. Wird auf einem Subdomain keine CAA-Konfiguration gefunden, prüft das System die CAA der übergeordneten Domain.

Vorher wurde beschrieben, wie die CAA die Ausstellung einschränkt – doch welchen Nutzen hat das? Die Einschränkung ist sehr wertvoll, weil sie die Angriffsfläche verringert. Erinnern Sie sich: Durch die Struktur der öffentlichen PKIs könnten diverse CAs Zertifikate für Ihre Properties ausstellen; jede einzelne müsste immer alles richtigmachen.

In der Praxis arbeiten die meisten Organisationen mit wenigen CAs, wodurch die übrigen zu einem Risiko werden. Mit CAA wird dieses Risiko minimiert.

In der Praxis ist folgende Herangehensweise zu empfehlen:

1. Eine vollständige Liste aller eigenen Domains erstellen
2. Mit CT ein Inventar aller öffentlichen Zertifikate erstellen
3. CT eine Weile überwachen und die genutzten CAs notieren
4. CAA gezielt auf die kurze Liste der genutzten CAs beschränken

Mit diesem pragmatischen Ansatz lässt sich das Risiko für das PKI-Ökosystem deutlich senken, ohne bisherige Zertifikatsprozesse zu gefährden. Jede Domain-Registrierung benötigt die gewünschte CAA-Konfiguration. Je nach gewünschtem Sicherheitsniveau kann eine Liste für alle Properties erstellt oder eine einschränkendere Lösung pro Domain gewählt werden.

Hinweis: DNS wird häufig genutzt, um Dritten begrenzte Befugnisse zu geben, z. B. für einen Managed Service auf der eigenen Domain. Dies geschieht meist per CNAME-Resource-Record. Das Setzen einer CAA-Policy auf der Hauptdomain sollte die Ausstellung nicht blockieren, auch wenn ein Dritter eine CA nutzt, die nicht auf Ihrer Liste steht. Denn via CNAME wird die gesamte DNS-Delegation – inklusive CAA – übertragen. Lediglich müssen Drittanbieter selbst eine für sie passende CAA setzen.

Der Kernstandard von CAA ist eine gute Basis, reicht aber für Organisationen mit hochkritischen Properties nicht aus. Eine „Lücke“ besteht darin, dass CAA zwar die CAs einschränkt, aber nicht verhindert, dass andere Dritte über zugelassene CAs Zertifikate beziehen. Verschärft wird es dadurch, dass praktisch jede Organisation Let's Encrypt für kostenlose und automatisierte Zertifikate nutzt – die Hürden sind hier extrem niedrig.

Genau hier setzen die ACME CAA-Erweiterungen an. ACME steht für Automatic Certificate Management Environment – der Standard für die automatisierte Ausstellung von Zertifikaten, populär durch Let's Encrypt seit 2015 und mittlerweile von allen CAs übernommen. RFC 8657 standardisiert zwei zusätzliche Funktionen an der Schnittstelle zwischen ACME und CAA:

• Einschränkung, aus welchen CA-Kundenkonten die Ausstellung erlaubt ist
• Einschränkung der zur Validierung erlaubten ACME-Methoden

Zum Zeitpunkt der Erstellung dieses Textes ist RFC 8657 nicht verpflichtend, es wird jedoch erwartet, dass er in naher Zukunft übernommen wird. Aktuell ist Let's Encrypt die einzige Zertifizierungsstelle (CA), die ihn offiziell unterstützt. Die Natur dieser Erweiterungen ist, dass sie – anders als das grundlegende CAA – nicht von allen CAs unterstützt werden müssen, um nützlich zu sein. Sie müssen lediglich von den CAs unterstützt werden, mit denen Sie zusammenarbeiten. Im Zweifel sprechen Sie mit Ihrer CA. Manche verfügen über proprietäre Funktionen, mit denen ein ähnlicher Effekt erzielt werden kann.

Mit RFC 8657 ist es möglich, eine Ausstellung für einen Domainnamen durch eine CA so zu erlauben, dass kein anderer Kunde derselben CA für denselben Namen Zertifikate ausstellen kann. So könnte das aussehen, wenn Sie mit Let's Encrypt arbeiten:

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

Solange das obige Konfigurationsfragment aktiv ist, kann nur das Konto „1726001367“ Zertifikate von Let's Encrypt für die Domain „example.com“ erhalten. Falls eine Ausstellung über mehrere Konten benötigt wird, können mehrere CAA-Tags konfiguriert werden, von denen jedes ein anderes Kundenkonto erlaubt.

Die andere Funktion von RFC 8657 ist, dass sie das Einschränken von Validierungsmethoden unterstützt, die von ACME genutzt werden können, bevor ein Zertifikat ausgestellt wird. ACME umfasst verschiedene Methoden, und Kunden können bei der Anforderung eines Zertifikats normalerweise ihre bevorzugte Methode wählen. Die beliebteste Validierungsmethode ist der Nachweis des Eigentums („proof of ownership“), bei der auf der Website, für die das Zertifikat benötigt wird, eine Antwort auf die Challenge der CA veröffentlicht werden muss.

Dieser Ansatz ist oft praktisch, da er es jedem beliebigen Server ermöglicht, direkt mit einer CA zu kommunizieren und selbst Zertifikate zu erhalten. Im Hinblick auf die Sicherheit ist es jedoch meist nicht ideal, Server ihre eigenen Zertifikate beschaffen zu lassen; wer immer einen Server kontrolliert, kann damit für jede auf ihn verweisende Domain Zertifikate beschaffen.

Eine Möglichkeit, eine solche Konstellation auszunutzen, ist eine dangling DNS-Fehlkonfiguration. Damit ein Domainname funktioniert, müssen an zwei Stellen Konfigurationsänderungen vorgenommen werden: Zunächst im DNS, wo A- und AAAA-Records genutzt werden, um IPv4- bzw. IPv6-Adressen zuzuweisen. Dann muss auf den gleichen IP-Adressen ein Server eingerichtet werden, der Antworten liefert. Ein dangling DNS-Problem entsteht, wenn ein Server außer Betrieb genommen, die DNS-Einträge aber nicht entfernt werden. Angenommen, die IP-Adressen stammen von einem Cloud-Anbieter, wie das häufig der Fall ist, dann kann jeder, dem diese IP-Adressen zugewiesen werden, Zertifikate für die verwaiste DNS-Domain erhalten. Dies ist nur ein Beispiel – es gibt noch andere Angriffsvektoren im DNS, die auf dieselbe Weise ausgenutzt werden können.

Organisationen, die diese Art von Problem verhindern möchten, könnten ihre Zertifikatsausstellung zentralisieren und die DNS-basierte ACME-Validierungsoption nutzen. Damit das funktioniert, müssen jedoch alle anderen Validierungsmethoden deaktiviert werden. So könnte das mit RFC 8657 aussehen:

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

                                  dns-01"

Mit dieser Konfiguration kann eine Zertifikatsausstellung nur genehmigt werden, wenn Änderungen an der DNS-Konfiguration der Domain vorgenommen werden.

Die beiden in RFC 8657 beschriebenen Beschränkungen unterstützen Einschränkungen, die sich zwar ähneln, jedoch wichtige Unterschiede aufweisen, die beeinflussen können, welche Sie wann nutzen möchten.

• Bei der Beschränkung der Validierungsmethode ist keine Authentifizierung der Anfrage erforderlich. Wird die Ausstellung auf eine Methode wie „dns-01“ beschränkt, können nur diejenigen, die Ihr DNS (oder relevante Teile davon) kontrollieren, die CAA-Konfiguration erfüllen. Das reduziert die Angriffsfläche, aber auch hier wird die Ausstellung selbst nicht authentifiziert. Beispielsweise könnte weiterhin eine DNS-Fehlkonfiguration ausgenutzt werden.
• Die Kontobeschränkung erzwingt eine starke Authentifizierung. Wird die Ausstellung auf ein bestimmtes Kundenkonto beschränkt, wird damit automatisch eine starke Authentifizierung der Anfrage, bevor eine Validierung erfolgt, erzwungen. Bei ACME beispielsweise sind Konten mit öffentlicher Kryptografie abgesichert. Die erste Aktion eines ACME-Clients ist die Generierung einer einzigartigen kryptografischen Identität, die bei jeder Ausstellung genutzt wird. Wenn eine Kontobeschränkung aktiv ist, ist die Authentifizierung der Anfrage der erste Schritt in der ACME-Interaktion, da der Client seine Zugehörigkeit zu dem im CAA-Eintrag spezifizierten Konto nachweisen muss.

Hinweis: Im Juni 2025 hat das CA/Browser Forum die Annahme von Ballot SC-085v2 beschlossen, das von allen CAs verlangt, bei CAA-Abfragen und DCV (Domain Control Validation) DNSSEC zu validieren. Diese Änderungen sind ab März 2026 für alle CAs verpflichtend. Danach sind Domains mit DNSSEC gegen jegliche Form von DNS-Spoofing geschützt. 

Die in RFC 8657 definierten Erweiterungen ermöglichen strengere Sicherheitskontrollen bei der Ausstellung von Zertifikaten. Das geht aber nicht ohne Aufwand: Es erfordert Zeit und Ressourcen, die Ausstellung neu zu gestalten und so zu organisieren, dass sie kompatibel und zugleich sicherer wird. Für alle Domains eines Unternehmens ist dieses Vorgehen nicht wirtschaftlich. Allerdings ist das Verfahren für eine kleine Anzahl besonders wertvoller Domains sinnvoll. Für alles andere reicht es meist, die Ausstellung auf eine geringe Anzahl von CAs zu beschränken.

Für Ihre besonders schützenswerten Domains empfiehlt sich folgendes Vorgehen:

1. Wählen Sie zwei oder drei kompetente CAs aus. Sie brauchen mindestens zwei, um keinen Single Point of Failure zu haben. Für wichtige Domains empfehle ich, immer mindestens ein gültiges Ersatz-Zertifikat bereitzuhalten, falls es mit dem primären Probleme gibt. Mindestens eine Ihrer gewählten CAs muss entweder RFC 8567 unterstützen oder eine gleichwertige proprietäre Funktion bereitstellen.
2. Setzen Sie eine strikte CAA-Konfiguration um auf dem Hauptdomain-Namen, die die Ausstellung nur auf die ausgewählten CAs und – besonders wichtig – auf jeweils definierte Konten beschränkt. Diese Konfiguration ermöglicht eine starke kryptografische Validierung.
3. Überwachen Sie Ihre DNS-Konfiguration dahingehend, a) dass keine dangling DNS-Probleme auftreten und b) ob Delegationen an Dritte via CNAMEs existieren (diese könnten eigene, übergreifende CAA-Konfigurationen nutzen).

Wie bereits erläutert, hat Certificate Transparency die Möglichkeiten zur Überwachung der Aktivitäten von Zertifizierungsstellen grundlegend verändert. Dennoch gibt es beim Monitoring Herausforderungen:

• Es ist immer noch möglich, öffentliche Zertifikate an CT vorbei zu veröffentlichen, wie in einem früheren Abschnitt dieses Dokuments erläutert.
• CT-Monitoring ist weiterhin nicht weitverbreitet. Obwohl dies seit einigen Jahren verpflichtend ist, investieren die meisten Organisationen noch nicht ausreichend Ressourcen in die Überwachung der Zertifikatsausstellung für ihre eigenen Domains.
• Signal von Rauschen zu unterscheiden ist schwierig. Zertifikate enthalten oft nicht genügend Informationen, um regulär ausgestellte Zertifikate von solchen zu unterscheiden, die unberechtigt durch Dritte beschafft wurden. Dafür werden fortschrittliche Monitoring-Tools benötigt, die vielen Organisationen noch nicht bekannt sind.

Auch wenn dieses Dokument die Möglichkeiten aufzeigen möchte, erkennen wir an, dass viele Organisationen keinen Höchstschutz benötigen. Selbst bei denen, die höchste Sicherheit benötigen, gilt das häufig nicht für alle Domains und Websites.

Wir empfehlen, Ihre Domains nach Risikoprofil in drei Gruppen zu teilen:

• Sehr geringes Risiko: Hierzu zählen alle geparkten und ungenutzten Domains. Je nach Größe Ihres Unternehmens sind das einige wenige oder Hunderte. Sofern Sie nicht über eine ausgezeichnete DNS-Automatisierung verfügen, lohnt sich eine weitere Absicherung dieser Gruppe meist nicht. 
• Geringes Risiko: Hier gehören alle Domains hinein, auf denen Sie tatsächlich Websites oder Anwendungen betreiben. Das sollte die Standardgruppe sein. Hier empfiehlt es sich, eine einfache CAA-Konfiguration zu verwenden, die die Ausstellung auf wenige, ausgesuchte CAs beschränkt – wie bereits oben im Dokument beschrieben. Diese Domains sind selten Angriffsziel, CAA wird hier vorrangig zur Durchsetzung Ihrer CA-Auswahlvorgaben genutzt.
• Hohes Risiko: In diese Gruppe gehören Ihre besonders kritischen Domains – alles, was mit Geld, Behörden, Kommunikation oder potenziellen aktiven Netzangriffen zu tun hat. Für diese Gruppe sollten Sie sämtliche technischen Schutzmaßnahmen ergreifen, die Ihnen zur Verfügung stehen.

High-Assurance CT-Monitoring ist ein Ansatz, mit dem Sie mit hoher Sicherheit einen Strom von Zertifikaten aus Certificate Transparency überwachen und eindeutig zwischen Zertifikaten unter Ihrer Kontrolle und solchen Dritter unterscheiden können.

Konzepteill ist der Ansatz einfach: Man validiert, was bekannt und legitim ist. Alles andere gilt als potenziell problematisch:

1. Führen Sie ein Inventar aller Zertifikate, die unter Ihrer Kontrolle sind
2. Überwachen Sie Certificate Transparency und suchen Sie nach Zertifikaten, die Ihnen noch nicht bekannt sind

Und das war's. Nur zwei Schritte; der erste kann je nach Setup allerdings einiger Aufwand sein. Bedenken Sie: Das muss nur für Ihre besonders schützenswerten Domains erfolgen, nicht für alle.

• Wenn Sie ein Certificate Lifecycle Management (CLM)-Tool oder ACME zusammen mit einer kommerziellen CA nutzen, gibt es dort vermutlich ein eingebautes Zertifikatsinventar. Es sollte nicht schwierig sein, Ihre Zertifikate dort herauszubekommen, Sie müssen aber ggf. gegen deren APIs programmieren.
• Wenn Sie ACME mit einer kostenlosen CA (zum Beispiel Let's Encrypt) nutzen, gibt es unter Umständen kein solches Inventar. Dann müssen Sie selbst Mechanismen schaffen, um ausgestellte Zertifikate zu erfassen und zentral zu speichern. Das ist einfacher, falls alle Zertifikate vom selben Server ausgestellt werden, aber auch bei mehreren Servern in der Regel nicht schwierig.

In der Praxis wird es in den meisten Fällen unvermeidlich sein, eine separate Datenbank zu pflegen, in der Sie Ihre eigenen Zertifikate speichern. Das liegt daran, dass eine zentrale Ausstellung in der Praxis, erst recht im großen Maßstab, sehr selten ist. Es gibt immer spezielle Fälle, eher, wenn Aspekte Ihrer öffentlichen PKI an Dritte delegiert werden. Die Gesamtlösung muss verschiedene Datenquellen integrieren, um einen vollständigen Überblick zu erhalten.