Ein CAA-Record definiert, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen können. Er dient als Schutzmaßnahme. Eine nicht aufgelistete Stelle muss die Ausstellung verweigern. CAA funktioniert durch Vererbung. Ohne Regel auf einer Subdomain gilt die Regel des Apex.
Ein CAA-Record enthält einen Namen, einen Typ, eine Flagge, ein Tag, einen Wert und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.
| Name | Typ | Flag | Tag | Wert | TTL in Sekunden |
|---|
| @ | CAA | 0 | issue | "letsencrypt.org" | 3600 |
In diesem Beispiel erlaubt die Zone Let's Encrypt, Zertifikate für die Domain auszustellen. Die Flagge Null eignet sich für übliche Verwendungszwecke. Die TTL von 3600 entspricht einer Stunde.
| Name | Typ | Flag | Tag | Wert | Rolle |
|---|
| @ | CAA | 0 | issue | "digicert.com" | Eine Stelle autorisieren |
| @ | CAA | 0 | issuewild | "letsencrypt.org" | Wildcard-Zertifikate erlauben |
| @ | CAA | 0 | iodef | "mailto:security@beispiel.com" | Vorfallberichte empfangen |
| @ | CAA | 0 | issue | ";" | Jede Ausstellung verbieten |
Das Tag "issue" erlaubt die Ausstellung klassischer Zertifikate. Das Tag "issuewild" zielt auf Wildcard-Zertifikate ab. Das Tag "iodef" gibt an, wohin ein Bericht bei unbefugten Versuchen gesendet werden soll.
CAA am Apex veröffentlichen, um die gesamte Domain abzudecken. Bei Bedarf Ausnahmen auf Subdomain-Ebene definieren.
Das Ziel eines MX oder anderen Dienstes ändert nichts am CAA. Die Ausstellungsentscheidung wird basierend auf dem Namen des beabsichtigten Zertifikats getroffen.
Die kritische Flagge gibt es für erweiterte Verwendungszwecke. Ein Wert von einhundertachtundzwanzig fordert die Stelle auf, das Tag zu verstehen, andernfalls verweigert sie.
Eine kurze TTL macht eine Anpassung schneller sichtbar. Praktisch bei einem Wechsel der Zertifizierungsstelle.
Eine mittlere oder lange TTL reduziert die Anfragen an die autoritativen Server. Geeignet für eine stabile Richtlinie.
TTL einige Stunden vor der Umstellung reduzieren, dann nach Validierung wieder erhöhen.
Gut zu wissen
Vererbung ist entscheidend. Eine Regel auf shop.beispiel.com ersetzt die des Apex für diese Subdomain. Ohne lokale Regel gilt die übergeordnete Regel.
Am Apex zur Definition der allgemeinen Richtlinie. Auf einer Subdomain zur Gewährung einer kontrollierten Ausnahme wie einem von Dritten verwalteten Dienst. Anschließend die tatsächliche Ausstellung bei der beabsichtigten Stelle testen.
Zu vermeiden
Das iodef vergessen, das Meldungen erleichtert.
Zu viele Stellen autorisieren, was die Kontrolle erschwert.
Ein altes CAA nach einem Anbieterwechsel aktiv lassen.
Ein Online-DNS-Lookup ermöglicht die Eingabe eines Domainnamens. Das Ergebnis zeigt die CAA-Tags und die vom Internet aus sichtbare TTL. Das ist eine nützliche erste Kontrolle. Anschließend einen lokalen Test von der eigenen Maschine durchführen.
Windows stellt nslookup zur Verfügung. Man kann es im interaktiven Modus verwenden.
nslookup
set q=caa
beispiel.com
nslookup
set q=caa
server 1.1.1.1
beispiel.com
Der erste Teil fragt entsprechend der Netzwerkkonfiguration der Maschine ab. Der zweite erzwingt die Verwendung eines Drittanbieters-Resolvers, hier den von Cloudflare.
Auf diesen Systemen ist der Befehl dig praktisch und einfach zu verwenden.
dig CAA beispiel.com
dig CAA beispiel.com @1.1.1.1
Das Vorhandensein eines Tags "issue" oder "issuewild" zeigt die autorisierte Stelle an. Ein Wert mit Semikolon allein verbietet die Ausstellung.
Eine hohe verbleibende TTL kann eine Verzögerung nach einer Änderung erklären.
Ein völliges Fehlen von CAA bedeutet keine Einschränkungen. Die Stellen können entsprechend ihren üblichen Kontrollen ausstellen.
- Die gewählte Stelle und den eventuellen Wildcard-Bedarf auflisten.
- Die CAAs am Apex mit reduzierter TTL veröffentlichen.
- iodef zu einer funktionierenden Kontaktadresse hinzufügen.
- Die Ausstellung eines Testzertifikats bei der Stelle testen.
- Die TTL erhöhen, wenn alles validiert ist.
Praktischer Tipp
Eine Liste der veröffentlichten CAAs führen. Datum, TTL und Grund der Änderung notieren. Den Nachweis erfolgreicher Ausstellungstests aufbewahren.
Ein einziges Tag "issue" veröffentlichen. Überprüfen, dass alle Dienste über diese Stelle laufen.
"issuewild" für dieselbe Stelle hinzufügen. "issue" für Nicht-Wildcard-Zertifikate behalten.
"iodef" mit einer dedizierten E-Mail oder einer https-Empfangsadresse hinzufügen.
- Wenn die Ausstellung fehlschlägt, überprüfen, dass das Tag "issue" oder "issuewild" die beabsichtigte Stelle erwähnt.
- Wenn die Stelle eine Korrektur verlangt, die Vererbung bis zum Apex überprüfen.
- Wenn die Änderung nicht berücksichtigt wird, das Ablaufen der TTL abwarten und wenn möglich den Cache des lokalen Resolvers leeren.
Zusammengefasst definiert ein CAA-Eintrag, wer Zertifikate für eine Domain ausstellen kann. Die Tags "issue", "issuewild" und "iodef" decken die Mehrzahl der Bedürfnisse ab. Die Vererbung leitet die Entscheidung. Eine angepasste TTL erleichtert den Übergang. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Anhaltspunkten bleibt die Verwaltung klar. Änderungen laufen stressfrei ab. Zertifikate werden entsprechend Ihrer Richtlinie ausgestellt.