domainsecuritycheck

← Record Studio

CAA

CAA-Records (RFC 8659) legen fest, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen. Eine regelkonforme CA muss CAA vor jeder Ausstellung prüfen (RFC 8659 §3) — eine enge Positivliste senkt das Risiko von Fehlausstellungen deutlich. Eine harte Sperre ist es nicht: CAA wirkt nur so weit, wie Aussteller sich daran halten (RFC 8659 §5), und nach einer CAA-Prüfung darf eine CA noch innerhalb der TTL des Records oder 8 Stunden ausstellen, je nachdem, was länger ist (CA/Browser-Forum-BR §4.2.2.1) — eine verschärfte Policy wirkt also nicht sofort. Beobachten Sie zusätzlich die Certificate-Transparency-Logs.

Ausstellung an ein bestimmtes ACME-Konto oder Validierungsverfahren binden? Nutzen Sie die Felder ACME-Bindung (RFC 8657) unten, um accounturi= und validationmethods= an Ihre issue/issuewild-Regeln anzuhängen – z. B. 0 issue "letsencrypt.org; validationmethods=dns-01". Bis zum 15. März 2027 ist die Verarbeitung dieser Parameter in den CA/Browser-Forum-Baseline-Requirements ein SHOULD (§4.2.2.1.2), und RFC 8657 §5.2 sagt, man dürfe die Unterstützung ohne ausdrückliche Angabe der CA nicht voraussetzen; ab dem 15. März 2027 müssen alle öffentlich vertrauenswürdigen TLS-CAs sie verarbeiten.

CAs suchen CAA, indem sie vom Zertifikatsnamen aus im DNS-Baum nach oben klettern, und bleiben beim ERSTEN Namen stehen, der überhaupt ein CAA-RRset trägt (RFC 8659 §3). Ein Eintrag auf der registrierbaren Domain (example.com) deckt deshalb auch www und jede andere Subdomain mit ab, die keinen eigenen Satz veröffentlicht. Ein CAA-RRset auf einer Subdomain ERSETZT den Satz der übergeordneten Domain für diesen Namen — zusammengeführt wird nie; wiederholen Sie dort also jede Regel, die weiter gelten soll, iodef- und Kontakt-Properties eingeschlossen. Achtung: Ein Satz, der die Suche stoppt, aber keine issue-/issuewild-Regel enthält — etwa nur contactemail oder iodef —, lässt die Ausstellung für diesen Namen unbeschränkt (RFC 8659 §3). Und wo das DNS einer Subdomain an Dritte delegiert ist, kann CAA nicht beschränken, was diese dort veröffentlichen (RFC 8657 §5.7).

Eine E-Mail-Adresse wird zu einer mailto:-URL.

Veröffentlicht einen Domain-Kontakt für CAs. Sein einziger spezifizierter Zweck, die Domain-Kontakt-Validierung (CA/Browser-Forum-BR §3.2.2.4.13), läuft aus: seit dem 15.03.2026 SHOULD NOT, ab dem 15.03.2028 MUST NOT. Für Fehlausstellungs-Meldungen nutzen Sie das Feld iodef oben. Nur die reine Adresse angeben — kein mailto: (anders als bei iodef).

Ein Telefon-Kontakt, den CAs nachschlagen können. Sein einziger spezifizierter Zweck, die telefonbasierte Domain-Validierung (CA/Browser-Forum-BR §3.2.2.4.17), läuft aus: seit dem 15.03.2026 SHOULD NOT, ab dem 15.03.2027 dürfen CAs sich nicht mehr darauf stützen. Für Fehlausstellungs-Meldungen nutzen Sie das Feld iodef oben. Im internationalen Format mit führendem + und Ländervorwahl angeben — eine Global Number nach BR Appendix A.1.2; dieses Formular entfernt die Leerzeichen (erlaubt wären sie) und setzt kein tel:-Präfix.

Erlaubte Zertifizierungsstellen

Pro CA ankreuzen, welche Ausstellungstypen sie durchführen darf. Über das Suchfeld lässt sich die Liste nach CA-Name oder Domain filtern. issue autorisiert TLS-/sonstige Zertifikate — inklusive Wildcards, sofern nicht zusätzlich eine issuewild-Regel gesetzt ist, die dann die Wildcards regelt (RFC 8659 §4.3). issuemail ist separat: es regelt S/MIME-(E-Mail-)Zertifikate (RFC 9495) und wird von issue/issuewild nicht abgedeckt. Um Wildcards ganz zu verbieten, unten „Wildcard-Ausstellung verbieten“ nutzen. Die flag-Spalte setzt das Flag für alle Records dieser CA zugleich: 0 (normal) oder 128 (kritisch). Kritisch heißt: Eine CA, die dieses Property Tag nicht kennt oder nicht unterstützt, muss JEDE Ausstellung für den Namen ablehnen (RFC 8659 §4.1) — und das wirkt in beide Richtungen: 128 auf issuemail kann bei einer reinen TLS-CA Ihre TLS-Zertifikate blockieren, 128 auf issue bei einer reinen S/MIME-CA Ihre S/MIME-Zertifikate (RFC 9495 §6). Öffentlich vertrauenswürdige TLS-CAs müssen issue/issuewild/iodef ohnehin verarbeiten (CA/Browser-Forum-BR §4.2.2.1). Bei 0 belassen.

Kommagetrennte CAA-Bezeichner weiterer CAs, die TLS-/sonstige Zertifikate ausstellen dürfen.

Weitere CAs, die Wildcard-Zertifikate ausstellen dürfen. Sobald eine issuewild-Regel existiert, regelt sie die Wildcards; sonst die issue-Regeln.

Weitere CAs, die S/MIME-(E-Mail-)Zertifikate ausstellen dürfen (RFC 9495).

ACME-Bindung (RFC 8657) — optional

Bindet die Ausstellung an ein bestimmtes ACME-Konto und/oder Validierungsverfahren. Diese Parameter werden an die issue/issuewild-Regeln oben angehängt (nicht an issuemail). Bis zum 15. März 2027 ist ihre Verarbeitung ein SHOULD (CA/Browser-Forum-Baseline-Requirements §4.2.2.1.2), und RFC 8657 §5.2 sagt, man dürfe die Unterstützung ohne ausdrückliche Angabe der CA nicht voraussetzen; ab dem 15. März 2027 müssen alle öffentlich vertrauenswürdigen TLS-CAs sie verarbeiten.

Die Konto-URL, auf die die Ausstellung festgelegt wird — sie muss IHR Konto bei der oben ausgewählten CA sein. Eine Property, deren accounturi diese CA nicht kennt, etwa ein Konto bei einer anderen CA, ist unerfüllbar: Die CA muss die Ausstellung dann ablehnen, Erneuerungen eingeschlossen (RFC 8657 §3, §5.8). Nur sinnvoll, wenn Sie genau eine CA erlauben — aus dem ACME-Client bzw. Dashboard genau dieser CA kopieren. CAs ohne ACME-Konto-URLs definieren ein eigenes accounturi-Format (CA/Browser-Forum-BR §4.2.2.1.2); dann gilt, was diese CA dokumentiert.

Kreuzen Sie die Validierungsverfahren an, die eine CA nutzen darf (validationmethods) — es sind die drei ACME-Challenge-Labels. Achtung: Sobald ein Häkchen gesetzt ist, sind ALLE nicht angekreuzten Verfahren verboten. Ein Verfahren, das zusätzlich ein ACME-Label hat, bleibt auch außerhalb von ACME abgedeckt — die CA SOLL jedes Label akzeptieren, das es abbildet (CA/Browser-Forum-BR §4.2.2.1.2). Verfahren ohne ACME-Entsprechung, etwa die E-Mail- und Telefon-Verfahren, tragen dagegen nur ca-tbr-<n>-Labels, die dieses Formular nicht erzeugen kann; wer so validiert, lässt alle Häkchen leer. Alle leer = jedes Verfahren erlaubt.

Signed HTTP Exchanges (SXG) — erweitert

Autorisiert SXG-Signaturzertifikate — Zertifikate mit der CanSignHttpExchanges-Extension, mit denen sich Signed HTTP Exchanges signieren lassen, z. B. vorab ladbare Inhalte unter Ihrer Origin-URL. Eine regelkonforme CA darf ein solches Zertifikat nur ausstellen, wenn dieser Parameter an ihrer eigenen issue/issuewild-Regel steht (draft-yasskin-http-origin-signed-responses §4.2). Der Parameter ist nicht CA-spezifisch: Google Trust Services (pki.goog) und DigiCert (digicert.com) verlangen ihn beide, und dieses Formular hängt ihn an die Regeln dieser CAs an. Nur in abgelaufenen IETF-Drafts (draft-yasskin-*) definiert, nie als RFC standardisiert und nur unter Chromium — lassen Sie es aus, sofern Sie nicht wirklich Signed Exchanges ausliefern.

Records werden in Ihrem Browser erzeugt; „Aktuellen Record laden“ lässt unseren Server das DNS Ihrer Domain abfragen. Record Studio · Ergebnis mit dem Domain-Sicherheitscheck prüfen