Automatisierte DNS-Validierung mit CertSecure Manager: Persistente DCV und DNS-Konnektoren

Ein Zertifikat, das früher jährlich erneuert werden musste, muss nun etwa alle fünf bis sechs Wochen neu validiert werden. Bis März 2029 verkürzt sich dieser Rhythmus auf alle 47 Tage. Persistente DCV (DNS-PERSIST-01) und DNS-Konnektoren sind die beiden Mechanismen, die eine zeitnahe Domainvalidierung ermöglichen: Persistente DCV erlaubt die erneute Verifizierung einer Domain anhand eines einmalig veröffentlichten DNS-TXT-Eintrags. DNS-Konnektoren automatisieren die verbleibenden DNS-Änderungen, sodass Zertifizierungsteams die immer kürzeren Gültigkeitsdauern gemäß CA/Browser Forum einhalten können, ohne bei jeder Erneuerung manuelle DNS-Arbeiten durchführen zu müssen.

Dieser Leitfaden beschreibt die Funktion jeder einzelnen Funktion, die genauen Fristen, die die Änderung erzwingen, die Voraussetzungen und den schrittweisen Arbeitsablauf für die Implementierung beider Funktionen, die für die Umsetzung verantwortlichen Teams sowie die Kennzahlen, die zeigen, ob die Automatisierung tatsächlich funktioniert.

Kurzantwort: Was sind persistente DCV- und DNS-Konnektoren?

Persistent DCV (DNS-PERSIST-01) ermöglicht es einem Domaininhaber, einen TXT-Eintrag unter _validation-persist.[domain] zu veröffentlichen , der von einer Zertifizierungsstelle bei jeder Verlängerung automatisch erneut überprüft wird. Dadurch entfällt der manuelle DNS-Aufwand bei jeder Verlängerung. DNS-Konnektoren automatisieren die verbleibenden DNS-Änderungen über die Provider-API. Zusammen sind sie erforderlich, um die vom CA/Browser Forum festgelegte 47-tägige TLS-Gültigkeitsdauer (März 2029, Abstimmung SC-081v3) ohne nennenswerten manuellen Aufwand zu gewährleisten.

Wichtige Erkenntnisse

• Der Wahlvorschlag SC-081v3 des CA/Browser Forums verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage am 15. März 2026, auf 100 Tage am 15. März 2027 und auf 47 Tage am 15. März 2029, wobei die Wiederverwendungszeiträume für DCVs im gleichen Rhythmus auf 10 Tage sinken.
• Persistent DCV (DNS-PERSIST-01), das seit November 2025 gemäß Abstimmung SC-088v3 zulässig ist, ermöglicht die erneute Validierung einer Domain anhand eines einmal veröffentlichten TXT-Eintrags, wodurch die DNS-Arbeit bei jeder Verlängerung für etablierte Domains vollständig entfällt.
• DNS-Konnektoren automatisieren die verbleibenden DNS-Änderungen, einschließlich neuer Domains und der Ersteinrichtung, indem sie direkt mit der API des DNS-Anbieters kommunizieren, anstatt ein manuelles Ticket zu erstellen.
• Die Trust Pulse Survey von DigiCert (2. Juli 2025) ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten hatten, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für einen bestimmten Teil dieser Einführung verantwortlich; die untenstehende Verantwortlichkeits-/Aktionsmatrix und die Checkliste der Voraussetzungen zeigen genau, wer was tut.

Direkt zu: Zusammenfassung | Implementierungsablauf | Voraussetzungen-Maßnahmen-Matrix | Verantwortliche-Maßnahmen-Matrix | Erfolgskennzahlen | CertSecure Manager v3.3 | FAQ

Für wen sind persistente DCV- und DNS-Konnektoren relevant?

Die betrieblichen Folgen des vom CA/Browser Forum vorgeschlagenen Gültigkeitsreduzierungsplans betreffen Zertifikatsteams, DNS-Teams, Sicherheitsarchitekten, Plattformingenieure und Compliance-Abteilungen gleichermaßen. Jedes dieser Teams trägt die Verantwortung für einen spezifischen Schwachpunkt. Ein Zertifikatsteam, das die Erneuerung automatisiert, die DNS-Validierung jedoch nicht, stößt an seine Grenzen, sobald das DCV-Wiederverwendungsfenster abläuft. Ein DNS-Team, das API-Zugriff gewährt, aber die Rotation der Connector-Anmeldeinformationen nicht überwacht, erzeugt einen unbemerkten Fehler. Bei einer Gültigkeitsdauer von 47 Tagen ab März 2029 führt jede Lücke zu achtmal häufigeren Erneuerungsfehlern als vor 2029.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI- und Zertifikatsteams	Besitzen Sie das Zertifikatsinventar und die Beziehungen zu den Zertifizierungsstellen (CAs). Identifizieren Sie die Domains, die für die dauerhafte DCV (Domain Certificate Validation) in Frage kommen, und priorisieren Sie die Einführung nach Risiko (SAN- und Wildcard-Domains zuerst, da diese den höchsten Koordinierungsaufwand verursachen). Laut der DigiCert Trust Pulse Survey (2. Juli 2025) hatten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikaten. Bei einer Gültigkeitsdauer von 47 Tagen führt jeder Fehler bei der manuellen Validierung achtmal häufiger zu einem Ausfall als zuvor. Nur 34 % der Organisationen haben einen vollständigen und aktuellen Überblick über ihre Zertifikate (DigiCert PKI Under Pressure Report, 2. Juni 2026). Daher ist die Ermittlung der Zertifikate die Voraussetzung für alle weiteren Schritte.	Führen Sie eine vollständige Zertifikatserkennung durch mit CertSecure Manager um ein mit Eigentümer-Tags versehenes Inventar aller öffentlich vertrauenswürdigen Zertifikate und ihrer SAN-Liste zu erstellen; verwenden CBOM Secure Die Erkennung soll über TLS-Zertifikate hinaus auf den gesamten kryptografischen Bereich ausgeweitet werden; SAN- und Wildcard-Domänen sollen für das persistente DCV-Onboarding priorisiert werden; es soll bestätigt werden, welche ausstellenden Zertifizierungsstellen DNS-PERSIST-01 bereits unterstützen, und für diejenigen, die dies noch nicht tun, soll herkömmliches DNS-01 mit Konnektoren verwendet werden.
Plattform- und Infrastrukturteams	Eigener DNS-Provider-Zugriff und API-Zugangsdatenverwaltung sind Voraussetzung für die Connector-Integration. Der langsamste Teil der DNS-basierten Validierung ist in der Regel nicht die DNS-Abfrage, sondern die manuelle Übergabe zwischen Zertifikats- und DNS-Teams. Eine fehlgeschlagene Erneuerung, weil ein DNS-Änderungsticket nicht rechtzeitig bearbeitet wurde, führt genau zu den Ausfällen, die in der DigiCert-Umfrage vom Juli 2025 gemessen wurden. Connector-API-Zugangsdaten müssen korrekt definiert, regelmäßig aktualisiert und proaktiv getestet werden, anstatt erst bei einem fehlgeschlagenen Erneuerungsversuch als abgelaufen erkannt zu werden.	Fordern Sie API-Zugangsdaten mit TXT-Eintragsschreibzugriff für jeden verwendeten DNS-Anbieter (Route 53, Cloudflare, Azure DNS, Google Cloud DNS und alle anderen) an; verbinden Sie jeden Anbieter mit CertSecure Manager Mithilfe der DNS-Connector-Integration; testen Sie, ob ein TXT-Eintragszyklus (Schreiben, Validieren, Löschen) programmatisch und ohne Ticket abgeschlossen wird, bevor ein Produktionszertifikat davon abhängt; planen Sie die vierteljährliche Rotation der Anmeldeinformationen und testen Sie jeden Connector nach der Rotation, um sicherzustellen, dass er weiterhin erfolgreich Einträge schreibt.
Sicherheitsarchitekten	Verantworten Sie das Governance-Modell für Anmeldeinformationen und Überwachung, das die dauerhafte DCV-Sicherheit gewährleistet, anstatt eine neue Angriffsfläche zu schaffen. Die dauerhafte DCV verlagert den Schutz vor DNS-Schreibzugriffen (der bei jeder Verlängerung verfügbar sein muss) auf den ACME-Kontoschlüssel (der nur zum Einrichten des persistenten Eintrags benötigt wird). Ein kompromittierter oder unüberwachter ACME-Kontoschlüssel, der einen persistenten Eintrag unterstützt, kann die Zertifikatsausstellung für eine etablierte Domain autorisieren, ohne eine DNS-Änderungswarnung auszulösen. Der _validation-persist-Eintrag selbst muss auf unbefugte Änderungen überwacht werden.	Fügen Sie ACME-Kontoschlüssel, die persistente DCV-Einträge unterstützen, dem bestehenden Geheimnisverwaltungs- und Rotationsprogramm der Organisation hinzu, bevor Sie persistente DCV in großem Umfang einführen; konfigurieren Sie Überwachungsalarme für den _validation-persist TXT-Eintrag jeder Domäne, sodass jede unerwartete Änderung eine Untersuchung auslöst; definieren Sie das Vorgehen bei nicht autorisierten persistenten Einträgen (deaktivieren Sie das ACME-Konto gemäß RFC 8555 Abschnitt 7.5.2, um die Ausstellungsberechtigung sofort zu widerrufen); planen Sie die PQC-Bereitschaft für ACME-Schlüsselalgorithmen durch PQC Kompetenzzentrum und PQC-Bereitschaft Leistungen
Compliance-Teams	Es muss sichergestellt werden, dass die automatisierte DCV- und DNS-Connector-Aktivität für regulierte Frameworks protokolliert und auditierbar ist. DORA, NIS2, FedRAMP und CMMC verlangen jeweils einen Nachweis darüber, wer welche Domain wann validiert hat. Automatisierte Prozesse, die keine Audit-Trails hinterlassen, erfüllen diese Anforderung genauso wenig wie manuelle. Der Zeitplan des CA/Browser Forum SC-081v3 (47-tägige Gültigkeit bis März 2029) bedeutet außerdem, dass der Nachweis der DCV-Konformität achtmal häufiger als vor 2029 erbracht werden muss, wodurch die manuelle Erfassung von Audit-Nachweisen aus demselben Grund nicht mehr praktikabel ist wie die manuelle Validierung.	Bestätigen Sie, dass die Zertifikatslebenszyklusplattform jedes DCV-Ereignis (Domäne, Methode, Zeitstempel, CA-Konto, Ergebnis) mit ausreichendem Detailgrad für Prüfnachweise protokolliert; ordnen Sie DCV- und Konnektoraktivitätsprotokolle den geltenden Rahmenwerkskontrollanforderungen zu (DORA Artikel 9, NIS2 Artikel 21, FedRAMP SC-12, CMMC Practice CM.L2-3.4.2); stellen Sie sicher, dass die Aufbewahrungsfrist für Protokolle den Rahmenwerksanforderungen entspricht, bevor DCV vollständig automatisiert wird; bewerten Sie PKI als Service für Organisationen, bei denen der verwaltete PKI-Betrieb eine integrierte Audit-Protokollierung für DCV-Aktivitäten umfasst
CISOS	Zertifikatsausfälle aufgrund verpasster Validierungen sind betrieblich gleichwertig mit Ausfällen aufgrund abgelaufener Zertifikate, jedoch schwieriger zu diagnostizieren, da das Zertifikat zwar gültig und vertrauenswürdig erscheint, aber nicht verlängert werden kann. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 37.5 % der zertifikatsbezogenen Ausfälle auf ein abgelaufenes Zertifikat zurückzuführen waren und über die Hälfte davon zu Ausfallzeiten von 5 bis 24 Stunden mit finanziellen Verlusten zwischen 50,000 und 250,000 US-Dollar in 31 % der betroffenen Organisationen führten. Der vom CA/Browser Forum festgelegte Zeitplan zur Reduzierung der Gültigkeitsdauer ist unabhängig von der Bereitschaft der Organisation festgelegt. Daher ist eine Investition in die Automatisierung vor 2026 eher eine Risikominimierungsmaßnahme als ein optionales Upgrade.	Die kontinuierliche Einführung von DCV und DNS-Connector soll als Investition zur Reduzierung des operationellen Risikos vor Inkrafttreten der Schwellenwerte im März 2026 und März 2027 finanziert werden; die Abdeckung der Zertifikatsautomatisierung (Prozentsatz des öffentlichen TLS-Netzwerks unter geplanter CA-unabhängiger DCV) soll vierteljährlich als KPI auf Vorstandsebene berichtet werden; der Schutz von ACME-Kontoschlüsseln soll in die Überprüfung des Geheimnismanagementprogramms einbezogen werden; evaluieren PKI als Service für Organisationen, die einen verwalteten Zertifikatslebenszyklus mit integrierter DCV-Automatisierung und DNS-Connector-Abdeckung benötigen.

Zusammenfassung für Führungskräfte in den Bereichen Sicherheit, PKI, Plattformen und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und eine Kurzübersicht zur Umsetzung.

• PKI-/Zertifikatsteams: Inventarisieren Sie den öffentlichen TLS-Bestand, identifizieren Sie die Domains, die für persistentes DCV in Frage kommen, und priorisieren Sie SAN- und Wildcard-Domains für das Onboarding.
• Sicherheitsteams: Behandeln Sie den ACME-Kontoschlüssel hinter einem persistenten Datensatz als sensible Anmeldeinformation und fügen Sie das Risiko eines Zertifikatsausfalls derselben Überwachungsebene wie andere Verfügbarkeitsrisiken hinzu.
• Plattform-/Infrastrukturteams: Verbinden Sie DNS-Anbieter über API-basierte Konnektoren mit der Zertifikatslebenszyklusplattform, sodass DNS-Änderungen nicht mehr auf ein Änderungsmanagement-Ticket warten müssen.
• Compliance-Teams: Es muss sichergestellt werden, dass die Aktivitäten der automatisierten DCV- und DNS-Konnektoren protokolliert und auditierbar sind, da regulierte Umgebungen (DORA, NIS2, FedRAMP, CMMC) Nachweise darüber benötigen, wer was wann validiert hat.

Die Fristen, die den Wandel vorantreiben

Im April 2025 stimmte das CA/Browser Forum mit 29 Ja-Stimmen und keiner Gegenstimme für den Wahlvorschlag SC-081v3 mit dem Titel „Einführung eines Zeitplans zur Reduzierung der Gültigkeitsdauer und der Datenwiederverwendungszeiträume“. Der ursprünglich von Apple vorgeschlagene Wahlvorschlag sieht eine schrittweise Reduzierung sowohl der maximalen Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate als auch des Zeitraums vor, in dem Validierungsdaten wiederverwendet werden dürfen. Alle öffentlich vertrauenswürdigen TLS-Zertifikate sind betroffen, unabhängig davon, ob es sich um DV-, OV- oder EV-Zertifikate handelt, einschließlich Wildcard- und Multi-Domain-Zertifikate (SAN). Die Analyse von Sectigo vom 14. April 2025 sieht diesen Zeitplan als schrittweisen Übergang und nicht als abrupte Änderung hin zu einer automatisierten, quantensicheren Zertifikatsverwaltung.

Datum des Inkrafttretens	Maximale TLS-Gültigkeit	Wiederverwendungszeitraum des DCV	SII-Wiederverwendung (OV/EV)
Bis zum 14. März 2026	398 Tage	398 Tage	825 Tage
15. März 2026	200 Tage	200 Tage	398 Tage
15. März 2027	100 Tage	100 Tage	398 Tage
15. März 2029	47 Tage	10 Tage	398 Tage

Die Gültigkeitsdauer und die Wiederverwendungsbeschränkungen für DCV-Zertifikate richten sich nach dem Ausstellungsdatum des Zertifikats, nicht nach dem Datum der Bestellung.

Das Zeitfenster für die Wiederverwendung von Subjektidentitätsinformationen (SII) für OV- und EV-Zertifikate verkürzt sich am 15. März 2026 von 825 auf 398 Tage. Damit endet das bisherige Modell „einrichten und vergessen“ für Zertifikate mit hoher Sicherheit. Die vollständigen zugehörigen Vorgaben, einschließlich der separaten Frist für Chrome Dual-EKU am 15. Juni 2026, finden Sie in unserer Analyse der CA/Browser-Forum-Vorgabe . Diese Änderung betrifft auch die Frage, wann eine öffentliche bzw. eine private Zertifizierungsstelle (CA) verwendet werden sollte.

Warum kürzere Zertifikate die manuelle Domainvalidierung beeinträchtigen

Die Herausforderung liegt nicht im Zertifikat selbst, sondern in der Häufigkeit der Neuausstellung. Nehmen wir eine Organisation mit 1,000 öffentlich anerkannten Zertifikaten. Bei einer Gültigkeitsdauer von 398 Tagen fallen derzeit jährlich etwa 1,000 Erneuerungen an. Bis 2029, bei einer Gültigkeitsdauer von 47 Tagen, werden es über 8,000 Erneuerungen pro Jahr sein – eine Verachtfachung des Arbeitsaufwands.

Die Validierung ist noch direkter betroffen. Wenn das DCV-Wiederverwendungsfenster auf 10 Tage sinkt, Zertifikate aber 47 Tage gültig sind, muss die Domaininhaberschaft pro Domain etwa 35 Mal pro Jahr neu nachgewiesen werden. E-Mail-basierte Validierung und einmalige HTTP-Dateiplatzierung sind in diesem Rhythmus nicht möglich. Besonders betroffen sind Teams, die große Domainbestände, SAN-Zertifikate mit mehreren Domains unter einer Validierung und Wildcard-Domains verwalten. Das Risiko ist am größten, wenn die DNS-Verantwortung auf Netzwerk-, Infrastruktur- und Plattformteams verteilt ist und jede Änderung ein Änderungsmanagement-Ticket erfordert.

Die Schlussfolgerung liegt auf der Hand: Bei maschinell beschleunigten Erneuerungszyklen ist die manuelle Zertifikatsverwaltung nicht mehr praktikabel, und die Zertifikatsautomatisierung wird zum Standard. Die Frage ist, welche Form der Automatisierung das größte operationelle Risiko minimiert.

Die Daten hinter der Dringlichkeit

Die obige Rechnung ist nicht theoretisch. Aktuelle Branchenstudien quantifizieren genau, was passiert, wenn Validierung und Erneuerung mit einem komprimierten Zertifizierungszyklus nicht Schritt halten können:

• 45 % der Unternehmen erlebten im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen., laut DigiCert Vertrauens-Pulsumfrage, veröffentlicht am 2. Juli 2025. Mehr als die Hälfte der betroffenen Organisationen verzeichneten Ausfallzeiten von 5 bis 24 Stunden, und 31 % meldeten finanzielle Verluste zwischen 50,000 und 250,000 US-Dollar.
• 72 % der Organisationen erlebten im vergangenen Jahr mindestens einen Ausfall im Zusammenhang mit Zertifikaten.laut CyberArk Bericht zum Stand der maschinellen Identitätssicherheit 2025, für die 1,200 Sicherheitsverantwortliche in sechs Ländern befragt wurden.
• Nur 34 % der Organisationen verfügen über einen vollständigen und aktuellen Überblick über ihre digitalen Zertifikate.Laut DigiCert sind fast 75 % der Befragten sehr oder extrem besorgt über Ausfälle, die durch abgelaufene Zertifikate verursacht werden. „PKI unter Druck: Der Wendepunkt für die Modernisierung“ Der Bericht wurde am 2. Juni 2026 veröffentlicht und basiert auf einer Umfrage unter mehr als 400 leitenden IT- und Sicherheitsexperten.
• Die automatisierte, DNS-validierte Ausstellung ist bereits die Norm.Allein die automatisierte ACME-Zertifikatsausstellung von Let's Encrypt macht mehr als 60 % aller verwendeten TLS-Zertifikate aus, und über 94 % aller heute ausgestellten Zertifikate sind domänenvalidiert, die meisten davon werden im ersten Quartal 2026 sofort durch automatisierte Prozesse ausgestellt.SSLreminder, „Status von TLS im ersten Quartal 2026“).

Persistente DCV- und DNS-Konnektoren sind die Mechanismen, die es der Domainvalidierung ermöglichen, mit diesem Wandel hin zur stets automatisierten Ausstellung Schritt zu halten, anstatt zum nächsten operativen Engpass zu werden, sobald sich die Erneuerungshäufigkeit vervielfacht.

Was ist Domänenkontrollvalidierung (DCV)?

Die Domänenkontrollvalidierung ist das Verfahren, mit dem eine Zertifizierungsstelle (CA) bestätigt, dass ein Zertifikatsantragsteller die in der Anfrage angegebene Domäne kontrolliert. Die CA/Browser Forum Baseline Requirements definieren mehrere anerkannte Methoden. Die drei gängigsten sind:

• Die DNS-basierte Validierung erfordert, dass der Antragsteller einen TXT-Eintrag unter der Domain veröffentlicht, den die Zertifizierungsstelle anschließend prüft. Dies ist die einzige Methode, die Wildcard-Domains verarbeitet und sich durch Automatisierung problemlos skalieren lässt.
• Die HTTP-basierte Validierung erfordert, dass der Antragsteller eine Datei unter einem bekannten Pfad auf dem Webserver ablegt. Dies funktioniert für einzelne Hosts, stößt aber bei verteilten oder Load-Balancing-Systemen an seine Grenzen.
• Die E-Mail-basierte Validierung erfordert, dass der Antragsteller auf eine an einen Domain-Kontakt gesendete Nachricht antwortet. Dieses Verfahren ist manuell kontrollierbar und wird schrittweise durch eine automatisierte Ausstellung ersetzt.

Für Organisationen mit großem Funktionsumfang ist die DNS-basierte Validierung die praktikabelste Lösung. Sie funktioniert mit Wildcards, lässt sich vollständig über APIs steuern und bildet die Grundlage für die automatisierten Ausstellungsprotokolle , die durch den neuen Zeitplan faktisch verpflichtend werden, insbesondere ACME und dessen DNS-01-Challenge. Sowohl persistente DCV als auch DNS-Konnektoren bauen direkt auf dieser DNS-basierten Grundlage auf.

Was ist Persistent DCV (DNS-PERSIST-01)?

Persistent DCV ist eine DNS-basierte Validierungsmethode, die das Erstellen und Löschen eines DNS-Eintrags für jede Zertifikatsausstellung überflüssig macht. Sie wurde als Abschnitt 3.2.2.4.22 mit dem Titel „DNS TXT Record with Persistent Value“ (auch bekannt als DNS-PERSIST-01) in die Baseline Requirements aufgenommen ( Abstimmung SC-088v3 ) und ist seit November 2025 zulässig. Vorgeschlagen wurde sie von Amazon Trust Services und unterstützt unter anderem Google Chrome, DigiCert und Sectigo.

Die Funktionsweise ist einfach. Anstatt für jedes Validierungsereignis einen neuen, temporären Eintrag zu erstellen, veröffentlicht der Domaininhaber einmalig einen einzigen, kontobezogenen TXT-Eintrag unter dem Label _validation-persist.[domain]. Dieser Eintrag identifiziert das CA-Konto des Antragstellers. Anschließend führt die CA automatisch wiederkehrende Validierungsprüfungen anhand desselben Eintrags durch, ohne dass weitere DNS-Änderungen erforderlich sind. Wichtig ist, dass die persistente DCV die Überprüfung der Domaininhaberschaft nicht schwächt. Das CA/Browser Forum fordert, dass sie die gleiche Sicherheit wie bestehende DNS-basierte Methoden bietet. Sie ändert lediglich Zeitpunkt und Art der Überprüfung und führt von ereignisgesteuerten Prüfungen zu einer kontinuierlichen, automatisierten Revalidierung. Die CAs sind weiterhin an die 10-tägige Wiederverwendungsgrenze gebunden, und die persistente DCV bedeutet, dass der zugrunde liegende Eintrag nicht neu erstellt werden muss, um diese Grenze zu erfüllen.

Das persistente TXT-Datensatzformat

Der Datensatz selbst kodiert, wer zur Ausstellung berechtigt ist. Ein persistenter TXT-Datensatz hat folgendes Format:

_validation-persist.example.com IN TXT (
    "authority.example;"
    " accounturi=https://authority.example/acct/123;"
    " persistUntil=1782424856"
)

Der Datensatzname identifiziert die Domäne; die Autorität benennt die Zertifizierungsstelle (CA); accounturi identifiziert das zur Ausstellung berechtigte ACME-Konto (gemäß RFC 8657 und stabil über Schlüsselrotationen hinweg gemäß RFC 8555 Abschnitt 7.3.5); und das optionale persistUntil legt ein Ablaufdatum fest. Die CA überprüft diesen einzelnen Datensatz dann bei jeder Ausstellung erneut.

Die betrieblichen Einsparungen skalieren mit der Größe des Domainbestands. Eine Organisation, die 100 Domains viermal jährlich validiert, führt unter dem herkömmlichen DNS-01-Verfahren jährlich etwa 400 DNS-Änderungen durch, im Vergleich zu 100 einmaligen Einträgen unter persistenter DCV.

Ein Kompromiss erfordert besondere Beachtung. Da ein dauerhafter Eintrag die Ausstellung autorisiert, verlagert sich der zu schützende Zugriffspunkt vom DNS-Schreibzugriff auf den ACME-Kontoschlüssel. Behandeln Sie diesen Schlüssel als sensible Zugangsdaten, überwachen Sie den dauerhaften Eintrag auf unerwartete Änderungen und beachten Sie, dass die Ausstellung durch Deaktivierung des ACME-Kontos sofort widerrufen werden kann (RFC 8555 Abschnitt 7.5.2).

Traditionelle DCV vs. Persistente DCV

Traditionelles DNS-basiertes DCV	Persistenter DCV (DNS-PERSIST-01)
Für jedes Ausgabeereignis wird ein eindeutiger, temporärer TXT-Datensatz erstellt.	Ein einzelner persistenter TXT-Datensatz wird einmalig unter _validation-persist veröffentlicht.
Der Datensatz wird in jedem Zyklus hinzugefügt, validiert und anschließend entfernt oder rotiert.	Die Zertifizierungsstelle überprüft denselben Datensatz bei jeder Ausstellung erneut; eine DNS-Änderung ist nicht erforderlich.
Die DNS-Koordination wird bei jeder Erneuerung wiederholt, was den Fehlerpunkt darstellt, dessen Häufigkeit mit der Anzahl der Erneuerungen zunimmt.	Die DNS-Koordination erfolgt einmalig bei der Einrichtung; Erneuerungen sind von der DNS-Arbeit entkoppelt.
Wird 8-mal häufiger, wenn die Gültigkeitsdauer auf 47 Tage verkürzt wird.	Die Häufigkeit der Ausgabe von DNS-Anfragen ist nicht mehr ausschlaggebend für die DNS-Auslastung.

Was sind DNS-Konnektoren?

Die persistente DCV reduziert die Häufigkeit erforderlicher DNS-Änderungen; DNS-Konnektoren übernehmen die verbleibenden Änderungen. Ein DNS-Konnektor ist eine Integration zwischen einer Zertifikatslebenszyklusplattform und einem DNS-Anbieter. Er ermöglicht es der Plattform, TXT-Einträge programmatisch über die API des Anbieters zu erstellen, zu aktualisieren und zu validieren, anstatt dass ein DNS-Administrator jede Änderung manuell vornehmen muss.

Dies ist relevant, da der langsamste Teil der DNS-basierten Validierung üblicherweise nicht die DNS-Abfrage selbst, sondern die manuelle Übergabe ist. Ein Zertifizierungsteam fordert einen Eintrag an, ein Netzwerkteam plant die Änderung, ein Genehmigungszeitraum verstreicht, und erst dann kann die Validierung abgeschlossen werden. Bei einer jährlichen Validierung ist diese Verzögerung tolerierbar. Bei Dutzenden von Validierungen pro Domain und Jahr wird sie jedoch zur Hauptursache für Betriebsstörungen und Ausfallrisiken, da eine Verlängerung komplett fehlschlagen kann, wenn der Validierungseintrag nicht rechtzeitig vorhanden ist. Konnektoren eliminieren diese manuelle Übergabe: Die Plattform kommuniziert direkt mit dem DNS-Anbieter, und der Eintrag wird automatisch erstellt, validiert und verwaltet – ganz ohne Ticket.

Wie persistente DCV- und DNS-Konnektoren zusammenarbeiten

Die beiden Funktionen ergänzen sich, sind aber nicht austauschbar. Persistente DCV eliminiert DNS-Anpassungen während des Verlängerungszyklus. DNS-Konnektoren automatisieren die weiterhin notwendigen DNS-Änderungen, einschließlich der Veröffentlichung des initialen persistenten Eintrags und der Integration neuer Domains. In Kombination bieten sie einem Team zwei entscheidende Möglichkeiten:

• Wenn ein persistenter Eintrag verwendet werden kann, werden DNS-Änderungen während der Erneuerung vollständig entfernt, sodass die Ausgabehäufigkeit nicht mehr die DNS-Arbeitslast bestimmt.
• Wo dennoch eine DNS-Änderung erforderlich ist (neue Domains, Ersteinrichtung, Anbieter ohne dauerhafte Unterstützung), führt ein Konnektor diese automatisch und ohne manuelle Koordination aus.

Das Ergebnis ist ein Validierungsworkflow, der sich problemlos skalieren lässt, wenn sowohl das Zertifikatsvolumen als auch die Erneuerungshäufigkeit steigen – genau das, was die Fristen von 2027 und 2029 erfordern.

DCV-Automatisierung: Anforderungen, Fehlermodi und Überwachungssignale

Anhand dieser Tabelle können Sie jede DCV-Automatisierungsanforderung ihrer Validierungsmethode, dem Fehlermodus bei Nichterfüllung der Anforderung, dem Überwachungssignal, das den Fehler meldet, und der maßgeblichen Richtlinienquelle zuordnen. Die CA/Browser Forum SC-081v3 und SC-088v3 werden vierteljährlich überprüft und können unabhängig voneinander aktualisiert werden.

Anforderung	Validierungsmethode	Fehlermodus	Überwachungssignal	Richtlinienquelle
Der persistente TXT-Eintrag wird von allen autoritativen Nameservern korrekt aufgelöst.	Abfrage von _validation-persist.[domain] bei mehreren DNS-Resolvern in verschiedenen geografischen Regionen; Bestätigung, dass alle Resolver denselben Datensatz zurückgeben; Test mit öffentlichen DNS-Resolvern (Google 8.8.8.8, Cloudflare 1.1.1.1); DNS-Validierungsprüfung der CLM-Plattform	DNS-Propagationsverzögerungen oder Zonentransferlücken führen dazu, dass die Validierungsprüfung der Zertifizierungsstelle aus einer oder mehreren Perspektiven fehlschlägt. MPIC (CA/Browser Forum SC-067) prüft nun CAA und DCV von mehreren Netzwerkstandorten aus, sodass eine aus einer Region sichtbare Inkonsistenz die Validierung fehlschlagen lässt; die Erneuerung schlägt fehl, obwohl der Eintrag aus einer einzelnen Perspektive korrekt erscheint.	CLM-Plattform-Alarm bei DCV-Validierungsfehler für eine Domain mit bestehendem persistenten Eintrag; Zertifikatserneuerungsfehler in Verbindung mit DNS-Propagationsfehlern in CA-Protokollen; DNS-Überwachungsalarm bei TXT-Eintragspropagationsfehler an einen oder mehrere autoritative Nameserver	CA/Browser Forum Abstimmung SC-088v3 (DNS-PERSIST-01, November 2025); Abstimmung SC-081v3 (DCV-Wiederverwendungszeiträume); Abstimmung SC-067 (MPIC, September 2025)
Die Anmeldeinformationen für die DNS-Connector-API sind gültig, haben den erforderlichen Gültigkeitsbereich und wurden getestet.	Testen Sie den Schreib-, Validierungs- und Löschzyklus eines TXT-Eintrags über den Connector, bevor ein Produktionszertifikat davon abhängt; bestätigen Sie, dass die Anmeldeinformationen Schreibzugriff auf TXT-Einträge auf die beteiligten Zonen (nicht kontoweit) beschränkt sind; überprüfen Sie das Ablaufdatum der Anmeldeinformationen; planen Sie die vierteljährliche Rotation ein und testen Sie nach jeder Rotation.	Ein Connector mit schreibgeschützten, abgelaufenen oder zu umfangreichen API-Anmeldeinformationen schlägt beim nächsten geplanten Lauf ohne Fehlermeldung fehl; die DNS-Änderung wird nicht vorgenommen; die Validierungsprüfung der Zertifizierungsstelle findet keinen Eintrag; die Erneuerung schlägt fehl; der Fehler kann als DCV-Fehler anstatt als Anmeldeinformationsfehler erscheinen, was die Diagnose verlangsamt.	CLM-Plattformwarnung bei fehlgeschlagenem Connector-Aufruf; DNS-Provider-Audit-Protokoll zeigt fehlgeschlagene API-Authentifizierung an; Anstieg von Zertifikatserneuerungsfehlern korreliert mit dem Ablaufdatum der Anmeldeinformationen; Connector-Integritätsprüfungs-Dashboard zeigt den Zeitstempel des letzten erfolgreichen Schreibvorgangs an	CA/Browser Forum Abstimmung SC-081v3 (DCV-Wiederverwendungszeiträume, die eine automatische Validierung erfordern); Dokumentation zur API-Authentifizierung von DNS-Anbietern; Richtlinie zur internen Rotation von Anmeldeinformationen
Der persistente Datensatz accounturi stimmt mit dem aktiven ACME-Konto für jede ausstellende CA überein.	Vergleichen Sie den Wert von accounturi im _validation-persist TXT-Eintrag mit der vom Account-Endpunkt der Zertifizierungsstelle zurückgegebenen ACME-Account-URL (RFC 8555 Abschnitt 7.3); bestätigen Sie, dass das Account aktiv und nicht deaktiviert ist; testen Sie, ob die Zertifizierungsstelle den persistenten Datensatz für eine Testausgabe akzeptiert.	Ein persistenter Datensatz, der für das falsche Konto erstellt wurde (falsche Zertifizierungsstelle, migriertes Konto oder geänderte Konto-URL), wird entweder für die falsche Zertifizierungsstelle validiert oder gar nicht; die Zertifikatserneuerung schlägt fehl; die Zertifizierungsstelle gibt einen DCV-Fehler zurück, der die Diskrepanz der Konto-URI nicht explizit benennt, was die Diagnose verlangsamt.	Fehler bei der DCV-Validierung der CLM-Plattform für eine Domäne mit einem persistenten Datensatz; CA-Fehlerantwort mit der Meldung, dass das Konto nicht autorisiert oder der Datensatz nicht erkannt wurde; CLM-Plattformwarnung über eine Änderung des accounturi-Werts eines persistenten Datensatzes seit der letzten Prüfung	CA/Browser Forum Abstimmung SC-088v3 Abschnitt 3.2.2.4.22 (Anforderung an das Feld „accounturi“); RFC 8657 (Stabilität des ACME-Kontoschlüssel-Rollovers); RFC 8555 Abschnitt 7.3.5 (Stabilität der Konto-URL bei Schlüsselrotationen)
Der persistente Datensatz wird auf unbefugte Änderungen überwacht.	Konfigurieren Sie die DNS-Überwachung für den TXT-Eintrag _validation-persist.[domain], der bei jeder Wertänderung eine Warnung ausgibt; bestätigen Sie, dass die Überwachungsplattform die Prüfungen von mehreren geografischen Standorten aus durchführt; testen Sie die Warnung, indem Sie den Eintragswert vorübergehend in einer Nicht-Produktionszone ändern.	Eine unbefugte Änderung des persistenten Eintrags bleibt unentdeckt; der geänderte Eintrag kann eine andere Zertifizierungsstelle oder ein anderes ACME-Konto zur Ausstellung von Zertifikaten für die Domain autorisieren; da der Eintrag dauerhaft und nicht pro Verlängerung gültig ist, ist das Risiko kontinuierlich und nicht auf einen Verlängerungszyklus beschränkt.	DNS-Überwachungsalarm bei Änderung des _validation-persist-TXT-Eintragswerts; CLM-Plattformalarm bei unerwarteter Änderung der Zertifizierungsstelle oder des Kontos im persistenten Eintrag; Alarm des externen DNS-Überwachungsdienstes bei Änderung eines Eintrags	CA/Browser Forum Abstimmung SC-088v3 (Anforderungen an die Sicherheit persistenter Datensätze); RFC 8555 Abschnitt 7.5.2 (Deaktivierung des ACME-Kontos zum Widerruf der Ausstellungsberechtigung); CA/Browser Forum Basisanforderungen Abschnitt 4.9 (Verpflichtungen zum Zertifikatswiderruf)
Die DCV-Automatisierung läuft nach einem Zeitplan, der auf den Erneuerungsrhythmus abgestimmt ist.	Stellen Sie sicher, dass die CLM-Plattform so konfiguriert ist, dass die Domänenvalidierung vor jeder Verlängerung in einem Intervall durchgeführt wird, das innerhalb des geltenden DCV-Wiederverwendungszeitraums liegt (200 Tage bis März 2027, 100 Tage bis März 2029, 10 Tage ab März 2029). Testen Sie, ob die DCV automatisch und ohne manuelle Auslösung ausgeführt wird. Stellen Sie sicher, dass die CA-unabhängige Planung gewährleistet ist, sodass die gleiche Automatisierung unabhängig davon gilt, welche öffentliche CA das Zertifikat ausstellt.	Die DCV-Automatisierung ist nicht geplant oder auf ein Wiederverwendungsfenster konfiguriert, das länger als die geltende Grenze ist; die DCV-Nachweise der Zertifizierungsstelle laufen vor der nächsten Verlängerung ab; die Zertifizierungsstelle verweigert die Ausstellung, da die Domänenvalidierungsdaten veraltet sind; dieser Fehlermodus tritt häufiger auf, je kleiner das Wiederverwendungsfenster wird.	CLM-Plattform-Warnung: DCV-Nachweis läuft bald ab; Zertifikatserneuerung schlägt aufgrund abgelaufener DCV-Nachweise in den CA-Protokollen fehl; CLM-Plattform-Dashboard zeigt Domains an, deren DCV-Letzte-Ausführungszeitpunkt älter als das geltende Wiederverwendungsfenster ist	CA/Browser Forum Abstimmung SC-081v3 (DCV-Wiederverwendungszeiträume: 200 Tage März 2026, 100 Tage März 2027, 10 Tage März 2029); CA/Browser Forum Basisanforderungen Abschnitt 3.2.2.4 (DCV-Methodenanforderungen)

Voraussetzungen vor der Implementierung

Stellen Sie sicher, dass diese Voraussetzungen erfüllt sind, bevor Sie persistente DCV- oder DNS-Konnektoren einrichten, damit die Einführung nicht mittendrin ins Stocken gerät:

1. Ein aktuelles Zertifikatsverzeichnis. Bevor Sie entscheiden können, welche Domains für die dauerhafte DCV in Frage kommen, benötigen Sie eine durch Discovery-Verfahren erstellte Liste aller öffentlich vertrauenswürdigen Zertifikate und der von ihnen abgedeckten Domains.
2. API-Zugriff auf jeden verwendeten DNS-Anbieter. DNS-Konnektoren authentifizieren sich gegenüber der API des Anbieters (Route 53, Cloudflare, Azure DNS, Google Cloud DNS und ähnliche). Daher benötigen Sie API-Zugangsdaten mit der Berechtigung zum Schreiben von TXT-Einträgen, die auf die betroffenen Zonen beschränkt sind.
3. Ein CA-Konto, das ACME und, sofern verfügbar, DNS-PERSIST-01 unterstützt. Bitte prüfen Sie, welche Ihrer ausstellenden Zertifizierungsstellen bereits persistentes DCV unterstützen, da es sich um eine neu zugelassene Methode handelt, die von den Zertifizierungsstellen noch eingeführt wird.
4. Ein benannter Inhaber zur Genehmigung von DNS-Änderungen. Auch bei automatisierten DNS-Änderungen muss aus Prüfungsgründen ein definierter Datensatzverantwortlicher festgelegt werden, typischerweise das Plattform- oder Infrastrukturteam.
5. Eine Plattform für das Zertifikatslebenszyklusmanagement wie CertSecure Manager in der Lage zu sein, wiederkehrende DCV-Aufrufe zu planen und DNS-Connector-Aufrufe auszuführen, anstatt einmalige Skripte zu verwenden.

Schrittweiser Implementierungsablauf

Sobald die oben genannten Voraussetzungen erfüllt sind, erfolgt die Einführung in fünf Schritten. Jeder Schritt benennt das Ergebnis, das Sie vor dem nächsten Schritt erwarten können.

Schritt 1: Inventarisierung des Zertifikatsbestands

Ermitteln Sie alle öffentlich vertrauenswürdigen Zertifikate, insbesondere jene, deren Gültigkeit nach dem 15. März 2026 abläuft. Lücken in der Zertifikatserkennung und Zertifikate, an die sich niemand erinnert, sind die häufigste Ursache für unbemerkte Ausfälle. Kennzeichnen Sie jedes Zertifikat mit der zugehörigen Domain, der SAN-Liste und dem Inhaber. Ergebnis: ein vollständiges, mit Inhabern versehenes Verzeichnis aller öffentlichen TLS-Zertifikate.

Schritt 2: DNS-Anbieter einbinden

Verbinden Sie jeden DNS-Anbieter, der Ihre Zonen hostet, mithilfe seiner API-Zugangsdaten mit der Zertifikatslebenszyklusplattform, damit DNS-01-Challenge-Einträge programmatisch erstellt und verifiziert werden können. Dadurch entfällt die manuelle Übergabe zwischen Zertifikats- und DNS-Teams. Ergebnis: Alle DNS-Anbieter im Netzwerk sind verbunden, und die Plattform kann ohne manuelles Ticket einen Test-TXT-Eintrag erstellen.

Abbildung 1. DNS-Provider-Onboarding und DNS-01-Connector-Konfiguration im CertSecure Manager.

Schritt 3: Veröffentlichen des persistenten Validierungsdatensatzes

Für qualifizierte Domains veröffentlichen Sie den einmaligen TXT-Eintrag unter _validation-persist.[domain] im zuvor gezeigten Format mithilfe des Connectors anstelle eines manuellen DNS-Tickets. Priorisieren Sie SAN- und Wildcard-Domains, da diese im alten Modell den höchsten Koordinierungsaufwand verursachen. Ergebnis: Der persistente Eintrag wird korrekt aufgelöst und die ausstellende Zertifizierungsstelle bestätigt die Erkennung des Kontos.

Schritt 4: Konfigurieren der geplanten DCV-Automatisierung

Konfigurieren Sie die Zertifikatslebenszyklusplattform so, dass die Domänenvalidierung regelmäßig und entsprechend dem nun erforderlichen Erneuerungszyklus Ihrer Zertifikate durchgeführt wird, anstatt die Validierung bei jeder Erneuerung manuell auszulösen. Achten Sie darauf, dass diese Konfiguration unabhängig von der Zertifizierungsstelle (CA) ist, sodass derselbe Zeitplan gilt, egal welche öffentliche CA ein bestimmtes Zertifikat ausstellt. Ergebnis: Die Domänenvalidierung wird automatisch vor jeder Erneuerung durchgeführt, ohne dass ein Eingriff pro Zyklus erforderlich ist.

Abbildung 2. Geplanter DNS-01-Domänenvalidierungsstatus im CertSecure Manager.

Schritt 5: Validieren, Überwachen und Festlegen von Rollback-Schutzmaßnahmen

Stellen Sie sicher, dass ein vollständiger Erneuerungszyklus ohne manuelle Eingriffe abgeschlossen wird. Aktivieren Sie anschließend die Überwachung des persistenten Datensatzes (unerwartete Änderungen sind ein Warnsignal) und von Verbindungsfehlern. Dokumentieren Sie den Rollback-Pfad, bevor Sie ihn benötigen. Ergebnis: Mindestens ein vollständiger automatisierter Erneuerungszyklus wird erfolgreich abgeschlossen, und es werden Benachrichtigungen für den Datensatz und die Verbindung eingerichtet.

Rollback-Anleitung und häufige Fehler

Häufige Fehler, auf die Sie achten sollten

• DNS-Propagationsverzögerungen. Ein neu geschriebener TXT-Eintrag, der noch nicht über alle autoritativen Nameserver verbreitet wurde, führt dazu, dass die Validierungsprüfung der Zertifizierungsstelle fehlschlägt; bauen Sie eine Verbreitungsprüfung in den Workflow ein, bevor Sie die Ausstellung auslösen.
• Der Gültigkeitsbereich der API-Zugangsdaten ist zu eng gefasst oder abgelaufen. Ein DNS-Connector mit schreibgeschützten oder abgelaufenen API-Anmeldeinformationen schlägt beim nächsten geplanten Lauf stillschweigend fehl; überprüfen und testen Sie die Anmeldeinformationen regelmäßig, nicht nur, wenn eine Erneuerung fehlschlägt.
• Der persistente Datensatz wurde unter dem falschen CA-Konto veröffentlicht. Da der Wert accounturi den Datensatz mit einem bestimmten ACME-Konto verknüpft, wird ein für das falsche Konto erstellter Datensatz entweder für die falsche CA validiert oder gar nicht.
• Es findet keine Überwachung des persistenten Datensatzes selbst statt. Da die Aufzeichnung die Ausstellung fortlaufend autorisiert, hat eine unbemerkte Änderung daran weitreichendere Folgen als früher eine versäumte einmalige Validierung.

Sicheres Zurücksetzen

Wenn die persistente DCV für eine Domain rückgängig gemacht werden muss, entfernen Sie entweder den TXT-Eintrag „_validation-persist“ oder deaktivieren Sie das zugehörige ACME-Konto (RFC 8555 Abschnitt 7.5.2), wodurch die Ausstellungsberechtigung sofort widerrufen wird. Halten Sie die herkömmliche DNS-01-Validierung als Ausweichpfad für alle Domains bereit, die auf persistente DCV migriert wurden, und testen Sie diesen Ausweichpfad, bevor Sie ihn in der Produktion einsetzen. Deaktivieren Sie bei DNS-Konnektoren die Integration des jeweiligen Anbieters, anstatt den plattformweiten API-Zugriff zu widerrufen, damit andere Anbieter während der Fehlerbehebung weiterhin funktionieren.

Voraussetzung-zu-Aktions-Matrix

Voraussetzung	Action	Eigentümerteam
Zertifikatsbestand unvollständig	Führen Sie eine Erkennung in öffentlichen und privaten Netzwerken durch; kennzeichnen Sie jedes Zertifikat mit Domäne, SAN-Liste und Inhaber	PKI/Zertifikatsteam
DNS-Anbieter-API-Zugriff noch nicht gewährt	Anforderung von API-Zugangsdaten mit TXT-Schreibberechtigung für jeden Anbieter	Plattform-/Infrastrukturteam
Die Zertifizierungsstelle unterstützt DNS-PERSIST-01 noch nicht.	Bestätigen Sie die dauerhafte DCV-Unterstützung direkt bei jeder ausstellenden Zertifizierungsstelle; verwenden Sie in der Zwischenzeit herkömmliches DNS-01 mit Konnektoren.	PKI/Zertifikatsteam
Kein benannter Inhaber für automatische DNS-Änderungen	Weisen Sie einen Verantwortlichen für die Eintragung im Prüfungsregister zu und dokumentieren Sie dies.	Sicherheits-/Compliance-Team
Keine geplante DCV-Automatisierung in der Lebenszyklusplattform	Konfigurieren Sie eine wiederkehrende, CA-unabhängige Domänenvalidierung, die auf den Erneuerungsrhythmus abgestimmt ist.	PKI/Zertifikatsteam

Vorher und Nachher: ​​DNS-Validierungsvorgänge

Operativer Schritt	Vorher (manuell)	Nach (persistenten DCV- und DNS-Konnektoren)
DNS-Änderung anfordern	Ticket beim Netzwerkteam eingereicht, in der Warteschlange hinter anderen Änderungsanfragen.	Die Zertifikatsplattform schreibt den Datensatz direkt über die API des Anbieters.
Überprüfung der Domaininhaberschaft	Wird bei jeder Verlängerung wiederholt, bis zu ca. 35 Mal pro Jahr und Domain bis 2029	Einmaliger Eintrag für etablierte Domains; keine DNS-Änderungen bei jeder Verlängerung
Genehmigungsfrist	Stunden bis Tage, abhängig von den Änderungsmanagementfenstern	Minuten, da im DNS-Pfad keine menschliche Genehmigung erfolgt.
Ausfallpunkt bei hoher Erneuerungsfrequenz	Eine versäumte oder verzögerte DNS-Änderung führt dazu, dass die Erneuerung selbst fehlschlägt.	Die Erneuerung erfolgt unabhängig vom DNS, sobald der persistente Eintrag vorhanden ist.
Audit-Trail	Verstreut über das Ticketsystem, die DNS-Konsole und das CA-Portal	Zentralisiert im Connector der Zertifikatslebenszyklusplattform und in den DCV-Protokollen

Entscheidungstabelle: Welcher DNS-01-Automatisierungspfad passt zu Ihrer Organisation?

Nicht jede Immobilie benötigt denselben Ausgangspunkt. Nutzen Sie die untenstehende Tabelle, um Ihre aktuelle Situation dem passenden nächsten Schritt zuzuordnen.

Deine Situation	Empfohlener Weg	Warum
Kleiner Nachlass (weniger als 50 öffentliche Zertifikate), jährlicher Erneuerungszyklus heute	Führen Sie die manuelle oder automatisierte Verlängerung kurzfristig fort, planen Sie aber bis März 2027 eine Gültigkeitsdauer von 100 Tagen ein.	Das Erneuerungsvolumen ist noch gering genug, um es manuell zu bewältigen, aber der Schwellenwert von 2027 vervierfacht die Erneuerungshäufigkeit in etwa.
DNS-Änderungen durchlaufen einen Ticket- oder Änderungsmanagementprozess.	DNS-Konnektoren sollten zuerst priorisiert werden.	Dadurch wird die menschliche Übergabe beseitigt, die zum Fehlerpunkt wird, sobald die Validierung alle paar Wochen wiederholt werden muss.
Große oder SAN-/Wildcard-lastige Domain-Umgebungen, die sich über mehrere Domains erstrecken	Verwenden Sie persistenten DCV (DNS-PERSIST-01) für etablierte Domänen, gepaart mit DNS-Konnektoren für neue Domänen.	Entfernt den DNS-Aufwand bei jeder Verlängerung für bereits validierte Domains vollständig und reduziert die DNS-Änderungen von Hunderten pro Jahr auf eine einmalige Einrichtung pro Domain.
Multi-Cloud- oder Hybrid-PKI-Umgebung, die sich über mehrere öffentliche und private Zertifizierungsstellen erstreckt	Setzen Sie CA-unabhängige Automatisierungslösungen wie CertSecure Manager v3.3 ein, die geplante DCV-Prüfungen, DNS-Konnektoren und eine zentrale Protokollierung von Audit-Vorgängen kombinieren.	Gewährleistet eine konsistente und nachvollziehbare Validierung unabhängig davon, welche öffentliche oder private Zertifizierungsstelle ein bestimmtes Zertifikat ausstellt, und vermeidet den Neuaufbau des Workflows bei der Konsolidierung von Zertifizierungsstellen oder Cloud-Anbietern.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI/Zertifikatsteam	Besitzt das Zertifikatsinventar und die Beziehungen zu Zertifizierungsstellen.	Ermitteln Sie, welche Domänen für die dauerhafte DCV in Frage kommen, und ordnen Sie die Einführung nach Risiko (SAN/Wildcard zuerst).
Sicherheits Team	Besitzt Anmeldeinformationen und Schlüsselschutz	Behandeln Sie ACME-Kontoschlüssel hinter persistenten Datensätzen als sensible Zugangsdaten; überwachen Sie sie auf unautorisierte Änderungen.
Plattform-/Infrastrukturteam	Besitzt Zugangsdaten für den DNS-Anbieter und die API.	Gewähren und Rotieren von DNS-API-Zugangsdaten mit Gültigkeitsbereich; Verbinden jedes Anbieters mit der Lebenszyklusplattform
Compliance-Team	Besitzt Prüfungsnachweise für regulierte Rahmenwerke	Stellen Sie sicher, dass die DCV- und Steckverbinderaktivitäten protokolliert, gespeichert und den DORA-, NIS2- oder FedRAMP/CMMC-Kontrollanforderungen zugeordnet werden.

Erfolgskennzahlen, die nach der Implementierung verfolgt werden sollten

Erfassen Sie diese Kennzahlen vor und nach der Einführung, damit die Auswirkungen der Automatisierung messbar und nicht nur vermutet werden können. Sofern Ihnen reale Zahlen aus Ihrer eigenen Umgebung vorliegen, berichten Sie diese vierteljährlich und nicht als einmaligen Wert.

• Zeitersparnis bei der Erneuerung pro Zertifikat, Vergleich der manuellen DNS-Koordination mit der durch den Connector gesteuerten Validierung.
• Anzahl der Zertifikate im Rahmen der geplanten, CA-unabhängigen DCV-Automatisierung, als Prozentsatz des gesamten öffentlichen TLS-Vermögens.
• Reduzierung manueller DNS-Änderungstickets eingereicht zum Zwecke der Zertifikatsvalidierung.
• Ausfälle oder Beinahe-Ausfälle im Zusammenhang mit Zertifikaten, vierteljährlich im Vergleich zum Ausgangswert vor der Automatisierung.
• Bereitstellungszeit zur Einbindung eines neuen DNS-Anbieters oder einer neuen Domain in den automatisierten Workflow.

Wir haben hier keine konkreten internen Vergleichswerte für diese Metriken angegeben, da wir lieber verifizierte Zahlen aus einem abgeschlossenen Rollout als Schätzungen veröffentlichen möchten. Wenn Sie diese Daten intern erfassen, unterstützt Sie unser PKI-Services-Team gerne bei der Festlegung von Ausgangswerten und der Berichterstattung.

Was macht man als nächstes

• PKI-Teams: Führen Sie jetzt einen Erkennungsdurchlauf durch und kennzeichnen Sie alle Zertifikate, die nach dem 15. März 2026 ablaufen, für eine prioritäre Migration.
• Sicherheitsteams: Fügen Sie ACME-Kontoschlüssel zu Ihrem bestehenden Geheimnisüberwachungsprogramm hinzu, bevor Sie persistentes DCV in großem Umfang einführen.
• Plattformteams: Beantragen Sie in diesem Quartal Zugriff auf die DNS-Provider-API, damit die Konnektor-Integration später nicht durch eine Verzögerung bei der Authentifizierung blockiert wird.
• Compliance-Teams: Prüfen Sie, ob Ihr Audit-Framework bereits automatisierte DCV-Protokolle als Nachweis akzeptiert, oder weisen Sie jetzt auf die bestehende Lücke hin.

CertSecure Manager v3.3: CA-unabhängige DNS-01-Automatisierung

CertSecure Manager ist die herstellerneutrale Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting. Dank ihres CA-agnostischen Designs ermittelt, stellt aus, erneuert und verwaltet eine einzige Steuerungsebene Zertifikate über alle von einer Organisation genutzten Zertifizierungsstellen hinweg. Gültigkeits- und Validierungsänderungen werden somit zentral und nicht für jede Zertifizierungsstelle einzeln gehandhabt. Fällt ein Zertifikat aus, kann es von einer anderen Zertifizierungsstelle neu ausgestellt werden.

Diese Neutralität ist besonders auf der Ebene der öffentlichen Vertrauenszertifizierungsstellen von Bedeutung, da hier die 47-Tage-Frist die größten Auswirkungen hat. CertSecure Manager integriert sich nativ mit den wichtigsten Anbietern öffentlicher Vertrauenszertifizierungsstellen, darunter DigiCert , GlobalSign , Sectigo, Let's Encrypt und Google Public CA, sowie mit privaten Zertifizierungsstellen wie Microsoft AD CS, AWS Private CA und HashiCorp Vault. Unabhängig davon, welche öffentliche Zertifizierungsstelle ein Zertifikat ausstellt, werden Erkennung, Ausstellung, Verlängerung und Validierung über dieselbe Konsole gesteuert. Diese entspricht exakt den oben beschriebenen Bildschirmen für die DNS-Anbieterintegration und die geplante DCV-Prüfung.

Für Organisationen, die die DNS-01-Validierung verwalten oder automatisieren möchten, ist CertSecure Manager v3.3 genau für diesen Übergang konzipiert. Encryption Consulting unterstützt Teams aktiv dabei:

• Binden Sie Ihre öffentlichen DNS-Anbieter ein, indem Sie die Anbieter verbinden, die Ihre DNS-Zonen hosten. Dadurch werden DNS-01-Challenge-Einträge programmatisch über eine Vielzahl von Anbietern hinweg erstellt und verifiziert. Dies entfällt die manuelle Übergabe zwischen Zertifikats- und DNS-Teams.
• Verwalten Sie die Domänenvalidierung (DCV) durch geplante Automatisierung, indem Sie wiederkehrende Domänenvalidierungen durchführen, die auf den Erneuerungszyklus von 100-Tage- und 47-Tage-Zertifikaten abgestimmt sind, sodass die DNS-01-Nachweise ohne Eingriff pro Zyklus aktuell bleiben.
• Die Validierung bleibt CA-unabhängig, indem unabhängig davon, welche öffentliche Zertifizierungsstelle das Zertifikat ausstellt, dieselbe DNS-01-Automatisierung angewendet wird, sodass bei einer Konsolidierung oder einem Wechsel des Anbieters der Validierungsworkflow nicht neu aufgebaut werden muss.
• Entwickeln Sie automatisierungsfähige Arbeitsabläufe im gesamten Unternehmen durch kontinuierliche Erkennung, Durchsetzung von Richtlinien und Zero-Touch-Erneuerungsagenten, damit Erneuerungen im Maschinentempo nicht zu einem proportionalen manuellen Aufwand führen.

Ziel ist das Betriebsmodell, das dem neuen Zeitplan zugrunde liegt: Die Domainvalidierung wird als koordiniertes, automatisiertes System behandelt und nicht als einmalige Aufgabe bei jeder Verlängerung. Durch frühzeitiges Engagement in Form von Bestandsaufnahme, DNS-Provider-Onboarding und geplanter DCV-Automatisierung erhalten die Teams einen priorisierten Fahrplan, lange bevor die verbindlichen Schwellenwerte in Kraft treten.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist Spezialist für angewandte Kryptografie und PKI. Neben der Bereitstellung von CertSecure Manager unterstützt unsere PKI-Services-Abteilung Unternehmen bei der durchgängigen Umsetzung der Umstellung auf kürzere Zertifikatslebensdauern – von der ersten Bestandsaufnahme bis zur vollautomatisierten, CA-unabhängigen Domänenvalidierung. Wir helfen Teams dabei:

• Prüfen Sie die Bereitschaft zur Ausstellung des TLS-Zertifikats innerhalb von 47 Tagen. Ermitteln Sie jedes öffentlich vertrauenswürdige Zertifikat, decken Sie die Lücken in der Zertifikatserkennung auf, die zu stillen Ausfällen führen, und erstellen Sie einen priorisierten Migrationsfahrplan für die Meilensteine ​​von 2026 bis 2029.
• Automatisierte DNS-01-Validierung. Binden Sie Ihre öffentlichen DNS-Anbieter ein und richten Sie eine zeitgesteuerte, CA-unabhängige Domainvalidierung ein, einschließlich persistenter DCV (DNS-PERSIST-01) für etablierte Domains, damit Verlängerungen von manuellen DNS-Arbeiten entkoppelt werden.
• CertSecure Manager bereitstellen und integrieren. Richten Sie die Plattform über Ihre öffentlichen und privaten Zertifizierungsstellen hinweg ein, mit Erneuerungsagenten für die automatische Erneuerung auf Webservern, Load Balancern und internen Anwendungen.
• PKI entwerfen und betreiben. Dies umfasst PKI-Design und -Implementierung sowie verwaltete Optionen durch PKI-as-a-Service und HSM-as-a-Serviceeinschließlich des Schutzes der ACME-Kontoschlüssel, die durch persistentes DCV sicherheitskritisch werden.
• Krypto-Agilität und PQC-Bereitschaft aufbauen. Dies bedeutet CA/Browser-Forum-Konformität, RFC-konforme Validierung und Post-Quanten-Bereitschaft, die auf unserer Technologie aufbaut. PQC Kompetenzzentrum und 9-phasig PQC-Bereitschaft Fahrplan, untermauert durch ein lebendiges CBOM Secure Erstellen Sie ein Inventar aller kryptografischen Vermögenswerte in Ihrem Portfolio, damit die von Ihnen jetzt eingerichtete Automatisierung auch beim nächsten Übergang erhalten bleibt. Unser CBOM: Von der Bestandsaufnahme zur Intelligenz Der Leitfaden führt Sie Schritt für Schritt durch die Umwandlung dieses Inventars in ein umsetzbares Krypto-Agilitätsprogramm.

Um Ihren Zertifikatsbestand anhand des 47-Tage-Zeitraums zu bewerten und eine Roadmap für die DNS-01-Automatisierung zu erstellen, wenden Sie sich an das PKI-Services-Team von Encryption Consulting.

Weiterführende Lektüre von Encryption Consulting

Weiterführende Informationen zu den oben genannten Fristen, Protokollen und Automatisierungsmaßnahmen:

• Das Mandat des CA/Browser-Forums behandelt die Gültigkeitsreduzierungen, die Frist für die duale EKU im Juni 2026 und die damit verbundenen Anforderungen.
• Öffentliches CA vs. privates CA erklärt, wann man welches Tool verwendet und wie man eine Automatisierung für den 47-Tage-Zeitraum aufbaut.
• Auswahl eines Zertifikatsanmeldeprotokolls Vergleicht ACME, EST, SCEP und CMP für kurzlebige Zertifikate.
• Was ist das ACME-Protokoll? erklärt, wie die Challenge-Response-Validierung, einschließlich DNS-01, tatsächlich funktioniert.
• ACME-Clients unter Linux behandelt Certbot, acme.sh, die Abdeckung von DNS-Anbietern und die Frage, wo eine zentrale Governance ihren Platz hat.
• Skalierung des Zertifikatslebenszyklus durch Automatisierung zeigt, wie man häufige Vertragsverlängerungen in einen ereignisgesteuerten, automatisierten Prozess umwandelt.
• CertSecure Manager v3.3 beschreibt detailliert, was die neue Version für die höhere Erneuerungsfrequenz bietet.
• Zentralisierung der Ausstellung von Let's Encrypt- und DNS-01-Zertifikaten mit CertSecure Manager Umfasst die DNS-01-Challenge-Validierung über alle öffentlichen DNS-Anbieter hinweg, zentral gesteuert.
• Leitfaden zur Migration der Post-Quanten-Kryptographie (9 Phasen) legt den Fahrplan für die Algorithmusumstellung dar, die auf die aktuellen Änderungen der Zertifikatslebensdauer und -validierung folgt.
• Wie man ein kryptografisches Inventar (CBOM) erstellt erweitert die in diesem Artikel beschriebene Erkennungsdisziplin von TLS-Zertifikaten auf Ihren gesamten kryptografischen Bestand.
• CBOM: Von der Bestandsaufnahme zur intelligenten Analyse zeigt, wie man ein kryptografisches Inventar in ein fortlaufendes Programm zur Krypto-Agilität und PQC-Bereitschaft umwandelt.

Fazit

Die Entwicklung ist festgelegt. Bis 2029 werden öffentliche TLS-Zertifikate 47 Tage gültig sein und die Domainvalidierungsnachweise alle 10 Tage ablaufen. Dadurch wird aus einer ehemals jährlichen Formalität eine kontinuierliche Aufgabe. Manuelle DNS-Aktualisierungen und E-Mail-basierte Validierung können mit diesem Tempo nicht mithalten. Persistente DCV (DNS-PERSIST-01) beseitigt die DNS-Änderung bei jeder Verlängerung für etablierte Domains, und DNS-Konnektoren automatisieren die verbleibenden Änderungen. So kann die Domainvalidierung mit der Ausstellungshäufigkeit skalieren, anstatt daran zu scheitern.

Organisationen, die diesen Übergang reibungslos gestalten, sind diejenigen, die sich vor Inkrafttreten der Schwellenwerte vorbereiten. Sie inventarisieren ihre Infrastruktur, integrieren ihre DNS-Anbieter und stellen die Domainvalidierung auf eine zeitgesteuerte, CA-unabhängige Automatisierung um – solange 200-Tage-Zertifikate noch Spielraum für Anpassungen bieten. Die Domainvalidierung entwickelt sich zu einer Hintergrundinfrastruktur; die Herausforderung besteht nun darin, einen reibungslosen Betrieb bis zum Stichtag 2027 zu gewährleisten.

Dieser Beitrag wird vierteljährlich gemäß den aktiven Richtlinien des CA/Browser Forum SC-081v3 und SC-088v3 überprüft und sofort aktualisiert, sobald das CA/Browser Forum die Wiederverwendungszeiträume von DCV ändert, neue persistente DCV-Anforderungen hinzufügt oder ein wichtiger DNS-Anbieter das API-Authentifizierungsverhalten ändert.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus diesem Leitfaden zu persistenten DCV- und DNS-Konnektoren?

Die Gültigkeit öffentlicher TLS-Zertifikate verkürzt sich bis März 2029 auf 47 Tage. Dies erfordert, dass die Domaininhaberschaft pro Domain etwa 35 Mal jährlich neu nachgewiesen werden muss. Persistent DCV (DNS-PERSIST-01) reduziert den DNS-Aufwand bei jeder Verlängerung für etablierte Domains, indem ein einziger statischer TXT-Eintrag verwendet wird. DNS-Konnektoren automatisieren die verbleibenden DNS-Änderungen. Zusammen ermöglichen sie, dass die Domainvalidierung mit der Ausstellungshäufigkeit skaliert und nicht zum nächsten Engpass wird.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig?

Das Zertifikatslebenszyklusmanagement leidet bereits jetzt unter mangelnder Transparenz: Laut einer Studie von DigiCert aus dem Jahr 2026 verfügen nur 34 % der Unternehmen über einen vollständigen und aktuellen Überblick über ihre Zertifikate. Da sich die Erneuerungshäufigkeit bis 2029 verachtfachen wird, erhöht sich das Risiko verpasster Erneuerungen und Ausfälle bei jedem manuellen Validierungsschritt, insbesondere bei der DNS-Koordination, proportional, sofern dieser nicht im Vorfeld automatisiert wird.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich?

Vier Teams teilen sich diese Aufgaben typischerweise: Das PKI- oder Zertifikatsteam ist für das Inventar und die Beziehungen zu Zertifizierungsstellen zuständig, das Plattform- oder Infrastrukturteam für den DNS-Provider-Zugriff und die Konnektor-Integration, das Sicherheitsteam für den Schutz der ACME-Kontoschlüssel, auf denen die persistente DCV basiert, und das Compliance-Team stellt sicher, dass die automatisierten Validierungsaktivitäten zu Prüfungszwecken protokolliert werden. Die obige Verantwortlichkeits-/Aufgabenmatrix veranschaulicht dies im Detail.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die Trust Pulse-Umfrage von DigiCert ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten verzeichneten, wobei 37.5 % direkt auf ein abgelaufenes Zertifikat zurückzuführen waren; über die Hälfte dieser Vorfälle verursachten Ausfallzeiten von 5 bis 24 Stunden. Die manuelle DNS-Koordination ist die häufigste Fehlerquelle, da die Validierung nun alle paar Wochen statt einmal jährlich wiederholt werden muss. Eine einzige versäumte oder verzögerte DNS-Änderung kann nämlich dazu führen, dass die Erneuerung selbst fehlschlägt.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen?

Die Automatisierung beseitigt die manuelle Übergabe, die Ticketwarteschlange und das Genehmigungsfenster, die heute im DNS-Prozess erforderlich sind. Persistente DCV eliminiert den DNS-Schritt für etablierte Domains vollständig, und DNS-Konnektoren führen alle verbleibenden DNS-Änderungen über die API des Anbieters innerhalb von Minuten statt Stunden oder Tagen durch. Da die Verlängerung nicht mehr von einer manuellen DNS-Änderung abhängt, wird die häufigste Fehlerursache für Zertifikatsausfälle beseitigt.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Erfassen Sie die pro Zertifikat eingesparte Erneuerungszeit, den Anteil der öffentlichen TLS-Server, der durch die automatisierte, CA-unabhängige DCV-Prüfung abgedeckt wird, die Reduzierung manueller DNS-Änderungstickets, zertifikatsbedingter Ausfälle oder Beinahe-Ausfälle im Vergleich zum Ausgangswert vor der Automatisierung sowie die Bereitstellungszeit für die Integration neuer DNS-Anbieter oder Domains. Berichten Sie diese Daten vierteljährlich, um den Trend und nicht nur eine Momentaufnahme zu erfassen und die Wirksamkeit der Automatisierung bei steigender Erneuerungshäufigkeit zu beurteilen.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Der Zeitplan des CA/Browser Forums für die Abstimmung SC-081v3 verkürzt die maximale Gültigkeitsdauer von TLS-Zertifikaten auf 200 Tage am 15. März 2026, 100 Tage am 15. März 2027 und 47 Tage am 15. März 2029. Gleichzeitig werden die Wiederverwendungszeiträume für DCV auf 10 Tage reduziert. Persistente DCV- und DNS-Konnektoren ermöglichen es, diese Fristen ohne proportionalen Anstieg des manuellen DNS-Aufwands einzuhalten.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Nutzen Sie eine CA-unabhängige Zertifikatslebenszyklusplattform wie CertSecure Manager, die unabhängig von der ausstellenden öffentlichen oder privaten Zertifizierungsstelle und dem Host der DNS-Zone dieselbe geplante DCV- und DNS-Connector-Logik anwendet. Dadurch entfällt die Notwendigkeit, den Validierungsworkflow jedes Mal neu zu erstellen, wenn ein Zertifikat von einer anderen Zertifizierungsstelle neu ausgestellt oder eine DNS-Zone zwischen Anbietern verschoben wird – ein häufiges Problem in Multi-Cloud- und Hybrid-PKI-Umgebungen.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Sie benötigen ein aktuelles, mit Inhabern versehenes Zertifikatsinventar; API-Zugangsdaten mit Schreibzugriff auf TXT-Einträge für jeden verwendeten DNS-Anbieter; eine Bestätigung, welche ausstellenden Zertifizierungsstellen DNS-PERSIST-01 aktuell unterstützen; einen benannten Inhaber für die automatisierte Genehmigung von DNS-Änderungen; und eine Zertifikatslebenszyklusplattform, die wiederkehrende DCV-Prüfungen planen und DNS-Connector-Aufrufe ausführen kann. Die oben stehenden Voraussetzungen beschreiben jeden dieser Punkte detailliert.

Welche häufigen Fehler sollten Teams vermeiden?

Die häufigsten Fehler: Veröffentlichung eines persistenten Eintrags unter dem falschen ACME-Konto (die Diskrepanz der Account-URI führt dazu, dass die Zertifizierungsstelle den Eintrag stillschweigend ablehnt); fehlende Überwachung des _validation-persist-Eintrags auf unautorisierte Änderungen (ein dauerhafter Eintrag ist ein wichtigeres Ziel als ein Eintrag, der bei jeder Erneuerung aktualisiert wird); fehlende Propagation-Prüfung eines neu geschriebenen TXT-Eintrags vor der Auslösung der Ausstellung (die DNS-Propagation-Verzögerung führt dazu, dass die MPIC-basierte Multi-Perspektiven-Prüfung der Zertifizierungsstelle in einer Region fehlschlägt); und fehlende regelmäßige Rotation der Anmeldeinformationen für die DNS-Connector-API (abgelaufene Anmeldeinformationen führen beim nächsten geplanten Lauf zu einem stillschweigenden Fehler, nicht erst zum Zeitpunkt ihres Ablaufs).

Was sollte vierteljährlich für die DCV-Automatisierungs-Governance aktualisiert werden?

Vierteljährlich: Sicherstellen, dass alle persistenten Einträge korrekt aufgelöst werden und mit autorisierten ACME-Konten übereinstimmen; Anmeldeinformationen der DNS-Connector-API rotieren und testen; Protokolle fehlgeschlagener Connector-Aufrufe des Vorquartals prüfen; neu hinzugefügte Domains seit der letzten Überprüfung auf die Abdeckung persistenter Einträge prüfen; CA/Browser Forum SC-081v3 und SC-088v3 auf Aktualisierungen der DCV-Wiederverwendungszeiträume oder Anforderungen an persistente Einträge überprüfen; und die PQC-Bereitschaftsplanung für ACME-Schlüsselalgorithmen über das PQC Center of Excellence bestätigen . Dieser Beitrag wird gemäß dem aktuellen Richtlinienplan des CA/Browser Forums vierteljährlich überprüft.