CAA-Record prüfen
CAA-Records einer Domain prüfen: erlaubte CAs, Wildcard-Policies, iodef-Adressen und Inheritance nach RFC 8659.
Methodik & Funktionsweise
Was wird geprüft?
Prüft die Certificate Authority Authorization (RFC 8659) einer Domain: welche CAs dürfen Zertifikate ausstellen?
Wie funktioniert es?
CAA-Lookup mit Inheritance: gibt es am angefragten Hostname keinen Record, wird der Parent gesucht (api.example.com → example.com → root). Parst issue, issuewild, iodef, contactemail, contactphone. Kritisch: unbekannte Tags mit critical-Flag (= CA muss ablehnen). Meldet: kein CAA (jede CA darf), niemand-Mode (keine CA darf), fehlendes iodef.
Beispiel-Ergebnis
google.com → issue "pki.goog" (nur Google Trust Services darf, 0 Issues)
Hinweise
CAA verhindert Mis-Issuance durch kompromittierte oder versehentlich verwendete CAs. Let's Encrypt prüft CAA vor jeder Ausstellung — falscher Record blockiert Renewal.
Was sind CAA-Records?
CAA-Records (RFC 8659) legen fest, welche CAs Zertifikate für eine Domain ausstellen dürfen. Ohne CAA darf jede der ca. 300 öffentlich vertrauenswürdigen CAs Zertifikate ausstellen. Der Checker prüft CAA mit Inheritance bis zur TLD, parst issue, issuewild, iodef. Häufige Befunde: kein CAA gesetzt, niemand-Mode (blockt Renewal), fehlende iodef-Adresse.
CAA pragmatisch konfigurieren
- 1Mindestens 0 issue letsencrypt.org hinterlegen.
- 2iodef-Adresse für Mis-Issuance-Reports einrichten.
- 3Bei Provider-Wechsel TTL niedrig halten.
- 4CAA-Inheritance nutzen: ein Record auf dem Apex reicht meistens.