CAA-Record-Prüfer/Generator
CAA ist eine DNS-Policy für Zertifikate; DNSSEC-Kontext hilft zu beurteilen, ob die Antwort authentifiziert ist.
DNS-SicherheitCAA-Records in der Praxis: Zertifikatsausstellung kontrollieren
Jede vertrauenswürdige CA darf für deine Domain ausstellen, bis du etwas anderes sagst. CAA ist das Werkzeug dafür — billig zu publizieren, überraschend scharf in der Wirkung, und am gefährlichsten für die, die vergessen, dass sie es publiziert haben.
Was ein CAA-Record dir wirklich kauft
Öffentlich vertrauenswürdige CAs sind verpflichtet, CAA vor der Ausstellung zu prüfen — nicht periodisch, nicht bei Renewal-Erinnerungen, sondern im Moment der Ausstellung. Ein Record wie example.com. CAA 0 issue "letsencrypt.org" verwandelt das Universum möglicher Aussteller in eine Liste, die du geschrieben hast. Eine Fehlausstellung durch eine nie autorisierte CA wird von einer stillen Möglichkeit zur detektierbaren Policy-Verletzung mit Audit-Spur — und der gutmeinende Kollege, der beim ausgemusterten Anbieter bestellt, bekommt eine saubere Ablehnung statt eines Zertifikats.
Genauso wichtig ist, was CAA nicht tut. Es wird ausschließlich bei der Ausstellung ausgewertet: Records zu publizieren oder zu ändern hat null Wirkung auf existierende Zertifikate — CAA ist also auch kein Notfall-Widerrufshebel. Und es beschränkt Ausstellung, nicht Nutzung: Ein Zertifikat von vor deiner Policy, oder unter der abweichenden Policy einer Subdomain, funktioniert bis zu seinem Ablauf. Kombiniere CAA mit Certificate-Transparency-Monitoring, wenn du sehen willst, was tatsächlich ausgestellt wurde — die beiden Kontrollen decken gegenseitig ihre blinden Seiten.
Wie CAs den Baum auswerten
Die Lookup-Semantik produziert die meisten Überraschungen der Praxis. Eine CA prüft den exakten zu zertifizierenden Namen — und klettert, wenn dort kein CAA-Set existiert, Ebene für Ebene nach oben, bis sie eines findet. Dann gilt ausschließlich dieses Set. Ein einzelner CAA-Record auf dev.example.com ersetzt also stillschweigend deine sorgfältig entworfene Apex-Policy für alles unterhalb von dev. Audits gehören deshalb auf Subdomains, nicht nur auf den Apex — der CAA-Record-Prüfer/Generator liest Live-Antworten (inklusive des generischen RFC-3597-Wire-Formats mancher Resolver) und validiert die Tag-Syntax, die du tatsächlich publiziert hast.
Drei Tags tragen die Policy. issue autorisiert eine CA für Host-Zertifikate; issuewild regelt Wildcards separat und fällt auf issue zurück, wenn es fehlt; iodef benennt eine Meldeadresse für Verstoß-Versuche. Die Leere-Aussteller-Form issue ";" bedeutet: niemand darf ausstellen — für geparkte Domains gelegentlich genau richtig, öfter aber ein Überbleibsel, das Monate später als rätselhafte Ablehnung wieder auftaucht.
Schärfere Pins: RFC 8657 für ACME
Eine CA zu benennen lässt eine breite Tür offen: Wer deren Domain-Validierung besteht, bekommt ein Zertifikat — exakt der Zug, den ein Angreifer mit temporärer DNS- oder Web-Kontrolle spielt. RFC 8657 macht die Tür schmaler. accounturi bindet die Ausstellung an ein bestimmtes ACME-Konto — Domain-Validierung allein reicht ohne deinen Account-Schlüssel nicht mehr. validationmethods beschränkt die zulässigen Challenge-Typen und schließt Methoden aus, die deine Infrastruktur nie verwendet.
Für automatisierte ACME-Landschaften ist das das stärkste günstige Upgrade — mit einem betrieblichen Vorbehalt: Die Account-URI muss der Realität folgen. Ein neu registriertes ACME-Konto bei vergessenem CAA-Pin produziert selbstverschuldete Ablehnungen, die exakt wie ein CA-Ausfall aussehen. Dokumentiere den Pin neben den Account-Credentials — und mache das Ändern des einen zur Pflichtprüfung des anderen.
Der Renewal-Fehler, der dich sonst findet
Der häufigste CAA-Vorfall ist komplett hausgemacht: Das Team wechselt den Zertifikatsanbieter, niemand aktualisiert den Record — und es passiert nichts. Eine Weile. Bestehende Zertifikate laufen weiter. Das erste Renewal über die neue CA scheitert Wochen später, taucht als Ablauf-Alarm auf und wird als CA-Problem triagiert, während die eigentliche Ursache in deiner eigenen Zone sitzt.
Prävention ist prozedural: Das Hinzufügen oder Wechseln einer CA wird ein dokumentierter Schritt, der den CAA-Record einschließt, und die Zertifikatsautomatisierung bekommt einen Pre-Renewal-Check, ob die vorgesehene CA aktuell autorisiert ist. Dekodiere im Zweifel, was tatsächlich deployed ist, mit dem SSL-Zertifikat-Decoder — und halte die Record-Liste kurz und ehrlich: Jede autorisierte CA ist Angriffsfläche für validierungsbasierte Ausstellung. Autorisiere, was ihr nutzt, und sonst nichts.