DNS Certification Authority Authorization

DNS Certification Authority Authorization (CAA) ist ein DNS-Record-Typ nach RFC 8659, mit dem ein Domaininhaber ausdrücklich festlegt, welche Zertifizierungsstellen (Certificate Authorities, CAs) berechtigt sind, TLS-Zertifikate für seine Domain auszustellen. Vor Einführung von CAA konnte grundsätzlich jede der weltweit über hundert öffentlich vertrauenswürdigen CAs ein Zertifikat für jede beliebige Domain ausstellen — eine Konstellation, die wiederholt zu schwerwiegenden Vorfällen geführt hat, etwa bei der niederländischen CA DigiNotar im Jahr 2011 oder beim Vertrauensverlust gegenüber Symantec ab 2017. CAA reduziert diese Angriffsfläche, indem es die Menge der berechtigten Aussteller per DNS verbindlich einschränkt.

Funktionsweise und Record-Aufbau

Ein CAA-Record besteht aus drei Bestandteilen: einem Flag-Feld, einem Property-Tag und einem Wert. Das gebräuchlichste Tag ist issue, das eine CA für die Ausstellung normaler Zertifikate freigibt. Ein typischer Eintrag sieht so aus: example.com. IN CAA 0 issue "letsencrypt.org". Damit erklärt der Domaininhaber, dass ausschließlich Let's Encrypt für example.com Zertifikate ausstellen darf. Sollen mehrere CAs zugelassen werden, werden entsprechend mehrere CAA-Records nebeneinander veröffentlicht.

Das Tag issuewild regelt analog die Ausstellung von Wildcard-Zertifikaten und kann sich von issue unterscheiden — viele Unternehmen erlauben etwa nur eine bestimmte CA für Wildcards, während mehrere CAs reguläre Zertifikate ausstellen dürfen. Das Tag iodef (Incident Object Description Exchange Format) verweist auf eine Kontaktadresse, an die eine CA Meldungen über Verstoßversuche schickt: example.com. IN CAA 0 iodef "mailto:security@example.com". In der Praxis nutzen nur wenige CAs diese Meldekanäle konsequent, dennoch ist der Eintrag empfehlenswert, um etwaige Hinweise nicht zu verpassen.

Ein leerer issue-Wert in Form von 0 issue ";" verbietet die Ausstellung durch jegliche CA — sinnvoll für reine Mailserver-Domains oder interne Zonen, für die niemals ein öffentliches Zertifikat erzeugt werden soll. Das Critical-Flag (Wert 128) markiert einen Record als zwingend zu verstehen: Eine CA, die ein unbekanntes Critical-Tag nicht interpretieren kann, muss die Ausstellung verweigern.

Verbindlichkeit durch CA/B Forum

CAA ist seit September 2017 als Mandatory Check in den Baseline Requirements des CA/Browser Forums verankert. Jede öffentlich vertrauenswürdige CA muss vor Ausstellung eines Zertifikats eine CAA-Abfrage für die betreffende Domain durchführen und die Ausstellung verweigern, wenn sie nicht in der Liste der erlaubten Aussteller steht. Diese Verpflichtung gilt unabhängig davon, ob der Antragsteller alle anderen Validierungsschritte erfolgreich durchläuft. Verstöße gegen die CAA-Prüfung führen zu Beanstandungen bei Audits und können im Extremfall zum Vertrauensentzug einer CA durch die Browser-Hersteller führen.

CAA wird üblicherweise gegen den autoritativen Nameserver der Domain abgefragt — bei fehlender Antwort auf den genauen Namen wandert die Abfrage in der Domain-Hierarchie nach oben (Tree-Climbing), bis entweder ein Record gefunden oder die TLD erreicht ist. Existieren keinerlei CAA-Records, ist die Ausstellung erlaubt; CAA ist also explizit eine Allowlist, kein implizites Verbot.

Schutz vor Rogue-CA-Ausstellung

Der Kernnutzen von CAA liegt in der Reduzierung der Blast Radius bei Kompromittierung oder Fehlverhalten einer beliebigen anderen CA. Im DigiNotar-Vorfall 2011 wurden über 500 betrügerische Zertifikate ausgestellt — darunter für google.com und für Domains, die anschließend gegen iranische Internetnutzer eingesetzt wurden —, weil ein Angreifer die CA-Infrastruktur übernommen hatte. Mit CAA-Records hätte zumindest jede technisch korrekt arbeitende CA die Ausstellung verweigert. Auch beim Vertrauensverlust gegenüber Symantec ab 2017 zeigte sich, dass eine einzelne kompromittierte oder fehlerhaft auditierte CA das gesamte Zertifikatsökosystem belastet.

CAA ersetzt aber keine der bestehenden Mechanismen. Es ergänzt TLS auf der Ebene der Zertifikatsausstellung und arbeitet komplementär zu DNSSEC, das die Integrität der DNS-Antworten selbst absichert. Ohne DNSSEC könnte ein Angreifer im Netzwerkpfad theoretisch gefälschte CAA-Antworten einschleusen und so eine unerwünschte CA legitimieren. Wir finden in Assessments regelmäßig CAA-Records ohne aktiviertes DNSSEC — die Kombination ist deutlich robuster, weil dann die CAA-Abfrage der CA kryptografisch verifiziert werden kann.

Caveats und Grenzen

CAA wirkt ausschließlich zum Zeitpunkt der Ausstellung. Bereits ausgestellte Zertifikate behalten ihre Gültigkeit auch dann, wenn der Domaininhaber die CAA-Records nachträglich verschärft. Eine Domain, die in der Vergangenheit Zertifikate von einer beliebigen CA bezogen hat, kann durch CAA also nicht rückwirkend bereinigt werden — dafür wäre eine aktive Revocation oder das Auslaufen der bestehenden Zertifikate notwendig.

Weiterhin schützt CAA nicht vor einer CA, die ihre Pflicht zur CAA-Prüfung verletzt. Solche Fälle treten in der Praxis selten, aber wiederholt auf: Mehrere CAs mussten in den letzten Jahren öffentlich Vorfälle eingestehen, in denen CAA-Records ignoriert oder fehlerhaft interpretiert wurden. CAA reduziert das Risiko, beseitigt es aber nicht vollständig. Ergänzend sollte daher das Certificate Transparency Log (CT) überwacht werden — etwa über crt.sh oder censys.io. Jedes von einer öffentlich vertrauenswürdigen CA ausgestellte Zertifikat muss in CT-Logs eingetragen werden, sodass eine unautorisierte Ausstellung dort innerhalb von Minuten bis Stunden sichtbar wird.

Schließlich gilt CAA nur für öffentlich vertrauenswürdige CAs. Interne PKIs, die in eigenen Trust Stores verankert sind, sind durch CAA nicht eingeschränkt — sie müssen über andere Mechanismen kontrolliert werden, etwa Active-Directory-basierte Zertifikatsvorlagen und HSM-gestützte Schlüsselverwaltung.

Zusammenspiel mit DANE und DNSSEC

CAA ist eine von mehreren DNS-basierten Sicherheitsmaßnahmen rund um TLS. Während CAA die Ausstellung neuer Zertifikate steuert, verknüpft DANE (DNS-based Authentication of Named Entities) ein konkretes Zertifikat oder einen öffentlichen Schlüssel direkt mit der Domain — und reduziert so die Abhängigkeit vom CA-Vertrauensmodell auch zur Laufzeit. Beide Verfahren basieren auf DNS und entfalten ihre volle Wirkung erst in Kombination mit DNSSEC, das die Authentizität der DNS-Antworten kryptografisch verifiziert. Auch DNS-Transportverschlüsselung wie DoT trägt zur Gesamtsicherheit bei, indem sie die DNS-Auflösung der Endgeräte vor Mitlesern schützt.

In der Praxis ergibt sich eine sinnvolle Reihenfolge: DNSSEC aktivieren, anschließend CAA-Records mit den tatsächlich genutzten CAs setzen, danach CT-Monitoring etablieren und — sofern für E-Mail-Server relevant — DANE/TLSA-Records ergänzen.

Beispielkonfiguration

Eine typische CAA-Konfiguration für ein Unternehmen, das Let's Encrypt für interne Dienste und einen kommerziellen Aussteller wie Sectigo für Wildcards verwendet, sieht zum Beispiel so aus:

Wichtig: CAA-Records werden auf der Apex-Domain (example.com) gesetzt und gelten dank Tree-Climbing auch für alle Subdomains, sofern dort kein eigener CAA-Record vorhanden ist. Für Subdomains mit abweichenden Anforderungen — etwa eine reine Mailserver-Subdomain ohne TLS-Webdienste — können eigene Records die Eltern-Konfiguration überschreiben.

Relevanz für KMUs

Für kleine und mittlere Unternehmen ist CAA eine der wirkungsvollsten Maßnahmen mit dem geringsten Aufwand: Die Konfiguration ist in der Regel in wenigen Minuten erledigt und kostet außer der Pflege der Record-Liste keine laufenden Ressourcen. Wir finden in Assessments dennoch häufig Domains ohne jeden CAA-Record — und damit eine unnötig große Angriffsfläche für Zertifikatsmissbrauch. Besonders Unternehmen, die nur eine oder zwei CAs nutzen, sollten ihre Domain entsprechend einschränken und die Records bei jedem CA-Wechsel mit anpassen. In Kombination mit DNSSEC und CT-Log-Monitoring entsteht so eine belastbare Verteidigung gegen Zertifikatsmissbrauch, die auch ohne dediziertes Security-Team realistisch zu betreiben ist.