CAA-Records erklärt: Wer Ihre Zertifikate ausstellen darf

Technisch kann jede öffentlich vertrauenswürdige Zertifizierungsstelle ein Zertifikat für jede Domain ausstellen. Das System verlässt sich darauf, dass jede CA die Kontrolle über die Domain ordentlich prüft, und die Geschichte kennt Beispiele, in denen das schiefging. Ein CAA-Record (Certification Authority Authorization) ist Ihr Mittel, den Kreis einzuschränken: ein DNS-Eintrag, der sagt „nur diese CAs dürfen Zertifikate für diese Domain ausstellen“. Eine CA, die nicht aufgeführt ist, muss ablehnen.

Es kostet nichts, dauert fünf Minuten und kann Ihnen auf genau eine Weise schaden: wenn Sie beim Wechsel der CA vergessen, dass der Record existiert. Dieser Leitfaden behandelt beide Seiten.

Was CAA leistet und was nicht

CAA ist in RFC 8659 definiert (der den ursprünglichen RFC 6844 abgelöst hat), und seit September 2017 verpflichten die Baseline Requirements des CA/Browser Forum jede öffentlich vertrauenswürdige CA, CAA vor der Ausstellung zu prüfen.

Geprüft wird von der CA, zum Zeitpunkt der Ausstellung. Browser sehen den Record nie an. Ein Zertifikat, das ausgestellt wurde, während CAA es erlaubte, bleibt gültig, auch wenn Sie den Record später ändern.
Kein CAA-Record bedeutet keine Einschränkung. Jede CA darf ausstellen, wie bisher.
Er verringert das Risiko einer Fehlausstellung über eine CA, die Sie nicht nutzen, etwa durch jemanden, der kurzzeitig einen Webserver oder ein Postfach kontrolliert und es bei einer CA mit einer schwächeren Prüfmethode versucht. Einen Angreifer, der Ihr DNS kontrolliert, hält er nicht auf, denn der kann auch den CAA-Record ändern.
Er ist kein Widerrufsmechanismus und kein Ersatz für die Überwachung der Certificate-Transparency-Logs.

Aufbau eines CAA-Records

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ value
;                                │ └ tag
;                                └ flags

Flags ist praktisch immer 0. Der Wert 128 setzt das „critical“-Bit: Eine CA, die das Tag nicht versteht, darf dann nicht ausstellen.

Tags:

Tag	Bedeutung
`issue`	Die genannte CA darf Zertifikate für diesen Namen ausstellen. Gilt auch für Wildcard-Zertifikate, sofern kein `issuewild` vorhanden ist.
`issuewild`	Regeln nur für Wildcard-Zertifikate. Falls vorhanden, ersetzt es `issue` für Wildcard-Anfragen.
`iodef`	Wohin eine CA eine Anfrage melden darf, die gegen die Richtlinie verstoßen hat (`mailto:` oder `https:`). Die Unterstützung bei den CAs ist begrenzt; betrachten Sie es als optional.
`issuemail`	Dieselbe Kontrolle für S/MIME-Zertifikate (RFC 9495).

Der Wert für issue/issuewild ist der Domainname zur Identifizierung, den jede CA dokumentiert, etwa auf ihrer CAA- oder CPS-Seite. Er ist nicht immer der Markenname oder die Website der CA, und CAs, die Zertifikate einer anderen CA weiterverkaufen, verwenden die Kennung der vorgelagerten CA. Schlagen Sie ihn nach; raten Sie nicht. Der besondere Wert ";" bedeutet „niemand“.

Beispiele

Eine CA, keine Wildcards, mit einer Meldeadresse:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Zwei CAs (etwa Ihre ACME-CA und die, die Ihr CDN verwendet):

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

Eine Domain, die nie Zertifikate haben soll:

parked.example.  IN  CAA  0 issue ";"

Wildcards von einer anderen CA als gewöhnliche Zertifikate:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

Wie eine CA den maßgeblichen Record findet

Das ist der Teil, den viele falsch verstehen. Für einen Zertifikatsantrag, der www.shop.example.com abdeckt, geht die CA so vor:

Sie fragt CAA unter www.shop.example.com ab;
gibt es dort kein CAA-Record-Set, fragt sie shop.example.com;
dann example.com, und so weiter den Baum hinauf;
sie hält beim ersten Namen an, der irgendwelche CAA-Records hat, und verwendet nur diese.

Die Folgen:

Ein Record unter example.com deckt jede Subdomain ab, die kein eigenes CAA hat.
Records werden nicht zusammengeführt. Ein CAA unter shop.example.com ersetzt für alles unter shop vollständig den Record unter example.com. Das können Sie gezielt nutzen, um einer Subdomain eine andere CA zu geben.
CNAMEs werden verfolgt. Ist shop.example.com ein CNAME auf stores.saas.example, wird die CAA-Abfrage für shop.example.com mit den CAA-Records des Ziels beantwortet. Die CAA-Richtlinie eines SaaS-Anbieters kann also für Ihren Hostnamen gelten. Nach dem aktuellen RFC steigt die CA nicht den Baum des Ziels hinauf; hat das Ziel kein CAA, geht der Aufstieg bei Ihrer übergeordneten Domain example.com weiter.
Ein Fehlschlag der Abfrage ist nicht dasselbe wie „kein Record“. Bekommt die CA keine saubere Antwort (Timeout, SERVFAIL, kaputtes DNSSEC), darf sie nicht ausstellen. Unzuverlässiges autoritatives DNS zeigt sich als fehlgeschlagene Verlängerungen.

Jeder Name in einem Zertifikat mit mehreren Namen wird einzeln geprüft.

Ausstellung an ein Konto oder eine Methode binden

RFC 8657 ergänzt Parameter, die CAA für ACME-Nutzer erheblich stärker machen:

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi beschränkt die Ausstellung auf ein ACME-Konto, sodass jemand anderes mit einem Konto bei derselben CA kein Zertifikat bekommt, selbst wenn er die Validierung besteht. validationmethods beschränkt, wie die Kontrolle nachgewiesen werden darf. Beides funktioniert nur bei CAs, die es umsetzen; prüfen Sie die Dokumentation der CA, bevor Sie sich darauf verlassen, und denken Sie daran, den Record zu aktualisieren, falls Sie das ACME-Konto jemals neu anlegen.

CAA einführen, ohne etwas kaputtzumachen: eine Checkliste

Finden Sie heraus, wer heute für Sie ausstellt. Sehen Sie sich die Zertifikate auf jedem Hostnamen an oder durchsuchen Sie die Certificate-Transparency-Logs nach Ihrer Domain. Typische Überraschungen: das CDN, die verwalteten Zertifikate des Load Balancers, der gehostete Shop, die Statusseite, der E-Mail-Dienst und ein internes Team, das eine andere ACME-CA verwendet.
Sammeln Sie die CAA-Kennung jeder CA aus deren Dokumentation.
Prüfen Sie Subdomains, die CNAMEs auf Dritte sind: Fragen Sie CAA auf ihnen ab und sehen Sie, was zurückkommt.
Veröffentlichen Sie die Records am Zonen-Apex mit einer moderaten TTL (3600). CAs dürfen das Ergebnis einer CAA-Prüfung höchstens für die TTL des Records oder 8 Stunden zwischenspeichern, je nachdem, was länger ist.
Testen Sie sofort eine Verlängerung (certbot renew --dry-run führt eine vollständige Validierung gegen die Staging-Umgebung durch, die bei den meisten ACME-CAs eine CAA-Prüfung einschließt), statt es in 60 Tagen zu erfahren.
Dokumentieren Sie es dort, wo die nächste Person nachsieht, wenn sie CDN oder CA wechselt.

Abfragen, was veröffentlicht ist:

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # empty → the CA will climb

Häufige Fehler

CDN oder Hosting-Anbieter wechseln und vergessen, dass der neue eine andere CA verwendet. Das neue Zertifikat wird stillschweigend nicht ausgestellt, und das alte läuft ab. Siehe SSL-Zertifikat abgelaufen: Was tun.
Den Marketingnamen der CA statt ihrer dokumentierten CAA-Kennung verwenden.
issuewild ";", während irgendwo ein Wildcard-Zertifikat im Einsatz ist.
Glauben, ein issue am Apex und ein weiteres issue auf einer Subdomain addierten sich. Das Set der Subdomain gilt allein.
Ein DNS-Anbieter, der den Typ CAA nicht unterstützt, und der Versuch, den Record als TXT abzulegen. Das bewirkt nichts.
Fehler mit Anführungszeichen in Verwaltungsoberflächen: Der Wert ist eine Zeichenkette in Anführungszeichen, Flag und Tag sind es nicht.
Erwarten, dass CAA bestehende Zertifikate ungültig macht. Es betrifft nur neue Ausstellungen.
Nameserver wechseln und die CAA-Records nicht mitkopieren; sie gehören zu den Records, die am häufigsten verloren gehen, wie in Nameserver ohne Ausfall wechseln angemerkt.

Mit OrbitProbe prüfen

Die DNS-Abfrage von OrbitProbe fragt CAA als einen der Record-Typen ab, mit der TTL, so wie öffentliche Resolver ihn in diesem Moment zurückgeben. Führen Sie sie zuerst für die reine Domain aus, dann für jede Subdomain, die ein CNAME auf einen externen Dienst ist, um zu sehen, welche Richtlinie eine CA dort tatsächlich vorfinden würde. Wie sich CAA in die übrigen Record-Typen einordnet, zeigt der Beitrag DNS-Record-Typen erklärt.