← Frankys Web GitHub Kontakt

CAA Check

CAA-Records einer Domain prüfen: welche Zertifizierungsstellen ausstellen dürfen.

Ein CAA-Record (Certification Authority Authorization) legt fest, welche Zertifizierungsstellen für eine Domain überhaupt Zertifikate ausstellen dürfen. Eine CA muss die CAA-Records vor jeder Ausstellung abfragen und darf ablehnen, wenn sie sich dort nicht wiederfindet, egal wer die Anfrage stellt. CAA ist damit eine einfache, wirksame Bremse gegen die Fehlausstellung von Zertifikaten für die eigene Domain.

Was dieses Werkzeug prüft

CAA wird die Namenskette aufwärts vererbt. Das Werkzeug klettert von der eingegebenen Domain aus nach oben, bis es eine Ebene mit CAA-Records findet oder die registrierbare Domain erreicht (höher zu klettern wäre bedeutungslos). Es wertet die Tags aus: issue (normale Zertifikate), issuewild (Wildcard-Zertifikate) und iodef (Kontakt für Meldungen) nach RFC 8659, dazu issuemail (S/MIME-Zertifikate auf E-Mail-Adressen der Domain) nach RFC 9495. Ein Wert von genau ; ist jeweils ein vollständiges Ausstellungsverbot für diese Art. Das kritische Flag unbekannter Tags wird erkannt. Der tatsächliche Aussteller eines laufenden Zertifikats wird bewusst nicht gegengeprüft, dafür gibt es den Zertifikat Check.

Das Ergebnis lesen

Kein CAA-Record irgendwo in der Kette bedeutet: jede öffentliche CA darf ausstellen. Das ist der Standardzustand der meisten Domains und wird als Info gezeigt, nicht als Fehler. Sind Records vorhanden, werden issue und issuewild getrennt aufgelistet; fehlt issuewild, gilt issue auch für Wildcards. Ein explizites Verbot (;) und ein unbekannter Tag mit gesetztem kritischen Flag erscheinen als Warnung, ein fehlender iodef-Kontakt nur als Hinweis.

Eine Zeile verdient besondere Beachtung: fehlt issuemail, darf jede CA S/MIME-Zertifikate auf E-Mail-Adressen dieser Domain ausstellen -- auch dann, wenn issue sauber auf eine einzige CA eingeschränkt ist. Das ist kein Versehen im Standard, sondern ausdrücklich so festgelegt (RFC 9495 §4). Weil ein gut gepflegter issue-Record den Eindruck erweckt, die Domain sei vollständig abgedeckt, steht dieser Hinweis unter jedem Ergebnis ohne issuemail. Er ist bewusst nur ein Hinweis: die meisten Domains brauchen keine S/MIME-Einschränkung, und eine Warnung stünde sonst fast überall.

Grundlagen

CAA ist in RFC 8659 definiert (Record-Format, Vererbung über die Namenskette, Verhalten bei fehlendem issuewild in §4.2, kritisches Flag in §4.1). RFC 8657 ergänzt Parameter zur Bindung an ein bestimmtes CA-Konto (accounturi) und an eine Validierungsmethode (validationmethods). Der ältere RFC 6844 ist abgelöst; seither wird CAA am konkreten Namen und dann aufwärts geprüft, nicht mehr entlang von CNAME-Ketten und DNAMEs im alten Verfahren. RFC 9495 kam 2023 hinzu und führte issuemail ein. Vorher gab es für S/MIME gar keine CAA-Steuerung: manche CAs zogen behelfsweise issue heran, verbindlich war das nie. Seit RFC 9495 ist die Lage eindeutig, und zwar in die andere Richtung -- issue gilt für S/MIME ausdrücklich nicht.

Typische Fehlerbilder und wie man sie behebt

  • Zertifikatsantrag scheitert mit CAA-Fehler. Der im CAA-Record hinterlegte CA-Bezeichner passt nicht zu dem, was die gewählte CA erwartet (zum Beispiel letsencrypt.org statt 0 issue "letsencrypt.org"). Den exakt von der CA dokumentierten Wert eintragen.
  • Wildcard-Zertifikat wird abgelehnt, normales geht. Es fehlt ein issuewild-Eintrag für die CA, oder issuewild nennt eine andere CA. Einen passenden issuewild-Record ergänzen.
  • S/MIME-Zertifikat wird trotz strenger CAA ausgestellt. Kein Fehler, sondern die Regel: issue und issuewild gelten für S/MIME ausdrücklich nicht (RFC 9495 §4). Wer das steuern will, braucht einen eigenen issuemail-Eintrag; ein 0 issuemail ";" verbietet S/MIME vollständig.
  • CAA am Zonen-Apex, aber Zertifikat für eine Subdomain klemmt. Ein CAA-Record direkt an der Subdomain überschreibt den der Elternebene vollständig, er wird nicht ergänzt. Enthält der Subdomain-Record dann nicht die benötigte CA, schlägt die Ausstellung fehl.
  • Ungewolltes Totalverbot. Ein issue ";" sperrt jede Ausstellung. Wenn das nicht beabsichtigt ist, den Wert durch die erlaubte CA ersetzen.
  • Alte oder überflüssige CA im Record. Nach einem CA-Wechsel den alten issue-Eintrag entfernen, sonst könnte die frühere CA weiterhin ausstellen.

Häufige Fragen

Was passiert ohne CAA-Record?
Fehlt CAA in der gesamten Kette, darf jede öffentliche Zertifizierungsstelle für die Domain ausstellen, und zwar für alle Arten: normale Zertifikate, Wildcards und S/MIME-Zertifikate auf E-Mail-Adressen der Domain. Das ist der Standardzustand der meisten Domains und kein Fehler.
Schützt mein issue-Record auch vor S/MIME-Zertifikaten?
Nein, und das ist der häufigste Irrtum bei CAA. issue und issuewild gelten nur für Zertifikate auf Domainnamen. Für S/MIME-Zertifikate, die auf eine E-Mail-Adresse deiner Domain ausgestellt werden, gibt es seit RFC 9495 einen eigenen Tag: issuemail. Fehlt er, darf jede Zertifizierungsstelle solche Zertifikate ausstellen, egal wie streng issue gesetzt ist. Wer das einschränken will, setzt 0 issuemail "ca.example" für die erlaubte Stelle oder 0 issuemail ";" als vollständiges Verbot. Für die meisten Domains ist das kein dringendes Thema, aber man sollte es entschieden haben und nicht übersehen.
Wie erstelle ich einen CAA-Record?
Am Zonen-Apex einen Record der Form 0 issue "letsencrypt.org" setzen, den exakten CA-Bezeichner aus der Dokumentation der gewünschten CA übernehmen. Für Wildcards zusätzlich 0 issuewild "...". Mehrere CAs bekommen je einen eigenen issue-Eintrag. Optional 0 iodef "mailto:security@example.com".
Mein Zertifikatsantrag scheitert an CAA, was tun?
Prüfen, ob der im CAA-Record hinterlegte CA-Bezeichner exakt dem entspricht, was die CA verlangt, und ob ein Record an der konkreten Subdomain den der Elternebene überschreibt. Bei Wildcards muss issuewild passen, nicht nur issue.
Was bedeutet ein issue-Wert von genau ';'?
Ein Wert von exakt ';' verbietet jeder Zertifizierungsstelle die Ausstellung, auch wenn die Domain selbst gerade kein Zertifikat braucht. Nützlich für Domains, die nie ein Zertifikat haben sollen.
Was ist der Unterschied zwischen issue und issuewild?
issue gilt für normale Zertifikate, issuewild speziell für Wildcard-Zertifikate wie *.example.com. Fehlt issuewild, gilt issue automatisch auch für Wildcards (RFC 8659 §4.2).
Wozu dient iodef?
iodef nennt eine Mail- oder Web-Adresse, an die Zertifizierungsstellen unautorisierte Ausstellungsversuche melden können. Optional; ein fehlender Eintrag ist nur ein Hinweis, kein Fehler.