So konfigurieren Sie CAA-Einträge richtig

Ein Certification-Authority-Authorization-Record (CAA) gehört zu den einfachsten Sicherheitsmaßnahmen, die Sie für eine Domain treffen können – und zugleich zu denen, die man am leichtesten auf subtile Weise falsch macht. Es handelt sich um einen DNS-Record, der sinngemäß sagt: „Nur diese Zertifizierungsstellen dürfen TLS-Zertifikate für diesen Namen ausstellen.“ Seit September 2017 verpflichten die Baseline Requirements des CA/Browser Forums jede öffentlich vertrauenswürdige Zertifizierungsstelle, CAA vor der Ausstellung eines Zertifikats zu prüfen. Existiert der Record und autorisiert er die CA nicht, muss die Anfrage abgelehnt werden.

Damit schützt CAA wirksam vor Fehlausstellungen: etwa durch ein kompromittiertes Konto bei einer anderen CA, einen Mitarbeiter, der unbedacht bei einem nicht freigegebenen Anbieter bestellt, oder eine CA, deren Domainvalidierung ausgetrickst wird. Es bedeutet aber auch, dass ein fehlerhafter CAA-Record unbemerkt Ihre eigenen Zertifikatsverlängerungen blockieren kann. Dieser Leitfaden erklärt die in RFC 8659 definierte Syntax, die Tags, die Sie wirklich brauchen, wie CAs die Records nachschlagen und wie Sie alles testen, bevor es darauf ankommt.

Was ein CAA-Record enthält

RFC 8659 wurde 2019 veröffentlicht, löste das ursprüngliche RFC 6844 ab und ist der aktuelle Standard. Jeder CAA-Record besteht aus drei Teilen:

• Flags – eine Zahl von 0 bis 255. In der Praxis verwenden Sie 0. Der Wert 128 setzt das „Issuer Critical“-Bit, das einer CA vorschreibt, die Ausstellung zu verweigern, wenn sie den Tag nicht versteht.
• Tag – der Name der Eigenschaft, etwa issue, issuewild oder iodef.
• Wert – ein Text in Anführungszeichen, dessen Bedeutung vom Tag abhängt, meist der Domainname einer CA.

In Zonendatei-Syntax sieht ein einfacher Record so aus:

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"

Sie können mehrere CAA-Records unter demselben Namen veröffentlichen. Jeder issue-Record fügt eine weitere zugelassene CA hinzu; die Einträge werden kombiniert, nicht überschrieben.

Die drei Tags, die Sie kennen sollten

issue

Der Tag issue erlaubt einer CA, beliebige Zertifikate für den Namen auszustellen – auch Wildcards, sofern kein issuewild-Record etwas anderes festlegt. Der Sonderwert eines einzelnen Semikolons, ";", bedeutet „keine CA ist erlaubt“. Das ist nützlich für Domains, die nie ein Zertifikat haben sollen, etwa geparkte Namen oder reine Mail-Domains.

issuewild

Der Tag issuewild gilt ausschließlich für Wildcard-Zertifikate wie *.example.com. Sobald mindestens ein issuewild-Record vorhanden ist, ignorieren CAs issue bei Wildcard-Anfragen und richten sich nur noch nach issuewild. Ein gängiges Muster erlaubt normale Zertifikate von einer CA und blockiert Wildcards komplett:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

iodef

Der Tag iodef nennt eine URL, an die eine CA Anfragen melden kann, die sie aufgrund Ihrer Richtlinie abgelehnt hat. Erlaubt sind mailto:- und https:-Adressen. Die Unterstützung ist optional – betrachten Sie es also als zusätzliches Signal, nicht als Monitoring-System.

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

CA-Kennungen gängiger Anbieter

Der Wert eines issue-Records muss exakt der Kennung entsprechen, die die CA selbst veröffentlicht, meist in ihrer Certificate Policy oder CPS. Ein falscher String ist die häufigste Ursache für gescheiterte Ausstellungen. Die folgenden Kennungen sind breit dokumentiert, prüfen Sie aber vor dem Einsatz die aktuelle Dokumentation Ihrer CA.

Denken Sie daran, dass viele Dienste Zertifikate in Ihrem Namen beziehen. Ein CDN, ein Managed-WordPress-Host oder ein E-Mail-Sicherheitsprodukt nutzt womöglich eine CA, die Sie nie selbst ausgewählt haben. Bevor Sie die Schrauben anziehen, klären Sie, welche CA jeder Dienst vor Ihrer Domain verwendet.

Wie CAs Ihren Record finden: Tree Climbing

Eine CA prüft nicht nur den exakten Namen aus der Zertifikatsanfrage. RFC 8659 definiert eine Suche, die beim angefragten Namen beginnt und Label für Label nach oben wandert. Der erste Name, der ein nicht leeres CAA-Record-Set liefert, ist maßgeblich – dort endet die Suche.

Bei einer Anfrage für shop.eu.example.com prüft die CA in dieser Reihenfolge:

1. shop.eu.example.com
2. eu.example.com
3. example.com
4. com

Daraus folgen zwei praktische Konsequenzen. Erstens schützt ein einziges Record-Set am Apex in der Regel alle Subdomains, weshalb die meisten Domains CAA nur bei example.com brauchen. Zweitens ersetzt ein CAA-Record auf einer Subdomain die Apex-Richtlinie für diesen Teilbaum vollständig, er ergänzt sie nicht. Setzen Sie 0 issue "digicert.com" auf eu.example.com, ist Let’s Encrypt dort nicht mehr erlaubt, selbst wenn der Apex es zulässt. Gibt es in der gesamten Kette keinen CAA-Record, darf jede CA ausstellen.

CNAME-Records und CAA

Bei CNAMEs wird CAA verwirrend. Fragt eine CA den CAA-Typ für einen Namen ab, der ein CNAME ist, folgt die normale DNS-Auflösung dem Alias und liefert die CAA-Records des Ziels. Hat das Ziel CAA-Records, gelten diese für den ursprünglichen Namen.

Hat das Alias-Ziel keine CAA-Records, klettert die CA laut RFC 8659 im Baum des ursprünglichen Namens weiter, nicht bei den Elternnamen des Ziels. Das frühere Verhalten aus RFC 6844, auch den Baum des Ziels hinaufzuklettern, wurde gestrichen. Relevant ist das, wenn www.example.com etwa auf example.cdn-provider.net zeigt:

• Veröffentlicht das CDN CAA am Ziel, gilt dessen Richtlinie für Ihren www-Namen, und Ihr Apex-Record wird nie erreicht.
• Hat das Ziel kein CAA, geht die CA weiter zu example.com und wendet Ihre Apex-Richtlinie an.

Da Sie neben einem CNAME keine weiteren Records unter demselben Namen veröffentlichen können, lässt sich die Richtlinie des Ziels am Alias selbst nicht überschreiben. Blockiert das CAA eines Anbieters die CA, die Sie brauchen, wenden Sie sich an den Anbieter oder wählen Sie ein anderes Hostnamen-Setup.

Konfiguration Schritt für Schritt

1. Zertifikate inventarisieren. Listen Sie jeden Hostnamen mit TLS und die ausstellende CA auf. Certificate-Transparency-Logs wie crt.sh helfen, vergessene Zertifikate zu finden.
2. Richtlinie festlegen. Entscheiden Sie, welche CAs Sie zulassen und ob Wildcards nötig sind.
3. Records am Apex veröffentlichen. Ein issue pro CA, optional issuewild, dazu ein iodef-Kontakt.
4. Anfangs eine niedrige TTL nutzen. Eine TTL von etwa 300 Sekunden erlaubt schnelle Korrekturen; erhöhen Sie sie, sobald alles stabil läuft.
5. Eine Verlängerung testen. Lösen Sie eine Staging- oder Dry-Run-Verlängerung aus, um zu bestätigen, dass die CA weiterhin ausstellen kann.

Ein vollständiges Beispiel für eine Domain, die Let’s Encrypt für die Website und Sectigo für ein Wildcard-Zertifikat nutzt:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "sectigo.com"
example.com.  3600  IN  CAA  0 issuewild "sectigo.com"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Manche CAs unterstützen zusätzlich Parameter aus RFC 8657, etwa accounturi, um die Ausstellung auf ein einzelnes ACME-Konto zu beschränken, oder validationmethods, um nur bestimmte Validierungsarten zuzulassen. Das erhöht die Sicherheit weiter – prüfen Sie aber vorher, ob Ihre CA diese Parameter unterstützt.

CAA-Records mit dig testen

Fragen Sie immer das öffentliche DNS ab, statt dem Dashboard Ihres Anbieters zu vertrauen. Diese Befehle zeigen, was eine CA sieht:

dig example.com CAA +short
dig www.example.com CAA +short
dig @1.1.1.1 example.com CAA
dig +trace example.com CAA

Eine gesunde Antwort für das obige Beispiel sieht so aus:

0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"

Liefert eine Subdomain nichts zurück, ist das normal – die CA klettert zum Elternnamen. Was Sie nicht sehen wollen, ist ein SERVFAIL. Eine CA, die keine eindeutige Antwort erhält, verweigert in der Regel die Ausstellung, und manche ältere DNS-Server und Appliances reagieren schlecht auf den CAA-Typ. Wenn Sie zusätzlich sehen möchten, welche Nameserver und welchen Registrar eine Domain nutzt, zeigt der WHOIS-Lookup von TLDix das zusammen mit dem Ablaufdatum.

Praxistipp: CAA bei mehreren Domains verwalten

Wer ein ganzes Portfolio betreut, sollte CAA nicht Domain für Domain improvisieren. Legen Sie eine Standardrichtlinie fest, etwa eine erlaubte CA plus iodef, und dokumentieren Sie Ausnahmen in einer einfachen Tabelle. Domains ohne Website, zum Beispiel Tippfehler-Varianten oder Markenschutz-Registrierungen, erhalten am besten 0 issue ";". So fällt sofort auf, wenn für einen dieser Namen plötzlich doch ein Zertifikat beantragt wird.

Häufige Fehler vermeiden

• CA wechseln, ohne CAA anzupassen. Erst die neue CA eintragen, dann das Zertifikat ausstellen, danach die alte entfernen.
• Tippfehler in Kennungen. letsencrypt.com oder lets-encrypt.org blockieren die Ausstellung stillschweigend.
• Drittanbieter vergessen. Ein CDN oder eine SaaS-Custom-Domain kann einen eigenen CA-Eintrag erfordern.
• Das Critical-Flag leichtfertig setzen. 128 bei einem unbekannten Tag stoppt jede Ausstellung.
• DNSSEC ignorieren. CAA ist nur so vertrauenswürdig wie die DNS-Antwort; DNSSEC erschwert Spoofing erheblich.

CAA wirkt am besten als Teil einer umfassenderen Routine: Ablaufdaten von Zertifikaten verfolgen, Certificate-Transparency-Logs beobachten und DNS-Änderungen überprüfen. Wenn Ihnen Record-Typen noch neu sind, ist unser Leitfaden zu den Grundlagen von DNS-Records ein guter Einstieg.