Ballot SC-085v2: Zertifizierungsstellen prüfen jetzt DNSSEC vor der Ausstellung von TLS-Zertifikaten

⚡TL;DR

• Seit dem 15. März 2026 müssen CAs bei der Domain-Validierung (DCV) DNSSEC prüfen, bevor sie ein TLS-Zertifikat ausstellen (Ballot SC-085v2)
• Wenn deine Domain DNSSEC veröffentlicht und die Vertrauenskette gebrochen ist (BOGUS), wird kein Zertifikat ausgestellt, solange das Problem besteht
• SC-085v2 ergänzt MPIC (SC-067): Zusammen schützen sie die DCV vor BGP-Hijacking und DNS-Spoofing
• SC-081v3 verkürzt auch die Laufzeit von TLS-Zertifikaten bis 2029 auf 47 Tage: lies unseren vollständigen SC-081v3-Leitfaden

Seit dem 15. März 2026 kann die Verlängerung eines TLS-Zertifikats fehlschlagen, wenn deine Domain DNSSEC mit einer ungültigen Vertrauenskette veröffentlicht. Das ist kein Bug deines Zertifikatsanbieters: Es ist die Umsetzung von Ballot SC-085v2 des CA/Browser Forums, das Zertifizierungsstellen (CAs) verpflichtet, DNSSEC-Antworten bei der Domain Control Validation zu prüfen.

Diese Änderung betrifft alle Domains, die DNSSEC veröffentlichen. Wenn deine DNS-Zone korrekt signiert ist, profitierst du von einem verstärkten Schutz gegen BGP-Hijacking und DNS-Spoofing bei der Zertifikatsausstellung. Aber wenn deine DNSSEC-Konfiguration fehlerhaft ist (veralteter DS-Record, abgelaufene Signaturen, veralteter Algorithmus), verweigert die CA die Ausstellung des Zertifikats.

Dieser Artikel erläutert das Problem, das SC-085v2 löst, die technische Funktionsweise, die Interaktion mit MPIC (SC-067), die betrieblichen Auswirkungen je nach Situation und einen Praxisleitfaden zur Überprüfung und Korrektur deiner Konfiguration vor der nächsten Verlängerung.

Das Problem: DCV basiert auf nicht authentifiziertem DNS

Die Domain Control Validation (DCV) ist der Prozess, mit dem eine CA überprüft, ob der Antragsteller eines Zertifikats tatsächlich die betreffende Domain kontrolliert. Dieser Prozess basiert auf DNS, einem Protokoll, das ohne Authentifizierung der Antworten konzipiert wurde.

So funktioniert die Domain-Validierung (DCV)

Bevor eine CA ein TLS-Zertifikat ausstellt, muss sie sicherstellen, dass du die Domain kontrollierst, für die du das Zertifikat beantragst. Drei Validierungsmethoden sind üblich:

• DNS-01: Die CA fordert dich auf, einen bestimmten TXT-Eintrag unter _acme-challenge.captaindns.com zu veröffentlichen. Anschließend fragt sie das DNS ab, um zu prüfen, ob der Eintrag vorhanden ist und den erwarteten Wert enthält. Das ist die am häufigsten verwendete Methode bei automatisierten Systemen.
• HTTP-01: Die CA fordert dich auf, eine Datei unter einer bestimmten URL auf dem Webserver der Domain abzulegen (z. B. http://captaindns.com/.well-known/acme-challenge/TOKEN). Dann prüft sie, ob die Datei erreichbar ist und den richtigen Wert enthält.
• E-Mail: Die CA sendet eine Validierungs-E-Mail an eine administrative Adresse der Domain (admin@, postmaster@ usw.) und wartet auf eine Bestätigung.

Das ACME-Protokoll (Automatic Certificate Management Environment, RFC 8555) automatisiert diesen Austausch. Es standardisiert den Dialog zwischen dem Client (certbot, acme.sh usw.) und der CA. Die Methode DNS-01 ist in automatisierten Umgebungen am weitesten verbreitet, da sie die Validierung von Wildcard-Zertifikaten ermöglicht und keinen Webserver erfordert.

In jedem Fall führt die CA DNS-Abfragen durch: um den Validierungs-TXT aufzulösen (DNS-01), um die IP-Adresse des Webservers aufzulösen (HTTP-01) oder um den MX der Domain aufzulösen (E-Mail). DNS ist also das Fundament der DCV.

DNS ohne DNSSEC ist fälschbar

Das DNS-Protokoll, 1983 entworfen, enthält keinerlei Authentifizierung der Antworten. Ein DNS-Resolver kann eine legitime Antwort nicht von einer gefälschten unterscheiden. Diese strukturelle Schwäche öffnet die Tür für mehrere Angriffsvektoren:

Cache Poisoning. Ein Angreifer schleust falsche Antworten in den Cache eines DNS-Resolvers ein. Nachfolgende Abfragen für dieselbe Domain liefern die IP-Adresse des Angreifers statt die des legitimen Servers.

BGP-Hijacking. Ein Angreifer kündigt betrügerische BGP-Routen an, um den Netzwerkverkehr auf seine eigenen Server umzuleiten. In Kombination mit einer DCV-Anfrage kann er die Validierung abfangen und ein Zertifikat für eine Domain erhalten, die er nicht kontrolliert.

Man-in-the-Middle-Angriff im Netzwerk. Ein Angreifer, der sich auf dem Netzwerkpfad zwischen der CA und dem autoritativen DNS-Server befindet, manipuliert die DNS-Antworten während der Übertragung.

Diese Angriffe sind nicht theoretisch. Mehrere schwerwiegende Vorfälle haben ihre Durchführbarkeit belegt:

• KLAYswap (Februar 2022): Angreifer leiteten den BGP-Verkehr eines koreanischen Domain-Registrars um, erlangten ein betrügerisches TLS-Zertifikat per BGP-Hijack und stahlen Kryptowährung im Wert von 2 Millionen Dollar über eine gefälschte Website.
• Celer Bridge (August 2022): Ein ähnlicher Angriff nutzte BGP-Hijacking, um den DNS-Verkehr einer DeFi-Bridge umzuleiten. Die Angreifer erlangten ein betrügerisches Zertifikat und stahlen 235.000 Dollar.
• MyEtherWallet (April 2018): Angreifer leiteten BGP-Präfixe von Amazons Route 53 um, um DNS-Anfragen auf einen betrügerischen Server umzuleiten, erlangten ein TLS-Zertifikat und fingen die Zugangsdaten der Nutzer des Krypto-Wallets ab.

Die akademische Forschung hat diese Risiken formalisiert. Die Studie "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) hat gezeigt, dass ein Angreifer betrügerische TLS-Zertifikate bei den fünf größten CAs erlangen konnte, indem er DNS-Anfragen per BGP umleitete, mit einer Erfolgsquote von über 60 % in ihren Experimenten.

Die Erkenntnis ist klar: Solange die DCV auf nicht authentifiziertem DNS basiert, bleibt die Ausstellung von TLS-Zertifikaten verwundbar.

Ballot SC-085v2: Was sich konkret ändert

Ballot SC-085v2 mit dem Titel "Require Validation of DNSSEC when Present for CAA and DCV Lookups" wurde von Clint Wilson (Apple) vorgeschlagen und von Chrome Root Program (Google), Fastly und HARICA unterstützt. Es ändert die Baseline Requirements (BR) des CA/Browser Forums, das normative Dokument, das alle öffentlich anerkannten CAs einhalten müssen.

Die Abstimmung

Die Abstimmung endete mit einer einstimmigen Annahme auf Browserseite und nahezu einstimmig auf CA-Seite:

• 25 Stimmen dafür (darunter DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
• 0 Stimmen dagegen
• 1 Enthaltung (Entrust, das technisch dafür stimmte, sich aber bei Timing-Fragen enthielt)
• Browserseite: Apple und Mozilla stimmten dafür

Was das Ballot vorschreibt

Seit dem 15. März 2026 müssen CAs eine vollständige DNSSEC-Validierung bei DNS-Abfragen durchführen, die verwendet werden für:

1. Domain Control Validation (DCV): Alle DNS-Abfragen im Zusammenhang mit der Kontrolle (TXT für DNS-01, A/AAAA für HTTP-01, MX für E-Mail)
2. CAA-Prüfungen (Certification Authority Authorization): CAA-Einträge legen fest, welche CAs Zertifikate für eine Domain ausstellen dürfen

Die DNSSEC-Validierung muss bis zum IANA-Trust-Anchor (dem Root-KSK) auf der Primary Network Perspective durchgeführt werden, also dem Hauptauflösungspunkt der CA. Die Anforderung umfasst die gesamte Kette: Vom DNS-Root bis zur Ziel-Domain muss jede RRSIG-Signatur verifiziert werden.

Was das Ballot nicht ändert

Domains ohne DNSSEC sind nicht betroffen. Wenn deine Domain keinen DS-Record beim TLD veröffentlicht, führt die CA die DCV genau wie bisher durch. SC-085v2 macht DNSSEC nicht zur Pflicht für den Erhalt eines Zertifikats. Es verpflichtet lediglich die CAs, DNSSEC zu validieren, wenn es eingesetzt wird.

Zeitplan der Einführung

Die wichtigsten CAs haben den Termin vorweggenommen:

• DigiCert: DNSSEC-Validierung aktiv seit dem 3. März 2026 mit dem Fehlercode dns_sec_validation_error für fehlgeschlagene Domains
• Sectigo: Einführung abgeschlossen am 5. März 2026
• Offizielle Frist: 15. März 2026, alle CAs müssen konform sein

Die Ausnahme für E-Mail-Validierung (SC-094v2)

Ballot SC-094v2, separat verabschiedet, gewährt eine vorübergehende Ausnahme für die DCV per E-Mail. Die E-Mail-Validierungsmethoden (BR-Abschnitte 3.2.2.4.2 und 3.2.2.4.4) werden schrittweise abgeschafft und erhalten eine zusätzliche Frist, bevor die DNSSEC-Validierung auch für sie gilt. Diese Ausnahme berücksichtigt, dass diese historischen Methoden nach und nach eingestellt werden.

Wie DNSSEC die Zertifikatsausstellung absichert

DNSSEC fügt dem DNS eine Schicht kryptografischer Authentifizierung hinzu. Jeder DNS-Eintrag wird von einer digitalen Signatur (RRSIG) begleitet, die der Resolver verifizieren kann. Das Vertrauen wird vom IANA-Trust-Anchor (dem Root-KSK) bis zur Ziel-Domain über eine Kette aus DS-Records und DNSKEY weitergegeben. Eine ausführliche Erklärung dieses Mechanismus findest du in unserem Leitfaden zur DNSSEC-Vertrauenskette.

Konkrete Anwendung bei der DCV

Nehmen wir ein konkretes Szenario. Ein automatisiertes System beantragt ein Zertifikat für captaindns.com über ACME (DNS-01). Der ACME-Client veröffentlicht einen TXT-Eintrag unter _acme-challenge.captaindns.com mit einem eindeutigen Token.

Die CA fragt das DNS ab, um diesen TXT abzurufen. Mit SC-085v2 führt der Resolver der CA jetzt eine vollständige DNSSEC-Validierung durch:

1. Er prüft, ob die Zone captaindns.com einen DS-Record beim TLD .com veröffentlicht
2. Er ruft die DNSKEY der Zone captaindns.com ab und prüft, ob der DS dem Hash des KSK entspricht
3. Er prüft, ob der RRSIG des TXT _acme-challenge.captaindns.com von einer ZSK signiert ist, deren DNSKEY wiederum vom KSK signiert ist
4. Er geht die Kette bis zum IANA-Root zurück, um jedes Glied zu validieren

Wenn alle Signaturen gültig sind, gibt der Resolver die Antwort mit dem AD-Flag (Authenticated Data) zurück. Die CA kann dann die DCV mit der Garantie durchführen, dass die DNS-Antwort nicht gefälscht wurde.

Die drei Szenarien nach SC-085v2

Szenario 1: Domain ohne DNSSEC. Deine Domain veröffentlicht keinen DS-Record beim TLD. Der Resolver der CA stellt das Fehlen von DNSSEC fest und führt die klassische DCV ohne kryptografische Validierung durch. Keine Änderung gegenüber vor SC-085v2.

Szenario 2: DNSSEC gültig (SECURE). Deine Domain veröffentlicht DNSSEC und die Vertrauenskette ist intakt. Der Resolver validiert jede Signatur, erhält das AD-Flag, und die CA führt die DCV mit der Gewissheit durch, dass die Antwort authentisch ist. Das ist das ideale Verhalten: Du profitierst von vollständigem Schutz gegen DNS-Spoofing bei der Ausstellung deines Zertifikats.

Szenario 3: DNSSEC fehlerhaft (BOGUS). Deine Domain veröffentlicht einen DS-Record beim TLD, aber die Validierung schlägt fehl. Der DS stimmt nicht mit dem DNSKEY überein, die RRSIG sind abgelaufen oder ein nicht unterstützter Algorithmus wird verwendet. Der Resolver markiert die Antwort als BOGUS und gibt einen SERVFAIL zurück. Die CA kann keine gültige DNS-Antwort erhalten und verweigert die Ausstellung des Zertifikats.

RFC 4035 Section 5 definiert den Validierungsalgorithmus, den Resolver (und damit CAs) implementieren müssen. SC-085v2-konforme CAs wenden diesen Algorithmus auf ihrer Primary Network Perspective für jede DCV- und CAA-Abfrage an.

MPIC und DNSSEC: Verteidigung in der Tiefe

SC-085v2 funktioniert nicht isoliert. Es ist Teil einer vom CA/Browser Forum initiierten Defense-in-Depth-Strategie, deren erster Baustein MPIC (Multi-Perspective Issuance Corroboration) ist.

MPIC: Schutz auf Netzwerkebene

Ballot SC-067v3, in Kraft seit März 2025, verpflichtet CAs, die DCV von mindestens zwei geografisch getrennten Netzwerkperspektiven aus zu validieren (Mindestabstand 500 km). Konkret bedeutet das: Wenn du ein Zertifikat beantragst, startet die CA die DNS-Prüfung von mehreren Points of Presence weltweit.

Das Ziel: Lokalisierte BGP-Angriffe abwehren. Wenn ein Angreifer den BGP-Verkehr in einer Region umleitet, erhalten die Netzwerkperspektiven in anderen Regionen die legitime DNS-Antwort. Die CA erkennt die Inkonsistenz und verweigert die Ausstellung des Zertifikats.

DNSSEC: Schutz auf Protokollebene

SC-085v2 fügt eine zweite Schutzschicht hinzu, diesmal auf Ebene des DNS-Protokolls selbst. DNSSEC garantiert die Authentizität der DNS-Antworten über kryptografische Signaturen. Selbst wenn der Angreifer den Netzwerkpfad kontrolliert, kann er keine gültige DNS-Antwort fälschen, ohne die privaten Schlüssel der Zone zu besitzen.

Warum beides nötig ist

MPIC und DNSSEC adressieren unterschiedliche Angriffsvektoren und ergänzen sich:

• Nur MPIC schützt nicht, wenn der autoritative DNS-Server kompromittiert ist oder der Angreifer die DNS-Caches global vergiftet hat. Alle Netzwerkperspektiven würden dieselbe falsche Antwort erhalten.
• Nur DNSSEC schützt nicht, wenn der Resolver der CA DNSSEC nicht validiert (was mit SC-085v2 bei vorhandenem DNSSEC nicht mehr möglich ist) oder wenn der Angriff auf den Netzwerkpfad abzielt, ohne die DNS-Antworten zu verändern.
• Zusammen: MPIC deckt den Netzwerkvektor ab (lokalisiertes BGP-Hijacking), DNSSEC deckt den DNS-Vektor ab (Spoofing, Cache Poisoning). Ein Angreifer müsste gleichzeitig die DNSSEC-Kette kompromittieren und den Verkehr von allen Netzwerkperspektiven der CA umleiten, um ein betrügerisches Zertifikat zu erlangen.

Betriebliche Auswirkungen: Wer ist betroffen?

Die Auswirkungen von SC-085v2 hängen direkt von deiner DNSSEC-Situation ab. Hier sind die vier typischen Profile und ihre Konsequenzen.

DNSSEC aktiv und korrekt konfiguriert

Wenn deine Domain DNSSEC mit einer intakten Vertrauenskette veröffentlicht, ändert SC-085v2 nichts an deinem Betriebsablauf. Deine Zertifikatsverlängerungen funktionieren weiterhin normal. Der einzige Unterschied: Die CA validiert jetzt kryptografisch die DNS-Antworten, was die Sicherheit der Ausstellung erhöht. Du bist gegen BGP-Hijacking und DNS-Spoofing bei der DCV geschützt.

Das ist das ideale Szenario. Deine Investition in DNSSEC zahlt sich doppelt aus: Klassischer DNS-Schutz und Schutz der Zertifikatsausstellung.

DNSSEC aktiv, aber fehlerhaft konfiguriert

Das ist das Risikoszenario. Deine Domain veröffentlicht einen DS-Record beim TLD, was Resolvern signalisiert, dass die Zone signiert ist. Aber die DNSSEC-Konfiguration ist ungültig. Häufige Ursachen:

• Veralteter DS-Record nach einer DNS-Migration. Du hast den DNS-Anbieter gewechselt, der neue Anbieter hat neue DNSSEC-Schlüssel generiert, aber der DS-Record beim Registrar zeigt noch auf die alten Schlüssel. Die Kette ist gebrochen.
• Abgelaufene RRSIG. DNSSEC-Signaturen haben eine begrenzte Lebensdauer (typischerweise 7 bis 30 Tage). Wenn der automatische Neusignierungsprozess unbemerkt fehlschlägt, laufen die RRSIG ab und die Zone wird BOGUS.
• Fehlerhafte KSK/ZSK-Rotation. Eine schlecht sequenzierte Schlüsselrotation (neuer Schlüssel veröffentlicht, bevor der DS propagiert ist, oder alter DS gelöscht, bevor der neue Schlüssel propagiert ist) unterbricht vorübergehend die Kette.
• Nicht unterstützter Algorithmus. Einige ältere Algorithmen (RSA-SHA1, DSA) sind veraltet. Wenn deine Zone einen Algorithmus verwendet, den der Resolver der CA nicht unterstützt, schlägt die Validierung fehl.

Vor SC-085v2 verursachte eine fehlerhafte DNSSEC-Konfiguration SERVFAIL bei validierenden Resolvern (1.1.1.1, 8.8.8.8, 9.9.9.9), verhinderte aber nicht die Zertifikatsausstellung, da die Resolver der CAs DNSSEC nicht systematisch validierten. Jetzt blockiert ein DNSSEC-BOGUS die DCV und das Zertifikat wird verweigert.

Kein DNSSEC eingesetzt

Wenn deine Domain keinen DS-Record beim TLD veröffentlicht, hat SC-085v2 keine unmittelbare Auswirkung. Die CA stellt das Fehlen von DNSSEC fest und führt die klassische DCV durch. Deine Verlängerungen funktionieren weiterhin genau wie zuvor.

Allerdings wird die Einführung von DNSSEC zunehmend strategisch. SC-085v2 schafft einen starken Anreiz: Domains mit gültigem DNSSEC profitieren von einer gegen Spoofing geschützten DCV. Domains ohne DNSSEC bleiben für die beschriebenen Angriffe verwundbar. Die Migration von Microsoft 365 zur Domain mx.microsoft mit automatischem DNSSEC, die Einführung von DMARCbis mit der Empfehlung von DNSSEC zum Schutz von MX-Einträgen und SC-085v2 konvergieren zu einem Ökosystem, in dem DNSSEC zum erwarteten Standard wird.

Automatisierte Zertifikate über ACME

Dieses Profil verdient besondere Aufmerksamkeit. Die Methode DNS-01 wird massiv von ACME-Systemen zur Zertifikatsvalidierung eingesetzt, insbesondere für Wildcard-Zertifikate. Wenn deine Infrastruktur die Verlängerung über certbot, acme.sh oder einen Kubernetes-Operator wie cert-manager automatisiert, ist der Ablauf vollständig nicht-interaktiv.

Das Risiko: Ein fehlerhaftes DNSSEC verursacht einen stillen Fehler. Die ACME-Verlängerung schlägt fehl, das Zertifikat läuft ab und deine Website wird per HTTPS unerreichbar. Kein menschliches Eingreifen ist im Prozess vorgesehen, um das Problem vor dem Ablauf zu erkennen.

DigiCert hat den Fehlercode dns_sec_validation_error eingeführt, um speziell einen DNSSEC-Validierungsfehler bei der DCV zu signalisieren. Wenn du diesen Fehler erhältst, liegt das Problem in deiner DNSSEC-Konfiguration, nicht in deinem Validierungseintrag.

DNSSEC-Verbreitung: Stand März 2026

Das Verständnis des aktuellen Verbreitungsgrads hilft, das Ausmaß der durch SC-085v2 eingeführten Änderung einzuschätzen.

Globale Validierung

Etwa 35 % der weltweiten DNS-Anfragen laufen über Resolver, die DNSSEC validieren. Diese Zahl spiegelt die Verbreitung auf Resolverseite wider: Die großen öffentlichen Resolver (1.1.1.1, 8.8.8.8, 9.9.9.9) validieren alle DNSSEC. Die ISP-Resolver sind heterogener, aber der Trend ist steigend.

Signierungsrate nach TLD

Die DNSSEC-Verbreitung bei Domains (zonenseitig, nicht resolverseitig) variiert erheblich je nach TLD:

• .nl (Niederlande): Etwa 60 % der Domains signiert. Weltweiter Spitzenreiter dank aktiver Förderung durch SIDN (Registry des .nl).
• Nordische TLDs (.se, .dk, .no): Über 50 % Verbreitung, getragen von proaktiven Registries.
• .com: Etwa 4 bis 5 % der Domains signiert. Das Volumen ist in absoluten Zahlen enorm, aber der Prozentsatz bleibt niedrig.
• 92 % der TLDs haben einen DS-Record in der Root-Zone, was bedeutet, dass die Signierungsinfrastruktur auf TLD-Ebene vorhanden ist.

Die Asymmetrie zwischen Infrastruktur und Verbreitung

Die DNSSEC-Validierungsinfrastruktur ist weitgehend ausgebaut. Die Resolver sind bereit. Die TLDs sind signiert. Aber die Signierung einzelner Zonen bleibt in der Minderheit. Diese Asymmetrie erklärt sich durch die wahrgenommene Komplexität der DNSSEC-Einführung und das bisherige Fehlen sichtbarer Konsequenzen für nicht signierte Domains.

SC-085v2 verändert diese Dynamik. Zum ersten Mal gibt es eine konkrete Konsequenz für das Veröffentlichen von DNSSEC mit ungültiger Konfiguration. Und es gibt einen messbaren Nutzen bei korrekter DNSSEC-Veröffentlichung: den Schutz der DCV.

Der Dominoeffekt ist absehbar. SC-085v2, kombiniert mit der Microsoft-365-Migration zu mx.microsoft mit automatischem DNSSEC und den DMARCbis-Empfehlungen, wird die DNSSEC-Verbreitung in den kommenden Quartalen beschleunigen.

Praxisleitfaden: DNSSEC-Konfiguration prüfen und korrigieren

Überprüfe vor deiner nächsten Zertifikatsverlängerung, ob deine DNSSEC-Konfiguration intakt ist. Hier sind die wesentlichen Befehle und Schritte.

Schnellprüfung mit dig

AD-Flag (Authenticated Data) prüfen:

dig +dnssec SOA captaindns.com

Suche im Abschnitt flags: nach ad. Seine Anwesenheit bedeutet, dass der Resolver die DNSSEC-Kette erfolgreich validiert hat. Sein Fehlen zeigt an, dass entweder DNSSEC nicht eingesetzt ist oder die Validierung fehlgeschlagen ist.

DS-Records beim TLD prüfen:

dig DS captaindns.com +short

Dieser Befehl gibt die beim Registrar veröffentlichten DS-Records zurück. Wenn die Antwort leer ist, veröffentlicht deine Domain kein DNSSEC. Wenn DS-Records vorhanden sind, prüfe, ob sie mit den aktuellen Schlüsseln deiner Zone übereinstimmen.

DNSKEY-Schlüssel prüfen:

dig DNSKEY captaindns.com +short

Du solltest mindestens zwei Schlüssel sehen: einen mit Flag 256 (ZSK) und einen mit Flag 257 (KSK). Der Hash des KSK (Flag 257) muss mit dem beim TLD veröffentlichten DS-Record übereinstimmen.

DNSSEC-Problem von anderem DNS-Problem unterscheiden:

dig captaindns.com +cd

Das Flag +cd (Checking Disabled) deaktiviert die DNSSEC-Validierung. Wenn die Abfrage mit +cd funktioniert, aber ohne (SERVFAIL) fehlschlägt, liegt das Problem bei DNSSEC.

Was tun, wenn DNSSEC fehlerhaft ist

Wenn deine Prüfungen ein Problem aufdecken, hier die Korrekturmaßnahmen nach Priorität:

DS-Record beim Registrar prüfen. Melde dich bei deinem Registrar an und vergleiche den veröffentlichten DS-Record mit dem DNSKEY (Flag 257) deiner Zone. Wenn du den DNS-Anbieter gewechselt hast, muss der DS auf den KSK des neuen Anbieters zeigen.

RRSIG in der Zone prüfen. Signaturen haben ein Ablaufdatum. Wenn dein DNS-Anbieter ein Problem mit der Neusignierung hat, können die RRSIG abgelaufen sein. Kontaktiere deinen DNS-Anbieter oder prüfe die Signierungslogs, wenn du DNSSEC intern verwaltest.

Algorithmus prüfen. Die Algorithmen RSA-SHA1 und DSA sind veraltet. Bevorzuge ECDSAP256SHA256 (Algorithmus 13) oder ECDSAP384SHA384 (Algorithmus 14).

Für eine detaillierte Diagnose von SERVFAIL-Fehlern im Zusammenhang mit DNSSEC siehe unseren Leitfaden: SERVFAIL nach DNSSEC beheben. Wenn du DNSSEC zum ersten Mal aktivieren möchtest, folge unserer Schritt-für-Schritt-Anleitung zur DNSSEC-Aktivierung.

Checkliste vor der Zertifikatsverlängerung

Vor jeder Zertifikatsverlängerung bei einer Domain mit DNSSEC:

• Der DS-Record beim Registrar stimmt mit dem aktiven KSK der Zone überein
• Die RRSIG sind nicht abgelaufen (Inception und Expiration mit dig +dnssec prüfen)
• Der verwendete Algorithmus wird unterstützt (ECDSAP256SHA256 empfohlen)
• Der Resolver gibt das AD-Flag für deine Domain zurück
• Das DNSSEC-Monitoring ist eingerichtet und sendet Alarme bei Kettenbrüchen
• Ein ACME-Dry-Run wurde erfolgreich auf der betreffenden Domain ausgeführt

SC-081 und die Beschleunigung der Verlängerungen

Ballot SC-081, vom CA/Browser Forum verabschiedet, reduziert schrittweise die maximale Laufzeit von TLS-Zertifikaten:

Inkrafttreten	Maximale Laufzeit
März 2026	200 Tage
März 2027	100 Tage
März 2029	47 Tage

Diese Reduzierung hat direkte Auswirkungen auf die Kritikalität von SC-085v2. Je kürzer die Zertifikatslaufzeit, desto häufiger die Verlängerungen. Und je häufiger die Verlängerungen, desto schneller wird ein fehlerhaftes DNSSEC erkannt, aber auch desto blockierender ist es.

Bei 200-Tage-Zertifikaten verzögert ein einwöchiges DNSSEC-Problem eine Verlängerung. Bei 47-Tage-Zertifikaten kann ein DNSSEC-Problem von wenigen Tagen dazu führen, dass das Zertifikat abläuft, bevor die Verlängerung gelingt. Die Fehlertoleranz schrumpft drastisch.

Bei 47 Tagen wird ACME-Automatisierung unverzichtbar. Keine Organisation kann Verlängerungen alle sechs Wochen manuell über einen Domain-Bestand hinweg verwalten. Und eine automatisierte ACME-Pipeline, die stillschweigend wegen fehlerhaftem DNSSEC fehlschlägt, ist ein schwerwiegendes Störfallszenario.

Die Empfehlung ist klar: Richte ein kontinuierliches DNSSEC-Monitoring für alle deine Domains mit TLS-Zertifikaten ein. Konfiguriere Alarme für den Ablauf der RRSIG (mindestens 7 Tage vor Ablauf) und für die DS/DNSKEY-Übereinstimmung. Integriere die DNSSEC-Prüfung in deine ACME-Verlängerungspipeline, vor der Zertifikatsanfrage.

Aktionsplan: Deine Infrastruktur vorbereiten

1. DNSSEC-Status prüfen aller deiner Domains mit dem DNSSEC Checker von CaptainDNS
2. Fehlerhafte Ketten korrigieren: Fehlender DS-Record, abgelaufene Signatur, inkompatibler Algorithmus
3. Aktive Zertifikate auditieren: Domains mit DNSSEC und Zertifikaten auflisten, die in den nächsten 90 Tagen verlängert werden
4. Monitoring konfigurieren: Alarme für RRSIG-Ablauf und Zertifikatsablauf
5. Verlängerung testen: ACME-Dry-Run auf den DNSSEC-Domains ausführen
6. Dokumentieren: DNSSEC-Prüfung in dein Verlängerungs-Runbook aufnehmen

FAQ

Macht Ballot SC-085v2 DNSSEC zur Pflicht für TLS-Zertifikate?

Nein. SC-085v2 verpflichtet CAs zur DNSSEC-Validierung, wenn DNSSEC vorhanden ist, macht DNSSEC aber nicht zur Pflicht. Wenn deine Domain keinen DS-Record beim TLD veröffentlicht, führt die CA die klassische DCV ohne DNSSEC-Validierung durch. Du kannst weiterhin ein TLS-Zertifikat ohne DNSSEC erhalten, genau wie zuvor.

Was passiert, wenn mein DNSSEC bei der automatischen Verlängerung fehlerhaft ist?

Die Verlängerung schlägt fehl. Die CA gibt einen Fehler vom Typ dns_sec_validation_error (bei DigiCert) oder einen SERVFAIL zurück. Der ACME-Client kann die DNS-01-Validierung nicht abschließen und das Zertifikat wird nicht verlängert. Wenn das Problem bis zum Ablauf des aktuellen Zertifikats bestehen bleibt, wird deine Website per HTTPS unerreichbar. Deshalb ist ein DNSSEC-Monitoring mit Alarmen unverzichtbar.

Welche CAs sind von SC-085v2 betroffen?

Alle öffentlich anerkannten CAs (also solche, deren Root-Zertifikat in den Vertrauensspeichern der Browser enthalten ist). Dazu gehören DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign und alle anderen CAs, die die Baseline Requirements des CA/Browser Forums einhalten. Private CAs (organisationsintern) sind nicht betroffen.

Hat Let's Encrypt DNSSEC bereits vorher validiert?

Let's Encrypt verwendete bereits DNSSEC-validierende Resolver (Unbound) in seiner Infrastruktur. In der Praxis konnte eine Domain mit DNSSEC-BOGUS schon bei Let's Encrypt die Validierung nicht bestehen. SC-085v2 formalisiert diese Anforderung in den Baseline Requirements und weitet sie auf alle CAs aus, nicht nur auf diejenigen, die freiwillig DNSSEC validierten.

Was ist der Unterschied zwischen MPIC (SC-067) und SC-085v2?

MPIC (SC-067) schützt die DCV auf Netzwerkebene durch Prüfung von mehreren geografischen Standorten aus. Es erkennt lokalisierte BGP-Angriffe. SC-085v2 schützt die DCV auf DNS-Ebene durch Prüfung der DNSSEC-Signaturen. Es erkennt gefälschte DNS-Antworten. Beide sind komplementär: MPIC deckt den BGP-Vektor ab, DNSSEC deckt den DNS-Vektor ab.

Wird mein aktuelles Zertifikat widerrufen, wenn DNSSEC nach der Ausstellung fehlschlägt?

Nein. SC-085v2 betrifft ausschließlich die Validierung zum Zeitpunkt der Ausstellung. Ein bereits ausgestelltes Zertifikat bleibt bis zu seinem Ablauf gültig, auch wenn DNSSEC nach der Ausstellung fehlschlägt. Allerdings wird die nächste Verlängerung fehlschlagen, solange DNSSEC BOGUS ist.

Wie finde ich heraus, ob meine Domain DNSSEC veröffentlicht?

Führe dig DS captaindns.com +short aus (ersetze durch deine Domain). Wenn der Befehl einen oder mehrere DS-Einträge zurückgibt, veröffentlicht deine Domain DNSSEC. Wenn die Antwort leer ist, ist DNSSEC nicht aktiviert. Du kannst auch den DNSSEC Checker von CaptainDNS für eine vollständige Diagnose inklusive Validierung der Vertrauenskette nutzen.

Betrifft SC-085v2 Wildcard-Zertifikate?

Ja. Wildcard-Zertifikate werden über DNS-01 validiert (die einzige ACME-Methode, die Wildcards unterstützt). Die CA fragt das DNS ab, um den TXT _acme-challenge zu prüfen, und wendet die DNSSEC-Validierung auf diese Abfrage an. Wenn DNSSEC für deine Domain BOGUS ist, wird das Wildcard-Zertifikat nicht ausgestellt.

Was hat Ballot SC-081 mit der Reduzierung der Zertifikatslaufzeit zu tun?

SC-081 reduziert die maximale Laufzeit von TLS-Zertifikaten (200 Tage 2026, 100 Tage 2027, 47 Tage 2029). Kürzere Zertifikate bedeuten häufigere Verlängerungen. Jede Verlängerung löst eine DCV aus, und jede DCV umfasst jetzt die DNSSEC-Validierung (SC-085v2). Ein fehlerhaftes DNSSEC blockiert also häufiger die Verlängerung, mit weniger Spielraum vor dem Ablauf.

Muss ich DNSSEC aktivieren, um vom SC-085v2-Schutz zu profitieren?

Ja. SC-085v2 schützt ausschließlich Domains, die DNSSEC veröffentlichen. Ohne DNSSEC kann die CA die Authentizität der DNS-Antworten nicht prüfen und die DCV bleibt für Spoofing verwundbar. DNSSEC auf deiner Domain zu aktivieren ist der einzige Weg, um von diesem verstärkten Schutz bei der Zertifikatsausstellung zu profitieren.

Glossar

• CA (Certificate Authority): Zertifizierungsstelle, die zur Ausstellung von TLS-Zertifikaten berechtigt ist. Öffentliche CAs sind in den Vertrauensspeichern der Browser enthalten und unterliegen den Baseline Requirements des CA/Browser Forums.
• DCV (Domain Control Validation): Prozess, mit dem eine CA überprüft, ob der Antragsteller eines Zertifikats tatsächlich die Domain kontrolliert. Gängige Methoden: DNS-01, HTTP-01, E-Mail.
• CA/Browser Forum: Konsortium aus CAs und Browser-Herstellern. Es definiert die Baseline Requirements, den normativen Rahmen, den alle öffentlichen CAs einhalten müssen.
• MPIC (Multi-Perspective Issuance Corroboration): Durch Ballot SC-067 vorgeschriebener Mechanismus, der CAs verpflichtet, die DCV von mindestens zwei geografisch entfernten Netzwerkperspektiven aus zu validieren, um BGP-Hijacking zu unterbinden.
• BOGUS: Interner Status des DNSSEC-Resolvers, wenn die kryptografische Validierung fehlschlägt. Eine BOGUS-Domain verursacht einen SERVFAIL für den Client. Nach SC-085v2 blockiert eine BOGUS-Domain auch die Zertifikatsausstellung.
• ACME (Automatic Certificate Management Environment): Standardisiertes Protokoll (RFC 8555) zur Automatisierung der Ausstellung und Verlängerung von TLS-Zertifikaten. Verwendet von Let's Encrypt, certbot, acme.sh und cert-manager.
• Baseline Requirements (BR): Normatives Dokument des CA/Browser Forums, das die Mindestanforderungen für die Ausstellung von TLS-Zertifikaten durch öffentliche CAs definiert. SC-085v2 ändert die BR zur Durchsetzung der DNSSEC-Validierung.

Quellen

1. Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
2. Ballot SC-067v3: Require Multi-Perspective Issuance Corroboration (CA/Browser Forum)
3. DigiCert: Validating DNSSEC for Domain Control and CAA Checks
4. RFC 4035: Protocol Modifications for DNS Security Extensions (IETF)
5. DNSSEC Deployment Statistics (APNIC)