CAA-DNS-Einträge: der vollständige Leitfaden, um zu steuern, wer deine Zertifikate ausstellt

⚡TL;DR

• Ein CAA-DNS-Eintrag legt fest, welche Zertifizierungsstellen ein TLS-Zertifikat für deine Domain ausstellen dürfen. Ohne CAA kann das jede öffentliche CA tun.
• Die Syntax besteht aus drei Feldern: flag tag value. Die nützlichen Tags sind issue (klassische Zertifikate), issuewild (Wildcards) und iodef (Meldung unautorisierter Versuche).
• Die CA prüft das CAA zum Zeitpunkt der Ausstellung, indem sie das DNS von der Subdomain zum Apex hinaufläuft (Tree Climbing), und stoppt beim ersten gefundenen Eintrag (RFC 8659).
• RFC 8657 ergänzt accounturi und validationmethods, um die Ausstellung an ein bestimmtes ACME-Konto und an erlaubte Validierungsmethoden zu binden.
• Eine schlecht durchdachte CAA-Konfiguration (vergessenes issuewild, missverstandenes Semikolon, fehlende CA) kann deine automatischen ACME-Verlängerungen blockieren.

Das Vertrauensmodell von TLS-Zertifikaten beruht auf rund hundert Zertifizierungsstellen (CAs), die von den Browsern anerkannt werden. Das Problem ist strukturell: Standardmäßig kann jede dieser CAs ein gültiges Zertifikat für deine Domain ausstellen, ohne deine Zustimmung und ohne dich überhaupt zu informieren. Ein Angreifer, dem es gelingt, eine einzige CA zu täuschen, oder eine CA, die sich irrt, kann ein einwandfrei anerkanntes Zertifikat für captaindns.com erzeugen.

Der CAA-DNS-Eintrag (Certificate Authority Authorization), definiert in RFC 8659, schließt einen Teil dieser Lücke. Er fungiert als Whitelist, die in deiner DNS-Zone veröffentlicht wird: Bevor eine konforme CA ein Zertifikat ausstellt, muss sie das DNS abfragen und prüfen, ob sie in deinen CAA-Einträgen aufgeführt ist. Ist sie es nicht, verweigert sie die Ausstellung. Das ist eine Barriere bei der Ausstellung, keine nachträgliche Erkennung.

Dieser Leitfaden richtet sich an Systemadministratoren, DevOps- und SRE-Teams sowie Sicherheitsverantwortliche. Er behandelt das Bedrohungsmodell, die vollständige Syntax eines CAA-Eintrags (Tags issue, issuewild, iodef, kritisches Flag), den genauen Validierungsmechanismus per Tree Climbing, die erweiterten Parameter aus RFC 8657 für das ACME-Ökosystem, die konkrete Konfiguration bei den wichtigsten Anbietern sowie die Fehler, die automatische Verlängerungen scheitern lassen.

Das Problem: jede CA kann ein Zertifikat ausstellen

Wenn dein Browser eine HTTPS-Verbindung öffnet, prüft er, ob das vorgelegte Zertifikat von einer Zertifizierungsstelle signiert wurde, die in seinem Vertrauensspeicher vorhanden ist. Dieser Speicher enthält rund hundert Root-CAs, die von sehr unterschiedlichen Organisationen in zahlreichen Ländern verwaltet werden.

Ein horizontales Vertrauen ohne Abschottung

Der Designfehler ist einfach zu benennen: Das Vertrauen ist horizontal. Der Browser vertraut allen CAs in seinem Speicher gleichermaßen. Nichts im Basisprotokoll beschränkt eine bestimmte CA auf eine Teilmenge von Domains. Konkret ist eine CA am anderen Ende der Welt, die du nie genutzt hast, technisch befugt, ein anerkanntes Zertifikat für deine Domain auszustellen.

Solange alle CAs einwandfrei arbeiten, hält dieses Modell. Doch es genügt, dass eine einzige versagt, durch einen Betriebsfehler oder eine Kompromittierung, damit ein betrügerisches Zertifikat erzeugt und von allen Browsern akzeptiert wird.

Ganz reale Vorfälle

Die Geschichte der TLS-Zertifikate ist von Vorfällen falscher Ausstellung (Mis-Issuance) durchzogen:

• DigiNotar (2011): Diese niederländische CA wurde kompromittiert. Die Angreifer stellten mehr als 500 betrügerische Zertifikate aus, darunter ein Wildcard für *.google.com, das zum Abfangen des Datenverkehrs iranischer Bürger genutzt wurde. DigiNotar verlor das Vertrauen der Browser und ging in Konkurs.
• Symantec (2015 bis 2017): Eine Reihe nicht konformer Ausstellungen, darunter ohne Genehmigung ausgestellte Testzertifikate für Drittdomains, veranlasste Google und Mozilla, den Entzug des Vertrauens in die alte Symantec-Infrastruktur zu planen. Das CA-Geschäft wurde an DigiCert abgegeben.
• BGP-Hijacking: Mehrere Angriffe kombinierten das Umleiten von Netzwerkrouten mit der Domain-Validierung, um betrügerische Zertifikate zu erlangen. Im Fall MyEtherWallet (2018) leiteten Angreifer den DNS-Verkehr um, um ein Zertifikat zu erhalten und Gelder zu stehlen.

Diese Vorfälle haben einen gemeinsamen Punkt: Ein technisch gültiges Zertifikat wurde für eine Domain ausgestellt, ohne Zustimmung ihres Inhabers. Die akademische Forschung hat bestätigt, dass dieses Risiko alles andere als anekdotisch ist. Die Studie "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018) zeigte, dass ein Angreifer bei den größten CAs betrügerische Zertifikate erlangen konnte, indem er die Domain-Validierungsanfragen per BGP umleitete, mit einer hohen Erfolgsquote.

Die Lehre lautet: Ein einziges Versagen bei irgendeiner der vertrauenswürdigen CAs reicht aus, um jede beliebige Domain zu kompromittieren. Genau das Ausmaß dieser Angriffsfläche verringert das CAA, indem es die Liste der CAs einschränkt, die für eine bestimmte Domain ausstellen dürfen.

Erkennung reicht nicht aus

Certificate Transparency (CT) schreibt seit 2018 vor, dass jedes öffentliche Zertifikat in öffentlichen und überprüfbaren Registern protokolliert wird. Das ist ein großer Fortschritt: Ein Domaininhaber kann diese Logs überwachen und ein ohne sein Wissen ausgestelltes Zertifikat erkennen.

Doch Certificate Transparency ist ein Mechanismus zur nachträglichen Erkennung. In dem Moment, in dem du ein betrügerisches Zertifikat in einem Log entdeckst, wurde es bereits ausgestellt und kann bereits zum Einsatz gekommen sein. Das CAA setzt im Vorfeld an: Es verhindert die Ausstellung, statt sie im Nachhinein festzustellen. Beide Mechanismen ergänzen sich, wie wir weiter unten erläutern.

Was ist ein CAA-Eintrag?

Ein CAA-DNS-Eintrag (Certificate Authority Authorization, RFC 8659) gibt an, welche Zertifizierungsstellen TLS-Zertifikate für eine Domain ausstellen dürfen. Vor jeder Ausstellung fragt die CA das DNS der Domain ab und verweigert die Ausstellung, wenn sie nicht in der veröffentlichten Liste steht. Es handelt sich um eine vorherige Genehmigung, die der Domaininhaber über seine DNS-Zone steuert.

Ein eigener DNS-Eintragstyp

Das CAA ist ein eigenständiger DNS-Eintragstyp, der Typ 257. Er wird in deiner Zone genauso veröffentlicht wie ein A-, MX- oder TXT-Eintrag. Du kannst ihn am Apex der Zone (captaindns.com) oder auf einer bestimmten Subdomain (api.captaindns.com) platzieren.

Hier ein minimales Beispiel, das nur Let's Encrypt erlaubt, Zertifikate für die Domain auszustellen:

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"

Dieser Eintrag erklärt nur eine Sache: Die einzige CA, die ein Zertifikat für captaindns.com ausstellen darf, ist Let's Encrypt, identifiziert über ihre Domain letsencrypt.org. Jede andere konforme CA, die eine Anfrage für diese Domain erhält, lehnt sie ab.

Ein wesentlicher Punkt zur Semantik: Das Vorhandensein eines einzigen issue-Eintrags kippt die implizite Richtlinie. Ohne CAA sind alle CAs standardmäßig erlaubt. Sobald ein issue existiert, kehrt sich der Standard um: Nur die ausdrücklich gelisteten CAs sind erlaubt, alle anderen sind implizit verboten. Eine CA zu deiner Richtlinie hinzuzufügen bedeutet also, einen zusätzlichen issue-Eintrag zu veröffentlichen; eine zu vergessen kommt einer Sperre gleich.

Eine Geschichte aus zwei RFCs

Das CAA wurde zuerst 2013 durch RFC 6844 definiert. Diese erste Fassung enthielt einen Tree-Climbing-Mechanismus, der als mehrdeutig galt, insbesondere bei der Behandlung von Fehlern und CNAME/DNAME-Aliassen.

RFC 8659, veröffentlicht 2019, ersetzt RFC 6844 und ist die aktuelle Referenz. Sie präzisiert den Tree-Climbing-Algorithmus und behebt die Graubereiche der ersten Fassung. Eine ergänzende RFC, RFC 8657 (2019), fügt zwei ACME-orientierte Parameter hinzu: accounturi und validationmethods. Diese Parameter behandeln wir in einem eigenen Abschnitt.

Eine Barriere, keine absolute Garantie

Das CAA beruht auf der Kooperation der CAs. Alle öffentlich anerkannten CAs, die den Baseline Requirements des CA/Browser Forums unterliegen, sind verpflichtet, das CAA vor der Ausstellung zu prüfen. Das ist eine Anforderung des Regelwerks, keine Option. In der Praxis wenden die großen CAs diese Prüfung an.

Das CAA schützt also nicht vor einer unehrlichen CA, die deine Einträge absichtlich ignorieren würde, noch vor einer organisationsinternen privaten CA. Aber es erhöht die Hürde deutlich: Um trotz eines gut konfigurierten CAA ein betrügerisches Zertifikat auszustellen, müsste ein Angreifer entweder die von dir ausdrücklich autorisierte CA kompromittieren oder deine DNS-Antworten im Moment der Prüfung fälschen. Dieser letzte Punkt führt uns zur Verbindung zwischen CAA und DNSSEC, die weiter unten behandelt wird.

Anatomie eines CAA-Eintrags

Ein CAA-Eintrag besteht aus drei Feldern, stets in derselben Reihenfolge. Diese Syntax zu beherrschen ist unerlässlich, um keine Konfigurationsfehler zu machen.

Die Struktur flag tag value

Jeder CAA-Eintrag setzt sich aus drei Elementen zusammen:

Feld	Rolle	Werte
flag	Steuerwert (Ganzzahl)	0 (nicht kritisch) oder 128 (kritisch)
tag	Betroffene Eigenschaft	issue, issuewild oder iodef
value	Wert der Eigenschaft	Kennung der CA oder Melde-URL

Von links nach rechts gelesen, übersetzt sich der Eintrag 0 issue "letsencrypt.org" zu: nicht kritisches Flag, Eigenschaft issue, Wert letsencrypt.org. Der Wert steht in der Textdarstellung immer in geraden Anführungszeichen.

Der Tag issue: eine CA für klassische Zertifikate autorisieren

Der Tag issue erlaubt einer CA, Nicht-Wildcard-Zertifikate für die Domain auszustellen. Der Wert ist die Kennung der CA, in der Regel ein Domainname.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issue "digicert.com"

Dieses Beispiel autorisiert zwei CAs: Let's Encrypt und DigiCert. Wenn mehrere issue-Einträge nebeneinander bestehen, addieren sie sich: Jede gelistete CA ist erlaubt. Es handelt sich um eine kumulative Whitelist.

Ein Sonderfall verdient Aufmerksamkeit: der Wert ";" (ein einfaches Semikolon). Er verbietet jede Ausstellung.

captaindns.com.  IN  CAA  0 issue ";"

Dieser Eintrag erklärt, dass keine CA berechtigt ist, ein klassisches Zertifikat für die Domain auszustellen. Das ist nützlich für eine Domain, die niemals ein Zertifikat tragen soll (etwa eine geparkte Domain), aber auch eine häufige Fehlerquelle, wenn es versehentlich gesetzt wird.

Der Tag issuewild: der Fall der Wildcards

Der Tag issuewild steuert speziell die Ausstellung von Wildcard-Zertifikaten (vom Typ *.captaindns.com). Seine Syntax ist identisch mit der von issue.

Die Vorrangregel ist entscheidend: issuewild hat Vorrang vor issue bei Wildcard-Zertifikaten. Ist ein issuewild-Eintrag vorhanden, ist er für Wildcard-Anfragen maßgeblich, und die issue-Einträge werden in diesem Fall ignoriert. Ist kein issuewild vorhanden, fallen die Wildcard-Zertifikate auf die issue-Regeln zurück.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issuewild "digicert.com"

In diesem Beispiel können klassische Zertifikate nur von Let's Encrypt ausgestellt werden, während Wildcard-Zertifikate nur von DigiCert ausgestellt werden können. Um jegliches Wildcard-Zertifikat schlicht zu verbieten, verwendet man das Semikolon:

captaindns.com.  IN  CAA  0 issuewild ";"

Das blockiert jede Wildcard-Ausstellung, während die klassischen Zertifikate weiterhin den issue-Regeln folgen.

Der Tag iodef: unautorisierte Versuche melden

Der Tag iodef (Incident Object Description Exchange Format) gibt an, wohin eine CA eine Zertifikatsanfrage melden soll, die deine CAA-Richtlinie verletzt. Der Wert ist eine URL, entweder eine E-Mail im Format mailto: oder eine HTTPS-URL.

captaindns.com.  IN  CAA  0 iodef "mailto:security@captaindns.com"
captaindns.com.  IN  CAA  0 iodef "https://captaindns.com/caa-report"

Wenn eine CA eine Anfrage erhält, die sie wegen deines CAA ablehnt, kann sie einen Bericht an die iodef-Adresse senden. Das ist ein wertvolles Signal: Ein unautorisierter Ausstellungsversuch kann auf einen laufenden Angriff oder einen falsch konfigurierten internen Dienst hindeuten. Die Unterstützung von iodef variiert je nach CA; man sollte es als Sichtbarkeitsbonus betrachten, nicht als Benachrichtigungsgarantie.

In der Praxis verdient ein iodef-Bericht eine sofortige Untersuchung. Entweder versucht einer deiner Dienste, ein Zertifikat über eine CA auszustellen, die du zu autorisieren vergessen hast (Konfigurationsproblem), oder ein externer Akteur versucht, ein Zertifikat für deine Domain zu erlangen (Sicherheitsproblem). In beiden Fällen verschafft dir das iodef eine Sichtbarkeit, die weder Certificate Transparency noch die Logs deiner Infrastruktur bieten, denn es erfasst den Versuch genau im Moment der Ablehnung.

Das kritische Flag: 0 gegen 128

Das erste Feld, das Flag, ist ein Oktett, bei dem nur das höchstwertige Bit (Wert 128, also 0x80) eine definierte Bedeutung hat: Es ist das kritische Flag (Issuer Critical).

• Flag 0: nicht kritischer Eintrag. Versteht eine CA den Tag nicht, ignoriert sie ihn und fährt fort.
• Flag 128: kritischer Eintrag. Trifft eine CA auf einen Tag, den sie nicht versteht, und ist dieses Flag gesetzt, muss sie die Ausstellung verweigern.

Das kritische Flag dient dazu, sich gegen die künftige Einführung von Tags abzusichern, die ältere CAs nicht interpretieren könnten. Indem du das Flag 128 auf einen Tag setzt, verlangst du, dass jede CA, die ihn nicht versteht, sicherheitshalber davon absieht, statt ihn zu ignorieren. In der überwiegenden Mehrheit der Konfigurationen bleibt das Flag auf 0: Die Tags issue, issuewild und iodef werden universell verstanden.

Die Kennungen der gängigen CAs

Der Wert eines issue- oder issuewild-Tags ist die Kennung der CA, die jede Stelle in ihrer Dokumentation festlegt. Hier die Kennungen der wichtigsten CAs:

Zertifizierungsstelle	CAA-Kennung
Let's Encrypt	letsencrypt.org
DigiCert	digicert.com
Sectigo	sectigo.com
GlobalSign	globalsign.com
Google Trust Services	pki.goog
Amazon (AWS Certificate Manager)	amazon.com (sowie amazontrust.com, amazonaws.com, awstrust.com)

Verwende immer die exakte von der CA veröffentlichte Kennung, keine Näherung. Ein falscher Wert kommt einer Nicht-Autorisierung der CA gleich, und das Zertifikat wird abgelehnt. Bist du dir bei der Kennung einer hier nicht gelisteten CA unsicher, konsultiere ihre offizielle Dokumentation, statt zu raten.

Wie die CAA-Validierung funktioniert

Die Stärke des CAA liegt in seinem Validierungsmechanismus zum Zeitpunkt der Ausstellung. Diesen Mechanismus zu verstehen vermeidet die meisten Konfigurationsfehler.

Das Tree Climbing

Wenn eine CA eine Zertifikatsanfrage für einen bestimmten Namen bearbeitet, betrachtet sie nicht nur das CAA dieses genauen Namens. Sie läuft die DNS-Hierarchie hinauf, Label für Label, vom angefragten Namen zum Apex der Zone, bis sie eine Menge von CAA-Einträgen findet. Das ist das Tree Climbing, definiert in Abschnitt 3 von RFC 8659.

Nehmen wir eine Anfrage für api.captaindns.com. Die CA geht so vor:

1. Sie fragt das CAA von api.captaindns.com ab. Ist dort eine CAA-Menge veröffentlicht, nutzt sie diese und stoppt.
2. Andernfalls steigt sie eine Stufe hinauf und fragt captaindns.com ab. Ist dort eine CAA-Menge veröffentlicht, nutzt sie diese und stoppt.
3. Der Aufstieg setzt sich fort, bis eine CAA-Menge gefunden wird oder bis die Root erreicht ist, ohne etwas zu finden.

Der Kernpunkt: Die CA stoppt beim ersten Namen, der CAA-Einträge besitzt. Die Einträge höherer Ebenen werden dann nicht mehr konsultiert.

Die Vererbung und ihre Folgen

Diese Mechanik hat eine wichtige Folge: Eine Subdomain erbt die CAA-Richtlinie ihres Elternteils, aber nur, wenn sie keine eigene definiert.

Wenn du ein CAA am Apex captaindns.com veröffentlichst und nichts auf api.captaindns.com, dann unterliegt api.captaindns.com der Richtlinie des Apex. Doch sobald du auch nur einen einzigen CAA-Eintrag auf api.captaindns.com veröffentlichst, stoppt die CA auf dieser Ebene und ignoriert den Apex vollständig. Die Vererbung ist binär: Entweder hat die Subdomain kein CAA und erbt, oder sie hat eines und ersetzt die Eltern-Richtlinie vollständig. Es gibt keine Verschmelzung der beiden Ebenen.

Das ist eine klassische Fehlerquelle: Man fügt ein spezifisches CAA auf einer Subdomain hinzu, um eine zusätzliche CA zu autorisieren, ohne zu bemerken, dass dieser Eintrag die Apex-Richtlinie ersetzt, statt sich ihr hinzuzufügen. Die Subdomain muss dann alle CAs auflisten, die sie braucht, einschließlich der bereits auf Elternebene autorisierten.

Das Zusammenspiel mit Wildcards

Der Fall der Wildcard-Zertifikate kombiniert zwei Regeln. Zunächst den oben beschriebenen Vorrang von issuewild vor issue. Dann das Tree Climbing. Für eine Anfrage zu *.captaindns.com sucht die CA zuerst eine CAA-Menge, indem sie den Baum hinaufläuft, und wendet dann innerhalb dieser Menge den Vorrang von issuewild an. Enthält die gefundene Menge ein issuewild, ist es für das Wildcard maßgeblich; andernfalls fällt das Wildcard auf die issue-Einträge derselben Menge zurück.

Der Fall der CNAME-Aliasse

Wenn der für die CAA-Validierung bearbeitete Name auf einen CNAME-Alias zeigt, folgt die CAA-Suche diesem Alias. RFC 8659 präzisiert, dass die CAA-Suche bei einem CNAME-Alias auf dem Ziel des Alias fortgesetzt wird. Das ist ein Detail, das manchmal überrascht: Eine per CNAME auf einen Drittdienst zeigende Subdomain kann je nach Konfiguration vom CAA des Ziels abhängen statt von dem deiner Zone. Wenn du eine Subdomain per CNAME an einen externen Anbieter delegierst, prüfe, welche CAA-Richtlinie tatsächlich gilt.

Was die CA bei der Ausstellung wirklich prüft

Zum Zeitpunkt der Ausstellung führt eine den Baseline Requirements konforme CA die CAA-Prüfung in einem begrenzten Zeitfenster durch (höchstens 8 Stunden vor der Ausstellung, gemäß Regelwerk). Nach Ablauf dieser Frist muss die Prüfung wiederholt werden. Diese Einschränkung verhindert, dass eine lange im Voraus erteilte Genehmigung gültig bleibt, nachdem du eine CA aus deiner Richtlinie entfernt hast.

Die CA muss außerdem seit der Einführung der Multi-Perspective-Validierung (MPIC, Ballot SC-067) die CAA-Prüfung und die Domain-Validierung von mehreren geografisch verteilten Netzwerk-Standorten aus durchführen. Ziel ist es, lokalisiertem BGP-Hijacking entgegenzuwirken: Leitet ein Angreifer den Verkehr in einer Region um, um die CAA-Antwort zu fälschen, erhalten die anderen Perspektiven die legitime Antwort, und die CA erkennt die Inkonsistenz. MPIC schützt die CAA-Prüfung also auf Netzwerkebene, während DNSSEC sie auf Ebene des DNS-Protokolls schützt. Beide Mechanismen verstärken einander.

Konkret sieht die Ausstellungssequenz so aus: Die CA erhält die Anfrage, validiert die Domain-Kontrolle (DNS-01, HTTP-01 oder TLS-ALPN-01), fragt das CAA ab, indem sie den Baum hinaufläuft, bestätigt, dass sie in der erlaubten Liste steht, und stellt dann aus. Lehnt das CAA sie ab, stoppt die Ausstellung sofort, und ist ein iodef vorhanden, kann ein Bericht gesendet werden.

Die Verbindung zu DNSSEC

Die CAA-Prüfung beruht auf DNS-Antworten. Kann ein Angreifer deine DNS-Antworten in dem Moment fälschen, in dem die CA das CAA abfragt, kann er die Prüfung täuschen. DNSSEC begegnet diesem Risiko, indem es DNS-Antworten kryptografisch authentifiziert.

Das CA/Browser Forum hat diese Verbindung mit Ballot SC-085v2 formalisiert, der seit dem 15. März 2026 in Kraft ist und CAs verpflichtet, DNSSEC, wenn es vorhanden ist, bei den CAA- und Domain-Validierungsanfragen zu prüfen. Konkret erhält die CA, wenn deine Zone signiert ist und die Vertrauenskette intakt ist, die Garantie, dass die gelesenen CAA-Einträge authentisch sind. Wir haben dieser regulatorischen Änderung einen eigenen Artikel gewidmet: CAs prüfen jetzt DNSSEC, bevor sie ein Zertifikat ausstellen. Du kannst den Signaturstatus deiner Zone mit unserem DNSSEC-Checker prüfen. Um DNSSEC auf einer Domain zu aktivieren, die noch nicht davon profitiert, folge unserem Schritt-für-Schritt-Aktivierungsleitfaden.

Erweiterte Parameter: RFC 8657 und ACME

RFC 8657 erweitert das CAA um zwei Parameter, die sich in den Tag issue oder issuewild einfügen. Sie sind besonders nützlich in einem automatisierten ACME-Ökosystem.

accounturi: ein ACME-Konto fixieren

Der Parameter accounturi beschränkt die Ausstellung auf ein bestimmtes ACME-Konto. Statt einem beliebigen Konto einer gegebenen CA die Ausstellung für deine Domain zu erlauben, fixierst du die Genehmigung auf die URI eines einzigen ACME-Kontos.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Dieser Eintrag erlaubt Let's Encrypt die Ausstellung, aber nur für das ACME-Konto mit der Nummer 12345678. Eine Anfrage von einem anderen Let's-Encrypt-Konto wird abgelehnt. Das ist ein starker Schutz: Selbst wenn ein Angreifer dieselbe CA wie du nutzt, kann er nicht mit seinem eigenen Konto ausstellen.

validationmethods: die Validierungsmethoden einschränken

Der Parameter validationmethods begrenzt die für die Domain erlaubten ACME-Validierungsmethoden. Die Werte entsprechen den ACME-Challenge-Typen: dns-01, http-01 und tls-alpn-01.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

Hier wird nur die Validierung per DNS-Eintrag (dns-01) akzeptiert. Ein Ausstellungsversuch per http-01 (Ablage einer Datei auf dem Webserver) wird abgelehnt. Das härtet die Konfiguration: Wenn du weißt, dass deine Zertifikate immer per dns-01 validiert werden, reduziert das Verbot der anderen Methoden die Angriffsfläche, etwa einen kompromittierten Webserver, der eine http-01-Validierung versuchen würde.

Die drei ACME-Validierungsmethoden haben unterschiedliche Risikoprofile. Die Methode dns-01 verlangt die Kontrolle über die DNS-Zone und ermöglicht Wildcard-Zertifikate. Die Methode http-01 verlangt die Kontrolle über den Webserver auf Port 80. Die Methode tls-alpn-01 validiert über eine TLS-Erweiterung auf Port 443. validationmethods auf die einzige tatsächlich genutzte Methode zu beschränken, verhindert, dass ein Angreifer, der nur einen dieser Vektoren kontrolliert, ein Zertifikat über einen von dir nicht vorgesehenen Weg erlangt.

Die Parameter für eine gehärtete Domain kombinieren

Die Parameter summieren sich in einem einzigen Eintrag, getrennt durch Semikolons. Eine typische gehärtete Konfiguration kombiniert CA, Konto und Methode:

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"

Dieser Eintrag erlaubt nur Let's Encrypt, ausschließlich über das ACME-Konto 12345678 und ausschließlich per Methode dns-01. Das ist die feinste vom CAA gebotene Kontrollstufe. Vorsicht jedoch: Je strenger die Konfiguration, desto eher kann ein Fehler (Kontowechsel, Migration der Validierungsmethode) eine Verlängerung blockieren. Die Unterstützung von RFC 8657 hängt zudem von der CA ab; Let's Encrypt implementiert sie, aber prüfe die Dokumentation deiner CA, bevor du accounturi oder validationmethods einsetzt.

Praxisleitfaden: CAA bei deinem Anbieter konfigurieren

Die CAA-Syntax ist standardisiert, aber jeder DNS-Anbieter stellt eine andere Oberfläche bereit. Manche verlangen die drei Felder einzeln (flag, tag, value), andere eine vollständige Zeichenkette. Der Eintragstyp ist immer CAA (Typ 257). Hier die Vorgehensweise bei den gängigen Anbietern.

Cloudflare

Gehe im Cloudflare-Dashboard zu DNS und dann zu Records und füge einen Eintrag vom Typ CAA hinzu. Die Oberfläche zeigt drei getrennte Felder:

• Flags: In den meisten Fällen 0 lassen.
• Tag: Wähle issue, issuewild oder iodef aus der Auswahlliste.
• CA domain name (oder Value): Gib die Kennung ein, zum Beispiel letsencrypt.org.

Cloudflare bietet auch eine API und sein Kommandozeilen-Tool, um die Erstellung von CAA-Einträgen in einer Infrastructure-as-Code zu automatisieren. Beachte, dass Cloudflare manchmal automatisch CAA-Einträge für seine eigenen verwalteten Zertifikate hinzufügt; prüfe nach einer Änderung die vollständige Liste, um keinen für einen Cloudflare-Dienst nötigen Eintrag zu überschreiben.

AWS Route 53

Wähle in der Route-53-Konsole deine gehostete Zone aus und erstelle einen Eintrag vom Typ CAA. Route 53 erwartet den Wert im vollständigen Format, eine Zeile pro Eintrag:

0 issue "amazon.com"
0 issue "letsencrypt.org"

Werden deine Zertifikate vom AWS Certificate Manager (ACM) verwaltet, dokumentiert Amazon mehrere akzeptierte Kennungen: amazon.com, amazontrust.com, amazonaws.com und awstrust.com. Du kannst sie alle autorisieren, um sämtliche Fälle abzudecken. Denk daran, die übrigen CAs zu behalten, die du für Dienste außerhalb von AWS brauchst.

OVHcloud

Öffne im OVHcloud-Kundenbereich die DNS-Zone deiner Domain und füge einen Eintrag hinzu. Wähle den Typ CAA. OVHcloud verlangt im Allgemeinen das Flag, den Tag und das Ziel (den Wert) in getrennten Feldern. Gib 0 für das Flag ein, den gewünschten Tag und die Kennung der CA als Ziel. Bestätige und warte dann die Propagierung ab.

Gandi

Füge in der DNS-Verwaltungsoberfläche von Gandi (LiveDNS) einen Eintrag vom Typ CAA hinzu. Gandi erwartet den Wert im vollständigen Textformat:

0 issue "letsencrypt.org"

Wie bei den anderen Anbietern kannst du mehrere CAA-Zeilen hinzufügen, um mehrere CAs zu autorisieren oder um issuewild und iodef zu ergänzen. Die Validierung der Gandi-Zertifikate für bei ihnen gehostete Domains stützt sich auf die von ihnen genutzten CAs; denk daran, diese einzuschließen, wenn du auf ihre Zertifikate setzt.

Die Propagierung nach der Konfiguration prüfen

Unabhängig vom Anbieter: Betrachte die Konfiguration nicht als abgeschlossen, solange du nicht bestätigt hast, dass der Eintrag öffentlich sichtbar ist. Frage das DNS von außerhalb deines Netzwerks ab und bestätige, dass das CAA mit dem erwarteten Flag, Tag und Wert erscheint. Berücksichtige den TTL: Ein geänderter Eintrag kann für die Dauer des vorherigen TTL im Cache bleiben. Bei einer mit DNSSEC signierten Domain prüfe außerdem, dass der neue CAA-Eintrag korrekt signiert ist, sonst lehnt ihn ein validierender Resolver ab.

iodef für die Meldung konfigurieren

Unabhängig vom Anbieter wird der Tag iodef wie issue konfiguriert, aber sein Wert ist eine Melde-URL statt einer CA-Kennung. Verwende eine von deinem Sicherheitsteam überwachte E-Mail-Adresse:

0 iodef "mailto:security@captaindns.com"

Prüfe, dass die Adresse tatsächlich abgerufen wird. Ein iodef, das auf ein verlassenes Postfach zeigt, nützt nichts.

Testen, bevor man verriegelt

Eine umsichtige Empfehlung: Beginne mit einer permissiven Richtlinie, die alle deine tatsächlich genutzten CAs auflistet, rolle sie aus, prüfe, ob die Verlängerungen durchlaufen, und härte dann schrittweise. Berücksichtige den TTL deiner Einträge: Ein hoher TTL verlangsamt die Übernahme eines CA-Wechsels. Senke vor einer CA-Migration den TTL des CAA, um die Propagierung zu beschleunigen.

Deine CAA-Einträge prüfen und auditieren

Sobald das CAA ausgerollt ist, prüfe, ob es korrekt veröffentlicht ist und deine Absicht widerspiegelt. Zwei Ansätze ergänzen sich: die Kommandozeile und die Audit-Tools.

Das CAA mit dig auslesen

Das Tool dig fragt das DNS direkt ab. Um die CAA-Einträge einer Domain anzuzeigen:

dig CAA captaindns.com +short

Die Ausgabe sieht so aus:

0 issue "letsencrypt.org"
0 issuewild "digicert.com"
0 iodef "mailto:security@captaindns.com"

Jede Zeile entspricht einem CAA-Eintrag, in der Reihenfolge flag tag value. Gibt der Befehl nichts zurück, veröffentlicht die Domain auf dieser Ebene kein CAA. Vergiss das Tree Climbing nicht: Eine Subdomain ohne CAA erbt vom Apex. Um zu prüfen, was api.captaindns.com tatsächlich erbt, frage nacheinander die Subdomain und dann den Apex ab.

Um das vollständige Detail einschließlich TTL und Authority-Abschnitt zu sehen, lass die Option +short weg:

dig CAA captaindns.com

Die CaptainDNS-Tools

Die Kommandozeile zeigt den rohen Eintrag, sagt aber nicht, ob er stimmig ist. CaptainDNS bietet zwei Prüfebenen.

Der dedizierte CAA-Checker zeigt deine Einträge und ihre Auslegung an und berücksichtigt dabei die Vererbung per Tree Climbing. Er sagt dir klar, welche CA für klassische Zertifikate und für Wildcards autorisiert ist.

Für einen breiteren Überblick integriert unser Sicherheits- und Zustellbarkeits-Audit das CAA nun in sein Scoring. Die Säule DNS-Sicherheit kombiniert zwei Signale: DNSSEC, das mit 80 Punkten gewichtet ist, und CAA, das mit 20 Punkten gewichtet ist. Diese Gewichtung spiegelt ihre jeweilige Rolle wider: DNSSEC authentifiziert die Gesamtheit deiner DNS-Antworten, das CAA beschränkt speziell die Ausstellung von Zertifikaten. Eine Domain, die ein stimmiges CAA veröffentlicht, gewinnt diese 20 Punkte und verbessert ihre gesamte Sicherheitslage.

Was zu prüfen ist

Kontrolliere beim Audit einige genaue Punkte:

• Stimmigkeit von issue und issuewild: Ist die CA, die deine Wildcards ausstellt, tatsächlich durch ein issuewild autorisiert, oder setzt du auf den Rückfall zu issue?
• Keine verwaiste CA: Ist jede CA, die du tatsächlich nutzt (auch für Drittdienste, CDN, Mail-Gateways), in der Liste aufgeführt?
• iodef erreichbar: Wird die Melde-Adresse überwacht?
• Kein unbeabsichtigtes Semikolon: Ein versehentlich gesetztes issue ";" würde jede Ausstellung blockieren.

Häufige Fehler, die zu vermeiden sind

Die meisten CAA-bezogenen Vorfälle gehen auf einige wiederkehrende Fehler zurück. Sie zu kennen erlaubt, ihnen vorzubeugen.

issuewild vergessen. Du veröffentlichst ein issue für Let's Encrypt und alles funktioniert, bis zu dem Tag, an dem du ein Wildcard-Zertifikat anforderst. Ist kein issuewild vorhanden, fällt das Wildcard auf issue zurück, was funktioniert. Hast du aber ein issuewild für eine andere CA gesetzt oder ein issuewild ";", wird das Wildcard abgelehnt. Prüfe immer die Stimmigkeit zwischen issue und issuewild.

Die eigene CA blockieren. Der direkteste Fehler: vergessen, die CA aufzulisten, die du tatsächlich nutzt. Kommen deine Zertifikate von Let's Encrypt, autorisiert dein CAA aber nur DigiCert, scheitert die nächste Verlängerung. Dieser Fehler tritt oft nach einem CA-Wechsel oder dem Hinzufügen eines neuen Dienstes auf.

Die ACME-Verlängerung mit einer zu strengen Richtlinie brechen. Die Parameter accounturi und validationmethods sind mächtig, aber starr. Fixierst du ein ACME-Konto und erstellst dieses Konto dann neu (neue Kennung), oder migrierst du von http-01 zu dns-01, ohne das CAA zu aktualisieren, scheitern die automatischen Verlängerungen stillschweigend. In einer automatisierten ACME-Infrastruktur zeigt sich diese Art von Fehler erst beim Ablauf des Zertifikats.

Die Vererbung falsch verstehen. Einen CAA-Eintrag auf einer Subdomain hinzuzufügen ergänzt die Apex-Richtlinie nicht, sondern ersetzt sie für diese Subdomain. Eine Subdomain mit eigenem CAA muss alle CAs auflisten, die sie braucht. Diesen Punkt zu vergessen führt dazu, dass man eine CA autorisiert und gleichzeitig die des Apex versehentlich blockiert.

Das missverstandene Semikolon. issue ";" verbietet jede Ausstellung. Das ist gewollt bei einer Domain, die niemals ein Zertifikat tragen soll, aber eine Falle, wenn man es für einen Trenner oder einen leeren Wert hält. Lies jeden Eintrag nach der Eingabe noch einmal.

Das falsche Flag. Das kritische Flag 128 zu setzen, ohne seine Wirkung zu verstehen, kann CAs blockieren, die einen Tag nicht erkennen. In der großen Mehrheit der Fälle sollte das Flag auf 0 bleiben. Wechsle nur dann auf 128, wenn du einen präzisen Grund hast und verstehst, welche CAs davon betroffen sein werden.

Glauben, das CAA wirke nachträglich. Das CAA ist eine Barriere bei der Ausstellung, kein Widerrufsmechanismus. Es widerruft kein bereits ausgestelltes Zertifikat und wirkt nicht auf bestehende Zertifikate. Zur Überwachung bereits erzeugter Zertifikate übernimmt diese Rolle die Certificate Transparency.

Das CAA im Ökosystem der DNS-Sicherheit

Das CAA genügt sich nicht selbst. Es fügt sich in ein Bündel von Mechanismen ein, die verschiedene Phasen des Lebenszyklus eines Zertifikats absichern. Sie zu verwechseln führt zu falschen Erwartungen.

Vier Mechanismen, vier Rollen

Mechanismus	Was er schützt	Zeitpunkt der Wirkung
CAA	Welche CA ausstellen darf	Vor der Ausstellung
Certificate Transparency	Sichtbarkeit der ausgestellten Zertifikate	Nach der Ausstellung
DANE / TLSA	Welches Zertifikat der Client akzeptieren soll	Bei der Verbindung
DNSSEC	Authentizität der DNS-Antworten	Bei jeder Auflösung

Das CAA wirkt im Vorfeld: Es beschränkt, wer ein Zertifikat erzeugen darf. Die Certificate Transparency wirkt im Nachgang: Sie macht jedes ausgestellte Zertifikat öffentlich und damit erkennbar. DANE (DNS-based Authentication of Named Entities) wirkt clientseitig: Es veröffentlicht im DNS, über TLSA-Einträge, den Fingerabdruck des Zertifikats, das der Client erwarten soll, was es erlaubt, ein gültiges, aber unrechtmäßiges Zertifikat abzulehnen. DNSSEC liegt allem zugrunde: Ohne authentifizierte DNS-Antworten sind weder das CAA noch DANE verlässlich.

Eine Verteidigung in der Tiefe

Diese Mechanismen konkurrieren nicht, sie ergänzen sich. Das CAA verhindert die unautorisierte Ausstellung. Geht eine betrügerische Ausstellung dennoch durch, erlaubt die Certificate Transparency, sie zu erkennen. DANE erlaubt dem Client, ein Zertifikat abzulehnen, das nicht dem von dir veröffentlichten entspricht. Und DNSSEC garantiert, dass die von den CAs und Clients gelesenen CAA- und TLSA-Einträge authentisch sind.

Um die Komplementarität von CAA und DANE zu vertiefen, lies unseren vollständigen Leitfaden zu DANE und TLSA. Um im Detail zu verstehen, wie DNSSEC die DNS-Antworten authentifiziert, auf denen das gesamte Gebäude ruht, lies unseren Artikel über die DNSSEC-Vertrauenskette.

Die empfohlene Strategie ist klar: Veröffentliche ein stimmiges CAA, um die Ausstellung zu beschränken, signiere deine Zone mit DNSSEC, um deine Antworten zu authentifizieren, überwache die Certificate Transparency, um jede unerwartete Ausstellung zu erkennen, und setze DANE ein, wenn dein Ökosystem es zulässt (insbesondere für Mail mit MTA-STS und DANE).

Empfohlener Aktionsplan

1. Inventarisiere deine realen CAs: Liste alle Stellen auf, die Zertifikate für deine Domains ausstellen, einschließlich der Drittdienste (CDN, Mail-Gateways, Cloud-Plattformen).
2. Veröffentliche ein permissives CAA: Deklariere zunächst alle deine CAs per issue, ergänze issuewild, wenn du Wildcards nutzt, und ein iodef zu einem überwachten Postfach.
3. Prüfe die Übernahme: Kontrolliere mit dig CAA und bestätige, dass deine Verlängerungen weiterhin durchlaufen.
4. Härte schrittweise: Erwäge accounturi und validationmethods auf kritischen Domains, nachdem du die Unterstützung deiner CA geprüft hast.
5. Signiere deine Zone mit DNSSEC: damit die CAA-Prüfung verlässlich und konform mit den Anforderungen von SC-085v2 ist.
6. Überwache: Integriere die CAA- und DNSSEC-Prüfung in dein Monitoring und werte die iodef-Berichte aus.

FAQ

Was ist ein CAA-Eintrag und wozu dient er?

Ein CAA-DNS-Eintrag (Certificate Authority Authorization, RFC 8659) deklariert, welche Zertifizierungsstellen TLS-Zertifikate für eine Domain ausstellen dürfen. Vor jeder Ausstellung fragt eine konforme CA das DNS ab und verweigert die Ausstellung, wenn sie nicht in der Liste steht. Das CAA verringert so das Risiko der Ausstellung betrügerischer Zertifikate durch eine nicht autorisierte CA.

Ist ein CAA-Eintrag verpflichtend?

Nein. Das CAA ist optional. Ohne CAA kann jede öffentlich anerkannte CA ein Zertifikat für deine Domain ausstellen. Es zu veröffentlichen ist eine dringend empfohlene Sicherheits-Best-Practice, da es die Liste der autorisierten CAs ausdrücklich einschränkt und die mit Fehlausstellung verbundene Angriffsfläche begrenzt.

Was passiert, wenn kein CAA-Eintrag vorhanden ist?

Liegt kein CAA vor, geht eine CA davon aus, dass keine Einschränkung besteht, und stellt nach ihren üblichen Domain-Validierungsprüfungen aus. Konkret kann dann jede öffentliche CA ein Zertifikat für deine Domain ausstellen. Das CAA hat nur dann eine einschränkende Wirkung, wenn es ausdrücklich veröffentlicht wird.

Was ist der Unterschied zwischen den Tags issue und issuewild?

Der Tag issue erlaubt einer CA, klassische (Nicht-Wildcard-)Zertifikate auszustellen. Der Tag issuewild steuert speziell die Wildcard-Zertifikate wie *.captaindns.com. Ist ein issuewild vorhanden, hat es bei Wildcard-Anfragen Vorrang vor issue. Fehlt es, fallen die Wildcards auf die issue-Regeln zurück.

Verhindert ein CAA-Eintrag wirklich die Ausstellung eines betrügerischen Zertifikats?

Es verhindert sie stark, aber nicht absolut. Das CAA beruht auf der Kooperation der CAs, die durch die Baseline Requirements des CA/Browser Forums verpflichtet sind, es zu prüfen. Es schützt nicht vor einer CA, die deine Einträge absichtlich ignorieren würde, noch vor einer Fälschung deiner DNS-Antworten. In Verbindung mit DNSSEC, das diese Antworten authentifiziert, wird es deutlich robuster.

Wie prüft man einen CAA-Eintrag mit dig?

Verwende den Befehl dig CAA captaindns.com +short und ersetze ihn durch deine Domain. Er zeigt die CAA-Einträge im Format flag tag value an, zum Beispiel 0 issue "letsencrypt.org". Gibt der Befehl nichts zurück, ist auf dieser Ebene kein CAA veröffentlicht, aber die Domain kann durch Tree Climbing die Richtlinie eines übergeordneten Namens erben.

Wie funktioniert die CAA-Vererbung bei Subdomains?

Bei einer Anfrage läuft die CA die DNS-Hierarchie von der Subdomain zum Apex hinauf und stoppt beim ersten Namen, der CAA-Einträge besitzt (Tree Climbing, RFC 8659). Eine Subdomain ohne CAA erbt also die Richtlinie ihres Elternteils. Doch sobald eine Subdomain ihr eigenes CAA veröffentlicht, ersetzt sie für diese Subdomain die Eltern-Richtlinie vollständig, ohne Verschmelzung.

Muss ich CAA konfigurieren, wenn ich bereits DNSSEC nutze?

Ja. DNSSEC und CAA decken unterschiedliche Bedürfnisse ab. DNSSEC authentifiziert die Integrität deiner DNS-Antworten, schränkt aber nicht ein, welche CA ein Zertifikat ausstellen darf. Das CAA hingegen deklariert ausdrücklich die autorisierten CAs. DNSSEC macht die CAA-Prüfung zuverlässiger (die CA liest authentische Einträge), ersetzt sie aber nicht. Beide ergänzen sich.

Welche Norm definiert den CAA-Eintrag?

Der CAA-Eintrag ist durch RFC 8659 (2019) definiert, die RFC 6844 (2013) ersetzt. RFC 8657 (2019) ergänzt die Parameter accounturi und validationmethods für das ACME-Ökosystem. Die CAA-Prüfung durch die CAs ist darüber hinaus durch die Baseline Requirements des CA/Browser Forums vorgeschrieben.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

• CAA-Kennungen der CAs herunterladen (CSV)
• CAA-Kennungen der CAs herunterladen (JSON)

Glossar

• CAA (Certificate Authority Authorization): DNS-Eintragstyp (Typ 257), der deklariert, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen.
• CA (Certificate Authority): Zertifizierungsstelle, die befugt ist, von den Browsern anerkannte TLS-Zertifikate auszustellen.
• CA/Browser Forum: Konsortium der CAs und Browser-Hersteller, das die Baseline Requirements definiert, das Regelwerk, das jede öffentliche CA einhalten muss, einschließlich der Pflicht, das CAA zu prüfen.
• Tree Climbing: Algorithmus, mit dem eine CA die DNS-Hierarchie vom angefragten Namen zum Apex hinaufläuft, um die anwendbaren CAA-Einträge zu finden.
• issuewild: CAA-Tag speziell für Wildcard-Zertifikate, vorrangig vor issue in diesem Fall.
• iodef: CAA-Tag, der eine URL (mailto oder HTTPS) angibt, an die unautorisierte Ausstellungsversuche zu melden sind.
• ACME (Automatic Certificate Management Environment): Protokoll (RFC 8555) zur Automatisierung der Ausstellung und Verlängerung von Zertifikaten, insbesondere von Let's Encrypt genutzt.
• Mis-Issuance (Fehlausstellung): Ausstellung eines gültigen Zertifikats für eine Domain ohne Zustimmung ihres Inhabers, durch Fehler oder Kompromittierung der CA.

Quellen

1. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record (IETF)
2. RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding (IETF)
3. CA/Browser Forum: Baseline Requirements
4. Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
5. Let's Encrypt: CAA (offizielle Dokumentation)