Globaler CAA-Record Checker
Der CAA-Record (Certification Authority Authorization) ist eine kritische Sicherheitserweiterung, die in RFC 6844 eingeführt wurde, um die Public Key Infrastructure (PKI) abzusichern. Ein CAA-Record erlaubt es Domain-Administratoren, explizit zu definieren, exakt welche Certificate Authorities (Zertifizierungsstellen wie Let's Encrypt, DigiCert oder Sectigo) rechtlich befugt sind, SSL/TLS-Zertifikate für ihre Infrastruktur auszustellen. Er fungiert als aggressive Perimeter-Verteidigung gegen bösartige oder kompromittierte Zertifizierungsstellen, die betrügerische, vertrauenswürdige Zertifikate für Man-in-the-Middle-Angriffe generieren könnten.
Obligatorische Checks vor der Ausstellung
Seit 2017 schreibt das CA/Browser Forum vor, dass jede kommerzielle CA einen DNS-Lookup nach CAA-Records durchführen muss, bevor sie ein Zertifikat ausstellt. Wenn ein automatisierter ACME-Client oder ein Administrator ein Zertifikat anfordert, fragt die CA die Zone ab. Existiert kein CAA-Record, geht die CA von einer impliziten Erlaubnis aus und stellt das Zertifikat aus. Ist jedoch ein CAA-Record vorhanden und der Hostname der anfragenden CA (z. B. letsencrypt.org) nicht explizit im Payload gelistet, wird der Ausstellungsprozess hart blockiert und sofort auf CA-Ebene abgebrochen.
Tree-Climbing und Geltungsbereich
Ein mächtiger Aspekt der CAA-Architektur ist ihre "Tree-Climbing"-Parsing-Logik. Fordert ein Administrator ein Zertifikat für eine tief verschachtelte Subdomain an (z. B. api.staging.example.com), fragt die Certificate Authority diesen exakten Node nach einem CAA-Record ab. Findet sie keinen, parst sie nach oben und prüft staging.example.com und schließlich den Apex example.com. Das bedeutet, dass ein einzelner, auf der Root-Domain deployter CAA-Record als übergreifende Sicherheitsrichtlinie fungiert, die automatisch nach unten kaskadiert und jede darunterliegende Subdomain vor unbefugter Ausstellung schützt.
Debugging von automatisierten Erneuerungsfehlern
Während CAA-Records die Sicherheit drastisch verbessern, sind sie die Hauptursache für plötzliche, stille SSL-Fehler in modernen DevOps-Pipelines. Wenn ein Unternehmen von einem manuellen Wildcard-Zertifikat (ausgestellt von DigiCert) auf automatisierte Let's Encrypt-Erneuerungen via Kubernetes cert-manager umsteigt, aber vergisst, seine restriktiven CAA-Records zu aktualisieren, wird der Erneuerungs-Bot fehlschlagen. Die CA gibt einen Autorisierungsfehler zurück, das Live-Zertifikat läuft schließlich ab und löst Browser-Warnungen für alle Endbenutzer aus. Zusätzlich können Administratoren ein iodef-Tag innerhalb des CAA-Payloads konfigurieren, das die CA anweist, eine automatisierte E-Mail oder einen Webhook-Alert an das Security-Team zu senden, wann immer ein blockierter Ausstellungsversuch auftritt.