CAA und DNSSEC: zwei DNS-Einträge gegen fremde Zertifikate

TLS-Zertifikate beweisen eines: dass jemand zum Zeitpunkt der Ausstellung Kontrolle über die Domain nachweisen konnte. Fast alle automatisierten Prüfungen laufen dafür über DNS oder über einen HTTP-Abruf, der wiederum per DNS gefunden wird. Damit ist DNS die eigentliche Angriffsfläche, nicht der Webserver, nicht der private Schlüssel. Zwei Einträge begrenzen den Schaden: CAA sagt, wer ausstellen darf, DNSSEC macht die Antwort fälschungssicher.

Was die beiden Einträge tun und was nicht#

Die Reihenfolge ist keine Geschmacksfrage: CAA ohne DNSSEC ist eine Bitte, kein Riegel. Wer DNS-Antworten fälschen kann, fälscht auch den CAA-Eintrag weg. Erst DNSSEC macht aus der Bitte eine überprüfbare Aussage. Umgekehrt bringt DNSSEC allein nichts gegen eine CA, die nach einer echten, bestandenen Prüfung ausstellt, dafür braucht es CAA.

CAA setzen: drei Zeilen, eine Entscheidung#

CAA ist ein gewöhnlicher DNS-Eintrag am Apex der Domain. Das Format und die Prüfpflicht stehen in RFC 8659; verbindlich wird die Prüfung über die Baseline Requirements des CA/Browser-Forums, an die sich jede öffentlich vertraute CA halten muss.

example.de.  IN  CAA  0 issue "letsencrypt.org"
example.de.  IN  CAA  0 issuewild ";"
example.de.  IN  CAA  0 iodef "mailto:[email protected]"

Zeile für Zeile:

• issue, diese CA darf einzelne Namen ausstellen. Mehrere Zeilen für mehrere CAs.
• issuewild ";", Wildcard-Zertifikate darf niemand ausstellen. Das Semikolon ist die ausdrückliche Verweigerung. Wer Wildcards braucht, setzt hier dieselbe CA wie oben; wer keine braucht, schließt eine ganze Angriffsklasse aus.
• iodef, wohin ein Bericht geht, wenn eine CA eine abgelehnte Anfrage meldet. Optional, aber die einzige Stelle, an der du von einem Versuch überhaupt erfährst.

Prüfen, bevor man sich darauf verlässt:

dig CAA example.de +short
# 0 issue "letsencrypt.org"
# 0 issuewild ";"
# 0 iodef "mailto:[email protected]"

Die CA-Kennungen sind fest vorgegeben und nicht frei wählbar; sie stehen in der Dokumentation der jeweiligen Stelle (letsencrypt.org, sectigo.com, digicert.com, pki.goog). Ein Tippfehler dort sperrt still die eigene Erneuerung, deshalb gehört der Test oben in dieselbe Sitzung wie die Änderung, nicht in die nächste Woche. Wie die Erneuerung selbst zuverlässig läuft, steht in TLS-Zertifikate automatisieren.

DNSSEC einschalten: der Teil, den man nicht halb macht#

DNSSEC signiert die Antworten deiner Zone (RFC 9364 fasst den heutigen Stand zusammen). Der Auflöser prüft die Kette vom Wurzelserver über die Registry bis zu dir; bricht sie, gibt es keine Antwort, statt einer falschen. Das ist die Stärke des Verfahrens und zugleich der Grund, warum ein halber Aufbau die Domain unerreichbar macht.

Bei den meisten Anbietern sind es heute zwei Schritte:

1. Signieren lassen, beim DNS-Betreiber, meist ein Schalter. Er erzeugt die Schlüssel und liefert einen DS-Eintrag.
2. DS-Eintrag bei der Registry hinterlegen, dort, wo die Domain registriert ist. Erst dieser Schritt schließt die Vertrauenskette.

Wer beides beim selben Anbieter hat, sieht oft nur einen Schalter. Wer DNS und Registrierung getrennt hat, muss den DS-Eintrag von Hand übertragen und genau dort entstehen die Ausfälle.

# Sind Schlüssel da?
dig DNSKEY example.de +short

# Ist die Kette geschlossen? Das ad-Flag ist die Antwort.
dig +dnssec example.de A | grep -E "^;; flags|RRSIG"
# ";; flags: qr rd ra ad;" -- ad = authentic data

# Gegenprobe von außen, gegen einen prüfenden Auflöser
dig @9.9.9.9 +dnssec example.de A | grep "flags"

Was danach messbar besser ist und was nicht#

Ehrlich bleiben, sonst ist es Sicherheitstheater:

• Besser: Eine fremde CA kann nicht mehr still für deine Domain ausstellen. Ein DNS-Angriff auf dem Weg zum Auflöser führt zu keiner Antwort statt zu einer falschen. Beides gilt sofort und für alle künftigen Ausstellungen.
• Nicht besser: Wer Zugriff auf dein DNS-Konto hat, ändert CAA und DNSSEC mit. Beides schützt gegen fremde Ausstellung und gegen Manipulation unterwegs, nicht gegen ein übernommenes Konto. Der zweite Faktor am DNS-Anbieter ist deshalb die Maßnahme, die logisch vor diesen beiden kommt, siehe Zweiter Faktor, der wirklich trägt.
• Unverändert: Ein bereits ausgestelltes fremdes Zertifikat wird durch einen späteren CAA-Eintrag nicht ungültig. Wer wissen will, was auf seinen Namen existiert, sieht in den Transparenzprotokollen nach, dieselbe Außensicht wie beim Messen der Angriffsfläche.

Häufige Fragen#

Bremst CAA meine automatische Erneuerung?#

Nein, solange die ausstellende CA im Eintrag steht. Der Eintrag wird bei jeder Ausstellung geprüft, also auch bei jeder Erneuerung, der Fehlerfall ist immer derselbe: falsche oder fehlende Kennung. Deshalb gehört ein dig CAA in dieselbe Prüfliste wie das Ablaufdatum.

Brauche ich DNSSEC, wenn meine Zone bei einem großen Anbieter liegt?#

Der Anbieter schützt den Weg zwischen sich und dir, nicht den zwischen sich und dem Auflöser des Besuchers. Genau dort setzt Manipulation an. Wenn der Anbieter Signierung anbietet, gibt es wenig Grund, sie nicht einzuschalten, der Aufwand liegt im DS-Eintrag, nicht im Betrieb.

Was ist mit DANE und TLSA?#

DANE bindet ein Zertifikat direkt an einen DNS-Eintrag und setzt DNSSEC zwingend voraus. Für Mailserver ist das verbreitet und sinnvoll; für Webseiten unterstützt es kein verbreiteter Browser. CAA und DNSSEC sind der Teil, der überall wirkt.

Wie merke ich, dass jemand versucht hat, ein Zertifikat zu bekommen?#

Über den iodef-Eintrag, sofern die betroffene CA Berichte verschickt; verbindlich ist das nicht. Zuverlässiger ist die Gegenrichtung: die öffentlichen Transparenzprotokolle beobachten und bei einem unerwarteten Zertifikat auf deine Domain nachfragen. Das gehört in dieselbe regelmäßige Außensicht wie der Portscan.

Danach#

Beides ist Einrichtung, kein Dauerbetrieb, mit zwei Ausnahmen, die in die Wartungsliste gehören: vor jedem CA-Wechsel den CAA-Eintrag ergänzen, und vor jedem Umzug des DNS-Betreibers den DS-Eintrag zurückbauen. Wer das übersieht, erzeugt einen Ausfall, der von außen wie ein Angriff aussieht und es nicht ist.