CAA-Eintrag: festlegen, wer Zertifikate für Deine Domain ausstellt

Wozu CAA da ist

Browser vertrauen Dutzenden Zertifizierungsstellen (CAs). Jede davon kann ein gültiges Zertifikat für Deine Domain ausstellen, und für ein falsches genügt eine, die sich täuschen lässt.

Der CAA-Eintrag (Certification Authority Authorization, RFC 8659) verkleinert diesen Kreis. Darin steht, welche CAs für Deine Domain ausstellen dürfen. Seit dem 8. September 2017 müssen alle öffentlichen CAs ihn vor jeder Ausstellung abfragen, so verlangen es die Baseline Requirements des CA/Browser Forums. Steht dort nur ein fremder Name, lehnt die CA den Antrag ab.

Was CAA nicht leistet

Browser schauen nie in den CAA-Eintrag. RFC 8659 verbietet sogar ausdrücklich, ihn bei der Prüfung eines Zertifikats heranzuziehen. Ein Zertifikat, das eine CA trotz Verbot ausstellt, funktioniert also ganz normal. Bestehende Zertifikate bleiben ebenfalls unberührt. Ein neuer CAA-Eintrag wirkt erst bei der nächsten Ausstellung oder Erneuerung.

Wer sehen will, was tatsächlich ausgestellt wurde, findet alle öffentlichen Zertifikate in den Certificate-Transparency-Logs, etwa über crt.sh. Mehr zum Zertifikat selbst steht im Artikel über TLS.

Aufbau des Eintrags

Jeder CAA-Eintrag besteht aus Flags, Tag und Wert:

beispiel.de.  CAA  0 issue "letsencrypt.org"
beispiel.de.  CAA  0 issuewild ";"
beispiel.de.  CAA  0 iodef "mailto:sicherheit@beispiel.de"

Tag	Bedeutung
issue	Diese CA darf Zertifikate ausstellen. Mehrere issue-Einträge gelten nebeneinander.
issuewild	Nur für Wildcard-Zertifikate (*.beispiel.de), hat dort Vorrang vor issue
iodef	Adresse (mailto: oder https:) für Meldungen über Anträge, die gegen den Eintrag verstoßen

Das Flag steht fast immer auf 0. Mit 128 wird ein Eintrag kritisch, und eine CA, die das Tag nicht kennt, darf dann überhaupt nicht ausstellen. Der Wert ";" ohne CA-Namen verbietet die Ausstellung. Fehlt issuewild, gelten für Wildcards die issue-Einträge. Enthält der Eintrag weder issue noch issuewild, schränkt er gar nichts ein. Auf Meldungen an die iodef-Adresse solltest Du Dich nicht verlassen.

Welche Ebene zählt

Die CA beginnt beim genauen Namen aus dem Antrag und arbeitet sich nach oben. Für shop.beispiel.de fragt sie erst shop.beispiel.de, dann beispiel.de, dann de. Der erste Name mit CAA-Einträgen entscheidet. Ein Eintrag bei beispiel.de gilt damit für alle Subdomains ohne eigenen Eintrag. Hat shop einen eigenen, zählt für shop nur noch dieser.

Zeigt www per CNAME auf einen Namen beim Hoster, bekommt die CA die CAA-Einträge dieses Ziels. Hat das Ziel keine, sucht sie bei beispiel.de weiter.

Die Namen der Zertifizierungsstellen

Welchen Namen eine CA im Eintrag erwartet, legt sie selbst fest:

CA	Wert für issue
Let's Encrypt	letsencrypt.org
Sectigo	sectigo.com
DigiCert (auch RapidSSL, GeoTrust, Thawte)	digicert.com
Google Trust Services	pki.goog
AWS Certificate Manager	amazon.com, amazontrust.com, awstrust.com oder amazonaws.com
GlobalSign	globalsign.com
SSL.com	ssl.com

Let's Encrypt versteht außerdem die Parameter aus RFC 8657. Mit accounturi bindest Du die Erlaubnis an ein bestimmtes ACME-Konto, mit validationmethods an Prüfverfahren wie dns-01. Ziehst Du später auf einen neuen Server mit neuem Konto um, scheitert die Erneuerung, bis der Eintrag angepasst ist. Bei CAs, die die Parameter nicht auswerten, schränken sie nichts ein.

Typische Fehler

• Die CA des CDN oder Hosters fehlt. Cloudflare holt seine Universal-SSL-Zertifikate bei Let's Encrypt, Google Trust Services und SSL.com, Ersatzzertifikate bei Sectigo. Liegt Dein DNS bei Cloudflare, ergänzt Cloudflare diese CAs selbst, sobald Du einen CAA-Eintrag anlegst; im Dashboard tauchen sie nicht auf.
• Ein issuewild ";" aus einer Vorlage, obwohl irgendwo ein Wildcard-Zertifikat läuft. Das fällt erst bei der nächsten Erneuerung auf, also womöglich Monate später.
• Der Eintrag liegt auf der falschen Ebene. Ein vergessener Eintrag bei www überdeckt den neuen bei der Hauptdomain.
• Der DNS-Anbieter kann kein CAA. Manche Oberflächen bieten den Typ nicht an. Heikler sind Nameserver, die auf CAA-Anfragen mit einem Fehler antworten oder gar nicht. Let's Encrypt stellt dann nicht aus, auch wenn überhaupt kein Eintrag existiert.

Ohne DNSSEC kann ein Angreifer, der die DNS-Antworten an eine CA fälscht, auch den CAA-Eintrag verschwinden lassen. Ist Deine Zone signiert, erkennt die CA eine solche Fälschung, und der Eintrag wird belastbarer.

Eintrag anlegen

Schau vorher in den Certificate-Transparency-Logs nach, welche CAs bisher für Deine Domain ausgestellt haben. Vergiss dabei weder den Mailserver noch Subdomains, die ein Dienstleister für Dich betreibt. In der Zonendatei sieht das dann etwa so aus:

beispiel.de.  3600  IN  CAA  0 issue "letsencrypt.org"
beispiel.de.  3600  IN  CAA  0 issue "pki.goog"
beispiel.de.  3600  IN  CAA  0 issuewild "letsencrypt.org"
beispiel.de.  3600  IN  CAA  0 iodef "mailto:sicherheit@beispiel.de"

Normale Zertifikate dürfen hier Let's Encrypt und Google Trust Services ausstellen, Wildcards nur Let's Encrypt.

In den Weboberflächen der DNS-Anbieter gibt es meist drei Felder für Flags, Tag und Wert. Ob der Wert Anführungszeichen braucht oder die Oberfläche sie selbst setzt, ist von Anbieter zu Anbieter verschieden. Prüf danach mit dig beispiel.de CAA, was wirklich im DNS steht.

CAA prüfen

Gibst Du Deine Adresse bei ZwoWebCheck ein, zeigt der Bericht, ob für Deinen Host ein CAA-Eintrag gilt und ob er die CA erlaubt, von der Dein aktuelles Zertifikat stammt. Gleich daneben steht, ob Deine Zone mit DNSSEC signiert ist. Fehlt der Eintrag und kennen wir Deine CA, findest Du im Bericht auch einen fertigen Vorschlag.