DNS-validatie automatiseren met CertSecure Manager: Permanente DCV- en DNS-connectoren

Een certificaat dat voorheen jaarlijks werd verlengd, moet nu ongeveer elke vijf tot zes weken opnieuw worden gevalideerd, en tegen maart 2029 wordt die frequentie zelfs elke 47 dagen. Persistent DCV (DNS-PERSIST-01) en DNS-connectoren zijn de twee beheermechanismen die ervoor zorgen dat de domeinvalidatie gelijke tred houdt: persistent DCV maakt het mogelijk om een ​​domein opnieuw te verifiëren aan de hand van één enkel DNS TXT-record dat eenmaal is gepubliceerd, en DNS-connectoren automatiseren de resterende DNS-wijzigingen, zodat certificaatteams kunnen voldoen aan het steeds korter wordende geldigheidsschema van het CA/Browser Forum zonder dat er bij elke verlenging handmatig DNS-werk nodig is.

Deze handleiding beschrijft wat elke functionaliteit doet, de exacte deadlines voor de wijziging, de vereisten en de stapsgewijze workflow voor de implementatie, de teams die verantwoordelijk zijn voor de uitvoering ervan, en de meetgegevens die aantonen of de automatisering daadwerkelijk werkt.

Kort antwoord: Wat zijn persistente DCV- en DNS-connectoren?

Persistent DCV (DNS-PERSIST-01) stelt een domeineigenaar in staat om één TXT-record te publiceren op _validation-persist.[domein] dat een CA automatisch opnieuw controleert bij elke verlenging, waardoor DNS-werkzaamheden per verlenging overbodig worden. DNS-connectoren automatiseren de resterende DNS-wijzigingen via de API van de provider. Samen zijn ze nodig om de 47-daagse TLS-validiteitstermijn van het CA/Browser Forum (maart 2029, stemming SC-081v3) te handhaven zonder evenredige handmatige inspanning.

Key Takeaways

• Het voorstel SC-081v3 van het CA/Browser Forum verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 200 dagen op 15 maart 2026, 100 dagen op 15 maart 2027 en 47 dagen op 15 maart 2029, waarbij de hergebruiksperioden van DCV's volgens hetzelfde schema worden verkort tot 10 dagen.
• Persistent DCV (DNS-PERSIST-01), toegestaan ​​sinds november 2025 onder stemming SC-088v3, maakt het mogelijk om een ​​domein opnieuw te valideren aan de hand van één TXT-record dat eenmaal is gepubliceerd, waardoor DNS-werkzaamheden bij elke verlenging volledig overbodig worden voor bestaande domeinen.
• DNS-connectoren automatiseren de resterende DNS-wijzigingen, waaronder nieuwe domeinen en de initiële configuratie, door rechtstreeks met de API van de DNS-provider te communiceren in plaats van via een handmatig ticket.
• Uit het Trust Pulse-onderzoek van DigiCert (2 juli 2025) bleek dat 45% van de bedrijven het afgelopen jaar te maken had met uitval als gevolg van certificaatproblemen, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat.
• De PKI-, beveiligings-, platform- en compliance-teams zijn elk verantwoordelijk voor een specifiek onderdeel van deze uitrol; de onderstaande matrix met verantwoordelijkheden en taken en de checklist met vereisten geven precies aan wie wat doet.

Ga naar: Samenvatting | Implementatieworkflow | Matrix van vereisten naar acties | Matrix van eigenaren/acties | Successtatistieken | CertSecure Manager v3.3 | Veelgestelde vragen

Voor wie zijn persistente DCV- en DNS-connectoren relevant?

De operationele gevolgen van het schema voor de verkorting van de geldigheidsduur van certificaten door het CA/Browser Forum treffen tegelijkertijd certificaatteams, DNS-teams, beveiligingsarchitecten, platformengineers en compliance-afdelingen. Elk van deze teams heeft een eigen zwak punt. Een certificaatteam dat de verlenging automatiseert, maar niet de DNS-validatie, loopt alsnog tegen problemen aan wanneer de DCV-hergebruiksperiode afloopt. Een DNS-team dat API-toegang verleent, maar de rotatie van connectorreferenties niet controleert, creëert een stille foutmodus. Bij een geldigheidsduur van 47 dagen vanaf maart 2029 leidt elke onderbreking tot verlengingsfouten die acht keer zo vaak voorkomen als vóór 2029.

Rol	Waarom het uitmaakt	Actie-item
PKI- en certificeringsteams	Beheer de certificaatinventaris en de CA-relaties; identificeer welke domeinen in aanmerking komen voor permanente DCV en sorteer de uitrol op risico (eerst SAN- en wildcarddomeinen, omdat deze de hoogste coördinatiekosten met zich meebrengen); uit DigiCert's Trust Pulse Survey (2 juli 2025) bleek dat 45% van de bedrijven het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaatproblemen, en dat bij een geldigheidsduur van 47 dagen elke handmatige validatiefout acht keer vaker tot een storing leidt dan voorheen; slechts 34% van de organisaties heeft een volledig en actueel overzicht van hun certificaten (DigiCert PKI Under Pressure-rapport, 2 juni 2026), waardoor het verkrijgen van inzicht de voorwaarde is die alle andere stappen mogelijk maakt.	Voer een volledige certificaatdetectie uit met CertSecure Manager om een ​​inventaris op te bouwen van elk openbaar vertrouwd certificaat en de bijbehorende SAN-lijst, voorzien van eigenaarlabels; gebruik CBOM Secure Om de ontdekking uit te breiden van TLS-certificaten naar het volledige cryptografische landschap; prioriteit geven aan SAN- en wildcarddomeinen voor permanente DCV-onboarding; bevestigen welke uitgevende CA's DNS-PERSIST-01 al ondersteunen en conventionele DNS-01 met connectors gebruiken voor degenen die dat nog niet doen.
Platform- en infrastructuurteams	Eigen DNS-providertoegang en API-referentiebeheer is een essentiële voorwaarde voor het onboarden van connectors; het traagste onderdeel van DNS-gebaseerde validatie is meestal niet de DNS-lookup zelf, maar de overdracht tussen de certificaat- en DNS-teams; een verlenging die mislukt omdat een DNS-wijzigingsticket niet tijdig is verwerkt, leidt tot precies de storingen die DigiCert in juli 2025 in een onderzoek heeft gemeten; API-referenties voor connectors moeten correct worden afgebakend, volgens schema worden vernieuwd en proactief worden getest, in plaats van pas te ontdekken dat ze verlopen zijn wanneer een verlenging mislukt.	Vraag om API-referenties met schrijftoegang tot TXT-records voor elke gebruikte DNS-provider (Route 53, Cloudflare, Azure DNS, Google Cloud DNS en alle andere); verbind elke provider met CertSecure Manager Gebruik de DNS-connectorintegratie; test of een schrijf-, validatie- en verwijdercyclus van een TXT-record programmatisch wordt voltooid zonder ticket voordat een productiecertificaat ervan afhankelijk is; plan een driemaandelijkse rotatie van referenties in en test elke connector na de rotatie om te bevestigen dat deze nog steeds succesvol records schrijft;
Beveiligingsarchitecten	Beheer het model voor authenticatie en monitoring dat persistente DCV beveiligt in plaats van een nieuw, permanent aanvalsoppervlak te creëren; persistente DCV verschuift de te beschermen asset van DNS-schrijftoegang (die bij elke verlenging beschikbaar moet zijn) naar de ACME-accountsleutel (die alleen nodig is om het persistente record in te stellen); een gecompromitteerde of niet-gemonitorde ACME-accountsleutel die een persistent record ondersteunt, kan certificaatuitgifte voor een bestaand domein autoriseren zonder een DNS-wijzigingswaarschuwing te activeren; het _validation-persist-record zelf moet worden gemonitord op ongeautoriseerde wijzigingen.	Voeg ACME-accountsleutels die persistente DCV-records ondersteunen toe aan het bestaande programma voor geheimbeheer en -rotatie van de organisatie voordat persistente DCV op grote schaal wordt geïmplementeerd; configureer monitoringwaarschuwingen op het _validation-persist TXT-record voor elk domein, zodat elke onverwachte wijziging een onderzoek activeert; definieer het reactieplan voor ongeautoriseerde persistente records (deactiveer het ACME-account volgens RFC 8555 Sectie 7.5.2 om de uitgifteautorisatie onmiddellijk in te trekken); plan de PQC-gereedheid voor ACME-sleutelalgoritmen via de PQC Centrum van Uitmuntendheid en PQC-gereedheid diensten
Compliance	Er moet worden bevestigd dat geautomatiseerde DCV- en DNS-connectoractiviteiten worden gelogd en controleerbaar zijn voor gereguleerde frameworks; DORA, NIS2, FedRAMP en CMMC vereisen elk bewijs van wie welk domein heeft gevalideerd en wanneer; geautomatiseerde processen die geen auditspoor achterlaten, voldoen net zo zeker niet aan deze eis als handmatige processen; het CA/Browser Forum SC-081v3-schema (47 dagen geldig tot maart 2029) betekent ook dat bewijs voor naleving van DCV acht keer zo vaak moet worden geproduceerd als vóór 2029, waardoor het verzamelen van handmatig auditbewijs onhoudbaar wordt om dezelfde reden dat handmatige validatie onhoudbaar is.	Bevestig dat het certificaatlevenscyclusplatform elke DCV-gebeurtenis (domein, methode, tijdstempel, CA-account, resultaat) registreert met voldoende details voor auditbewijs; koppel DCV- en connectoractiviteitenlogboeken aan de toepasselijke frameworkcontrolevereisten (DORA Artikel 9, NIS2 Artikel 21, FedRAMP SC-12, CMMC Practice CM.L2-3.4.2); vereis dat de bewaartermijn van logboeken voldoet aan de frameworkvereisten voordat DCV volledig geautomatiseerd wordt; evalueer PKI als een service voor organisaties waar beheerde PKI-bewerkingen ingebouwde auditregistratie voor DCV-activiteit omvatten
CISO's	Certificaatstoringen veroorzaakt door gemiste validaties zijn operationeel gelijk aan storingen door verlopen certificaten, maar moeilijker te diagnosticeren omdat het certificaat geldig en vertrouwd lijkt, maar niet kan worden verlengd. Uit DigiCert's Trust Pulse Survey (2 juli 2025) bleek dat 37.5% van de certificaatgerelateerde storingen te wijten was aan een verlopen certificaat, en dat meer dan de helft leidde tot 5 tot 24 uur downtime met financiële verliezen tussen $ 50,000 en $ 250,000 bij 31% van de getroffen organisaties. Het schema voor de vermindering van de geldigheidsduur van certificaten door de CA/Browser Forum is vastgesteld, ongeacht de gereedheid van de organisatie. Investeringen in automatisering vóór 2026 zijn daarom eerder een risicoverminderende beslissing dan een optionele upgrade.	Financier de uitrol van permanente DCV- en DNS-connectoren als een investering in het verminderen van operationele risico's vóórdat de drempelwaarden van maart 2026 en maart 2027 van kracht worden; vereis dat de dekking van certificaatautomatisering (percentage van het openbare TLS-netwerk onder geplande CA-onafhankelijke DCV) kwartaallijks als een KPI op bestuursniveau wordt gerapporteerd; verplicht dat de bescherming van ACME-accountsleutels wordt opgenomen in de evaluatie van het programma voor geheimbeheer; evalueer PKI als een service Voor organisaties die een beheerde certificaatlevenscyclus nodig hebben met ingebouwde DCV-automatisering en DNS-connectordekking.

Samenvatting voor leidinggevenden op het gebied van beveiliging, PKI, platformen en compliance

Als u een van deze functies leidt, is dit de beslissing die in dit artikel wordt ondersteund, samen met een handige checklist om deze in de praktijk te brengen.

• PKI/certificaatteams: Inventariseer het openbare TLS-domein, identificeer welke domeinen in aanmerking komen voor permanente DCV en geef prioriteit aan SAN- en wildcarddomeinen voor de onboarding.
• Beveiligingsteams: Beschouw de ACME-accountsleutel achter een persistent record als een gevoelige referentie en voeg het risico op certificaatuitval toe aan dezelfde monitoringlaag als andere beschikbaarheidsrisico's.
• Platform-/infrastructuurteams: Verbind DNS-providers met het certificaatlevenscyclusplatform via API-gebaseerde connectoren, zodat DNS-wijzigingen niet langer hoeven te wachten op een wijzigingsbeheerticket.
• Nalevingsteams: Bevestig dat de geautomatiseerde DCV- en DNS-connectoractiviteit wordt gelogd en controleerbaar is, aangezien gereguleerde omgevingen (DORA, NIS2, FedRAMP, CMMC) bewijs vereisen van wie wat wanneer heeft gevalideerd.

De deadlines die de verandering aandrijven

In april 2025 keurde het CA/Browser Forum stemvoorstel SC-081v3 goed , getiteld "Introduce Schedule of Reducing Validity and Data Reuse Periods", met 29 stemmen voor en geen tegen. Het voorstel, oorspronkelijk ingediend door Apple, beschrijft een gefaseerde reductie van zowel de maximale levensduur van publiekelijk vertrouwde TLS-certificaten als de periode waarin validatiegegevens opnieuw kunnen worden gebruikt. Elk publiekelijk vertrouwd TLS-certificaat wordt hierdoor beïnvloed, ongeacht of het om DV-, OV- of EV-certificaten gaat, inclusief wildcard- en multi-domeincertificaten (SAN-certificaten). Sectigo's eigen analyse van het voorstel van 14 april 2025 beschrijft hetzelfde schema als een stapsgewijze ontwikkeling, geen abrupte verandering, richting geautomatiseerd, quantum-compatibel certificaatbeheer.

Ingangsdatum	Maximale TLS-geldigheid	DCV-hergebruikperiode	SII-hergebruik (OV/EV)
Tot en met 14 maart 2026	398 dagen	398 dagen	825 dagen
15 maart 2026	200 dagen	200 dagen	398 dagen
15 maart 2027	100 dagen	100 dagen	398 dagen
15 maart 2029	47 dagen	10 dagen	398 dagen

De geldigheidsduur en de limieten voor hergebruik van DCV gelden vanaf de datum waarop een certificaat wordt uitgegeven, niet vanaf de datum waarop een bestelling wordt geplaatst.

De periode waarin Subject Identity Information (SII) voor OV- en EV-certificaten opnieuw gebruikt mag worden, daalt van 825 naar 398 dagen op 15 maart 2026. Deze wijziging maakt een einde aan het "instellen en vergeten"-model voor certificaten met een hoge mate van betrouwbaarheid. Voor een volledig overzicht van de gerelateerde mandaten, inclusief de aparte deadline voor Chrome dual-EKU op 15 juni 2026, zie onze analyse van het CA/Browser Forum-mandaat . Dezelfde verschuiving heeft ook gevolgen voor de keuze tussen een publieke en een private CA.

Waarom kortere certificaten handmatige domeinvalidatie verstoren

De uitdaging zit hem niet in het certificaat zelf, maar in de frequentie van heruitgifte. Neem bijvoorbeeld een organisatie met 1,000 publiekelijk erkende certificaten. Met een geldigheidsduur van 398 dagen genereert dit aantal certificaten momenteel ongeveer 1,000 verlengingsaanvragen per jaar. Tegen 2029, met een geldigheidsduur van 47 dagen, genereert hetzelfde aantal certificaten meer dan 8,000 verlengingsaanvragen per jaar, een achtvoudige toename van identiek werk.

Validatie wordt hierdoor nog directer beïnvloed. Wanneer de hergebruiksperiode van DCV's wordt verkort tot 10 dagen, terwijl certificaten 47 dagen geldig zijn, moet het domeineigendom per domein ongeveer 35 keer per jaar opnieuw worden bewezen. Validatie via e-mail en eenmalige plaatsing van HTTP-bestanden kunnen niet met die frequentie worden uitgevoerd. De teams die het meest kwetsbaar zijn, zijn degenen die grote domeinportfolio's beheren, SAN-certificaten die veel domeinen onder één validatie samenvoegen, en wildcarddomeinen. Het risico is het grootst wanneer het DNS-eigendom is verdeeld over netwerk-, infrastructuur- en platformteams, en waar elke wijziging wacht op een wijzigingsbeheerticket.

De implicatie is duidelijk. Bij de door machines gestuurde vernieuwingsfrequenties is handmatig certificaatbeheer niet langer haalbaar en wordt certificaatautomatisering de standaard. De vraag is welke vorm van automatisering het meeste operationele risico wegneemt.

De data die de urgentie onderbouwen

De bovenstaande berekening is niet theoretisch. Recent brancheonderzoek kwantificeert precies wat er gebeurt wanneer validatie en verlenging geen gelijke tred kunnen houden met een gecomprimeerd certificaatschema:

• 45% van de bedrijven ondervond het afgelopen jaar serviceonderbrekingen als gevolg van een certificaatgerelateerd incident, en 37.5% kon een storing specifiek herleiden tot een verlopen certificaat., volgens DigiCert's Trust Pulse-enquête, gepubliceerd op 2 juli 2025. Meer dan de helft van de getroffen organisaties ondervond 5 tot 24 uur downtime en 31% meldde financiële verliezen tussen $50,000 en $250,000.
• 72% van de organisaties heeft het afgelopen jaar minstens één storing ondervonden die verband hield met certificaten., volgens CyberArk's Rapport over de stand van zaken rond machine-identiteitsbeveiliging in 2025, waarbij 1,200 veiligheidsfunctionarissen in zes landen werden ondervraagd.
• Slechts 34% van de organisaties heeft een volledig en actueel overzicht van hun digitale certificaten.En bijna 75% is zeer of extreem bezorgd over storingen die worden veroorzaakt door verlopen certificaten, aldus DigiCert. “PKI onder druk: het omslagpunt voor modernisering” rapport, gepubliceerd op 2 juni 2026, gebaseerd op een enquête onder meer dan 400 senior IT- en beveiligingsleiders.
• Geautomatiseerde, door DNS gevalideerde uitgifte is al de norm.De geautomatiseerde ACME-uitgifte van Let's Encrypt is alleen al goed voor meer dan 60% van alle TLS-certificaten die in gebruik zijn, en meer dan 94% van alle certificaten die tegenwoordig worden uitgegeven, zijn domeingevalideerd, waarvan de meeste direct door geautomatiseerde processen worden uitgegeven (vanaf het eerste kwartaal van 2026).SSLreminder, “State of TLS Q1 2026”).

Permanente DCV- en DNS-connectoren zijn de mechanismen die ervoor zorgen dat domeinvalidatie gelijke tred kan houden met de verschuiving naar volledig geautomatiseerde uitgifte, in plaats van de volgende operationele bottleneck te worden wanneer de verlengingsfrequentie toeneemt.

Wat is domeincontrolevalidatie (DCV)?

Domeincontrolevalidatie is het proces dat een certificeringsinstantie (CA) gebruikt om te bevestigen dat een certificaataanvrager de domeinnaam beheert die in het verzoek wordt genoemd. De basisvereisten van het CA/Browser Forum definiëren verschillende geaccepteerde methoden. De drie meest gebruikte methoden zijn:

• DNS-gebaseerde validatie vereist dat de aanvrager een TXT-record onder het domein publiceert, dat vervolgens door de certificeringsinstantie wordt gecontroleerd. Dit is de enige methode die wildcard-domeinen ondersteunt en soepel schaalbaar is door middel van automatisering.
• HTTP-gebaseerde validatie vereist dat de aanvrager een bestand op een bekend pad op de webserver plaatst. Dit werkt prima voor individuele hosts, maar wordt lastig bij gedistribueerde of load-balanced systemen.
• Validatie via e-mail vereist dat de aanvrager reageert op een bericht dat naar een contactpersoon binnen het domein is gestuurd. Deze methode is afhankelijk van menselijke tussenkomst en wordt geleidelijk vervangen door geautomatiseerde uitgifte.

Voor organisaties die op grote schaal opereren, is DNS-gebaseerde validatie de meest praktische keuze. Het werkt voor wildcards, kan volledig via API's worden aangestuurd en vormt de basis voor de geautomatiseerde uitgifteprotocollen die de nieuwe tijdlijn feitelijk verplicht stelt, met name ACME en de bijbehorende DNS-01-uitdaging. Zowel persistente DCV- als DNS-connectoren bouwen direct voort op deze DNS-gebaseerde basis.

Wat is Persistent DCV (DNS-PERSIST-01)?

Persistent DCV is een op DNS gebaseerde validatiemethode die het aanmaken en verwijderen van een DNS-record voor elke uitgifte overbodig maakt. Het werd toegevoegd aan de Baseline Requirements als sectie 3.2.2.4.22, getiteld "DNS TXT Record with Persistent Value" en algemeen bekend als DNS-PERSIST-01, via stemming SC-088v3 , en werd een toegestane methode in november 2025. Het werd voorgesteld door Amazon Trust Services en onderschreven door onder andere Google Chrome, DigiCert en Sectigo.

Het mechanisme is eenvoudig. In plaats van voor elke validatiegebeurtenis een nieuw, tijdelijk record aan te maken, publiceert de domeineigenaar eenmalig een TXT-record met accountbereik, onder het label _validation-persist.[domein]. Dat record identificeert het CA-account van de aanvrager. Vanaf dat moment voert de CA automatisch terugkerende validatiecontroles uit op hetzelfde record, zonder dat verdere DNS-wijzigingen nodig zijn. Belangrijk is dat persistente DCV de verificatie van domeineigendom niet verzwakt. Het CA/Browser Forum vereist het om een ​​beveiliging te bieden die gelijkwaardig is aan bestaande DNS-gebaseerde methoden. Het verandert wanneer en hoe verificatie plaatsvindt, van gebeurtenisgestuurde controles naar continue, geautomatiseerde hervalidatie. CA's blijven gebonden aan dezelfde hergebruikslimiet van 10 dagen, en persistente DCV betekent dat het onderliggende record nooit opnieuw hoeft te worden opgebouwd om hieraan te voldoen.

Het permanente TXT-recordformaat

Het document zelf codeert wie bevoegd is om de gegevens uit te geven. Een permanent TXT-document heeft de volgende vorm:

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

De recordnaam identificeert het domein; authority noemt de CA; accounturi identificeert het ACME-account dat gemachtigd is om licenties uit te geven (conform RFC 8657, en stabiel tijdens sleutelrotaties onder RFC 8555 Sectie 7.3.5); en de optionele persistUntil stelt een vervaldatum in. De CA controleert vervolgens deze ene record opnieuw bij elke uitgifte.

De operationele besparing is evenredig met de omvang van het domein. Een organisatie die 100 domeinen vier keer per jaar valideert, voert jaarlijks ongeveer 400 DNS-wijzigingen uit met de conventionele DNS-01-methode, vergeleken met 100 eenmalige records met de persistente DCV-methode.

Eén afweging verdient expliciete aandacht. Omdat een permanent record de uitgifte autoriseert, verschuift het te beschermen object van DNS-schrijftoegang naar de ACME-accountsleutel. Beschouw die sleutel als een gevoelige referentie, controleer het permanente record op onverwachte wijzigingen en houd er rekening mee dat de uitgifte onmiddellijk kan worden ingetrokken door het ACME-account te deactiveren (RFC 8555 Sectie 7.5.2).

Traditionele DCV versus aanhoudende DCV

Traditionele DNS-gebaseerde DCV	Permanente DCV (DNS-PERSIST-01)
Voor elke uitgiftegebeurtenis wordt een uniek, tijdelijk TXT-record aangemaakt.	Een enkel persistent TXT-record wordt eenmalig gepubliceerd op _validation-persist.
Het record wordt elke cyclus toegevoegd, gevalideerd en vervolgens verwijderd of geroteerd.	De certificeringsinstantie controleert bij elke uitgifte hetzelfde record opnieuw; er is geen DNS-wijziging nodig.
De DNS-coördinatie wordt bij elke vernieuwing herhaald, wat het zwakke punt is dat toeneemt met de frequentie.	DNS-coördinatie vindt eenmalig plaats tijdens de installatie; verlengingen zijn losgekoppeld van DNS-werkzaamheden.
Het komt 8 keer vaker voor naarmate de geldigheidsduur wordt verkort tot 47 dagen.	De frequentie van uitgifte is niet langer bepalend voor de DNS-werkbelasting.

Wat zijn DNS-connectoren?

Persistente DCV vermindert de frequentie waarmee DNS-wijzigingen nodig zijn; DNS-connectoren verwerken de resterende wijzigingen. Een DNS-connector is een integratie tussen een certificaatlevenscyclusplatform en een DNS-provider, waardoor het platform TXT-records programmatisch kan aanmaken, bijwerken en valideren via de API van de provider, in plaats van dat een DNS-beheerder elke wijziging handmatig moet doorvoeren.

Dit is belangrijk omdat het traagste onderdeel van DNS-gebaseerde validatie meestal niet de DNS-lookup is, maar de overdracht door een medewerker. Een certificeringsteam vraagt ​​een record aan, een netwerkteam plant de wijziging in, een goedkeuringsperiode verstrijkt en pas dan kan de validatie worden voltooid. Bij een jaarlijkse frequentie is die vertraging acceptabel. Bij tientallen validaties per domein per jaar wordt het echter de belangrijkste bron van zowel operationele vertraging als uitvalrisico, omdat een verlenging volledig kan mislukken als het validatierecord niet op tijd aanwezig is. Connectoren elimineren de overdracht: het platform communiceert rechtstreeks met de DNS-provider en het record verschijnt, wordt gevalideerd en beheerd zonder dat er een ticket nodig is.

Hoe persistente DCV- en DNS-connectoren samenwerken

De twee mogelijkheden vullen elkaar aan, ze zijn niet uitwisselbaar. Persistent DCV elimineert DNS-contactmomenten tijdens de verlengingscyclus. DNS-connectoren automatiseren de DNS-wijzigingen die nog steeds nodig zijn, waaronder het publiceren van het initiële persistente record en het onboarden van nieuwe domeinen. Samen bieden ze een team twee verschillende mogelijkheden:

• Wanneer een permanent record kan worden gebruikt, worden DNS-wijzigingen tijdens de vernieuwing volledig geëlimineerd, waardoor de uitgiftefrequentie niet langer bepalend is voor de DNS-belasting.
• Wanneer een DNS-wijziging nog steeds nodig is (nieuwe domeinen, initiële configuratie, providers zonder permanente ondersteuning), voert een connector deze automatisch uit, zonder handmatige tussenkomst.

Het netto-effect is een validatieproces dat soepel meegroeit met zowel het certificaatvolume als de vernieuwingsfrequentie, precies wat de deadlines van 2027 en 2029 vereisen.

DCV-automatisering: vereisten, storingsmodi en bewakingssignalen

Gebruik deze tabel om elke DCV-automatiseringseis te koppelen aan de bijbehorende validatiemethode, de foutmodus wanneer niet aan de eis wordt voldaan, het monitoringsignaal dat de fout aan het licht brengt en de gezaghebbende beleidsbron. CA/Browser Forum SC-081v3 en SC-088v3 worden elk kwartaal herzien en kunnen onafhankelijk van elkaar worden bijgewerkt.

eis	Validatiemethode	Faal modus	Monitoringsignaal	Beleidsbron
Het persistente TXT-record wordt correct opgelost door alle gezaghebbende naamservers.	Query _validation-persist.[domein] bij meerdere DNS-resolvers in verschillende geografische regio's; bevestig dat alle resolvers dezelfde recordwaarde retourneren; test met behulp van openbare DNS-resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1); DNS-validatiecontrole voor het CLM-platform	DNS-propagatievertraging of zone-overdrachtskloof zorgt ervoor dat de validatiecontrole van de CA vanuit één of meerdere perspectieven mislukt; MPIC (CA/Browser Forum SC-067) controleert nu CAA en DCV vanuit meerdere netwerklocaties, waardoor een inconsistentie die vanuit één regio zichtbaar is, de validatie niet doorstaat; de verlenging mislukt zelfs als het record vanuit één enkel gezichtspunt correct lijkt.	CLM-platformwaarschuwing voor DCV-validatiefout voor een domein met een persistent record; certificaatvernieuwingsfout die correleert met DNS-propagatiefouten in CA-logboeken; DNS-monitoringwaarschuwing voor TXT-recordpropagatiefout naar een of meer gezaghebbende naamservers	CA/Browser Forum Stemming SC-088v3 (DNS-PERSIST-01, november 2025); Stemming SC-081v3 (DCV hergebruiksperioden); Stemming SC-067 (MPIC, september 2025)
De API-referenties van de DNS-connector zijn geldig, hebben een specifiek bereik en zijn getest.	Test een cyclus van schrijven, valideren en verwijderen van TXT-records via de connector voordat een productiecertificaat ervan afhankelijk is; bevestig dat de referenties schrijftoegang hebben tot TXT-records, beperkt tot de specifieke zones (niet accountbreed); controleer de vervaldatum van de referenties; plan een kwartaalrotatie en test na de rotatie.	Een connector met alleen-lezen, verlopen of te uitgebreide API-referenties faalt stilzwijgend bij de volgende geplande uitvoering; de DNS-wijziging wordt niet doorgevoerd; de validatiecontrole van de CA vindt geen record; de verlenging mislukt; de fout kan zich voordoen als een DCV-fout in plaats van een referentiefout, waardoor de diagnose trager verloopt.	CLM-platformwaarschuwing bij mislukte connectoroproep; DNS-providerauditlogboek toont mislukte API-authenticatie; piek in mislukte certificaatvernieuwingen gecorreleerd met vervaldatum van inloggegevens; dashboard voor connectorstatuscontrole toont tijdstempel van laatste succesvolle schrijfbewerking	CA/Browser Forum Stemming SC-081v3 (DCV-hergebruikperioden die geautomatiseerde validatie vereisen); documentatie voor authenticatie via de DNS-provider-API; intern beleid voor het roteren van inloggegevens
Het permanente record accounturi komt overeen met het actieve ACME-account voor elke uitgevende CA.	Vergelijk de accounturi-waarde in het _validation-persist TXT-record met de ACME-account-URL die wordt geretourneerd door het account-eindpunt van de CA (RFC 8555 Sectie 7.3); bevestig dat het account actief en niet gedeactiveerd is; test of de CA het persistente record accepteert voor een testuitgifte.	Een persistent record dat is aangemaakt voor een onjuist account (verkeerde CA, gemigreerd account of URL van een geroteerd account) wordt gevalideerd voor de verkeerde CA of helemaal niet; certificaatvernieuwing mislukt; de CA retourneert een DCV-fout die de mismatch in de accounturi niet expliciet vermeldt, waardoor de diagnose traag verloopt.	CLM-platform DCV-validatiefout voor een domein met een persistent record; CA-foutmelding dat het account niet is geautoriseerd of het record niet wordt herkend; CLM-platformwaarschuwing over wijziging van de accounturi-waarde van het persistente record sinds de laatste audit.	CA/Browser Forum Ballot SC-088v3 Sectie 3.2.2.4.22 (vereiste voor het veld accounturi); RFC 8657 (stabiliteit van ACME-accountsleutels bij sleutelrotatie); RFC 8555 Sectie 7.3.5 (stabiliteit van account-URL's bij sleutelrotaties)
Permanente records worden gecontroleerd op ongeautoriseerde wijzigingen.	Configureer DNS-monitoring voor het TXT-record _validation-persist.[domein] dat een waarschuwing geeft bij elke waardeverandering; bevestig dat het monitoringplatform vanuit meerdere geografische locaties controleert; test de waarschuwing door de recordwaarde tijdelijk te wijzigen in een niet-productiezone.	Een ongeautoriseerde wijziging van de permanente record blijft onopgemerkt; de gewijzigde record kan een andere CA- of ACME-account machtigen om certificaten voor het domein uit te geven; omdat de record permanent is in plaats van per verlenging, is de periode van blootstelling continu in plaats van beperkt tot een verlengingscyclus.	DNS-monitoringwaarschuwing bij wijziging van de waarde van het _validation-persist TXT-record; CLM-platformwaarschuwing bij onverwachte CA- of accountwijziging in het persistente record; waarschuwing van een externe DNS-monitoringdienst bij wijziging van het record	CA/Browser Forum Stemming SC-088v3 (vereisten voor permanente recordbeveiliging); RFC 8555 Sectie 7.5.2 (deactivering van ACME-account om uitgifteautorisatie in te trekken); CA/Browser Forum Basisvereisten Sectie 4.9 (verplichtingen inzake intrekking van certificaten)
De DCV-automatisering werkt volgens een schema dat is afgestemd op de vernieuwingscyclus.	Controleer of het CLM-platform is geconfigureerd om domeinvalidatie uit te voeren vóór elke verlenging met een frequentie die binnen het toepasselijke DCV-hergebruikvenster blijft (200 dagen tot en met maart 2027, 100 dagen tot en met maart 2029, 10 dagen vanaf maart 2029); test of DCV automatisch wordt uitgevoerd zonder handmatige trigger; bevestig dat de CA-onafhankelijke planning is ingesteld, zodat dezelfde automatisering van toepassing is, ongeacht welke openbare CA het certificaat uitgeeft.	De DCV-automatisering is niet gepland of is geconfigureerd met een hergebruikvenster dat langer is dan de toepasselijke limiet; het DCV-bewijs van de CA vervalt vóór de volgende verlenging; de CA weigert de certificering uit te geven omdat de domeinvalidatiegegevens verouderd zijn; deze foutmodus komt vaker voor naarmate het hergebruikvenster korter wordt.	CLM-platformwaarschuwing over verlopen DCV-bewijsmateriaal vlak voor de verlengingsdatum; certificaatvernieuwing mislukt vanwege verlopen DCV-bewijsmateriaal in CA-logboeken; CLM-platformdashboard toont domeinen met een DCV-laatst uitgevoerde tijdstempel die ouder is dan de toepasselijke hergebruiksperiode.	CA/Browser Forum Stemming SC-081v3 (DCV-hergebruikperioden: 200 dagen maart 2026, 100 dagen maart 2027, 10 dagen maart 2029); CA/Browser Forum Basisvereisten Sectie 3.2.2.4 (DCV-methodevereisten)

Voorwaarden voordat u begint met implementeren

Controleer of deze aanwezig zijn voordat u permanente DCV- of DNS-connectoren in gebruik neemt, zodat de uitrol niet halverwege vastloopt:

1. Een actuele inventaris van certificaten. Je hebt een lijst nodig, gebaseerd op ontdekkingsinformatie, van alle publiekelijk vertrouwde certificaten en de domeinen die ze dekken, voordat je kunt bepalen welke domeinen in aanmerking komen voor permanente DCV.
2. API-toegang tot elke gebruikte DNS-provider. DNS-connectoren authenticeren zich bij de API van de provider (Route 53, Cloudflare, Azure DNS, Google Cloud DNS en vergelijkbare providers), dus je hebt API-referenties nodig met toestemming om TXT-records te schrijven, beperkt tot de betreffende zones.
3. Een CA-account dat ACME en, indien beschikbaar, DNS-PERSIST-01 ondersteunt. Controleer welke van uw uitgevende certificeringsinstanties al persistente DCV ondersteunen, aangezien dit een nieuwe toegestane methode is die nog steeds door certificeringsinstanties wordt uitgerold.
4. Een aangewezen eigenaar voor goedkeuring van DNS-wijzigingen. Zelfs geautomatiseerde DNS-wijzigingen vereisen een gedefinieerde eigenaar voor auditdoeleinden, doorgaans het platform- of infrastructuurteam.
5. Een platform voor het beheer van de levenscyclus van certificaten zoals CertSecure Manager Geschikt voor het inplannen van terugkerende DCV- en DNS-connectoroproepen, in plaats van eenmalige scripts.

Stapsgewijze implementatieworkflow

Zodra aan bovenstaande voorwaarden is voldaan, verloopt de uitrol in vijf stappen. Bij elke stap wordt het resultaat beschreven dat u moet zien voordat u naar de volgende stap kunt gaan.

Stap 1: Inventariseer de certificatenportefeuille

Ontdek alle openbaar vertrouwde certificaten, met speciale aandacht voor certificaten die na 15 maart 2026 verlopen. Ontdekkingshiaten, certificaten die niemand zich herinnert, zijn de grootste oorzaak van stille storingen. Voorzie elk certificaat van een label met het bijbehorende domein, de SAN-lijst en de bedrijfseigenaar. Resultaat: een complete, van eigenaarslabels voorziene inventaris van het openbare TLS-ecosysteem.

Stap 2: DNS-providers toevoegen

Verbind elke DNS-provider die uw zones host met het certificaatlevenscyclusplatform via de API-gegevens, zodat DNS-01-uitdagingsrecords programmatisch kunnen worden aangemaakt en geverifieerd. Dit elimineert de handmatige overdracht tussen certificaat- en DNS-teams. Resultaat: elke DNS-provider in de omgeving is verbonden en het platform kan een test-TXT-record schrijven zonder handmatige tussenkomst.

Afbeelding 1. DNS-provider onboarding en DNS-01 connector configuratie in CertSecure Manager.

Stap 3: Publiceer het permanente validatierecord

Voor domeinen die in aanmerking komen, publiceert u het eenmalige TXT-record op _validation-persist.[domein] in het eerder getoonde formaat, met behulp van de connector in plaats van een handmatig DNS-ticket. Geef prioriteit aan SAN- en wildcarddomeinen, aangezien deze de hoogste coördinatiekosten met zich meebrengen onder het oude model. Resultaat: het permanente record wordt correct opgelost en de uitgevende CA bevestigt dat het account wordt herkend.

Stap 4: Configureer de geplande DCV-automatisering

Stel het certificaatlevenscyclusplatform zo in dat er periodieke domeinvalidatie wordt uitgevoerd, afgestemd op de vernieuwingsfrequentie die uw certificaten nu vereisen, in plaats van de validatie handmatig te activeren bij elke vernieuwing. Zorg ervoor dat dit CA-onafhankelijk is, zodat hetzelfde schema geldt, ongeacht welke openbare CA een bepaald certificaat uitgeeft. Resultaat: DCV wordt automatisch uitgevoerd vóór elke vernieuwing, zonder tussenkomst per cyclus.

Afbeelding 2. Status van de geplande DNS-01-domeinvalidatie in CertSecure Manager.

Stap 5: Valideren, bewaken en terugdraaibeveiliging instellen

Controleer of een volledige vernieuwingscyclus zonder handmatige tussenkomst van begin tot eind is voltooid. Schakel vervolgens de monitoring in voor de permanente record (onverwachte wijzigingen hierin zijn een waarschuwingssignaal) en voor mislukte connectoroproepen. Documenteer het terugdraaipad voordat u het nodig hebt. Resultaat: ten minste één volledige geautomatiseerde vernieuwingscyclus is succesvol voltooid, met waarschuwingen voor de record en de connector.

Richtlijnen voor terugdraaien en veelvoorkomende fouten

Veelvoorkomende fouten waar u op moet letten

• DNS-propagatievertragingen. Een nieuw geschreven TXT-record dat nog niet is doorgegeven aan alle gezaghebbende naamservers, zorgt ervoor dat de validatiecontrole van de CA mislukt; voeg een doorgiftecontrole toe aan de workflow voordat de uitgifte wordt geactiveerd.
• De reikwijdte van de API-referenties is te beperkt of ze zijn verlopen. Een DNS-connector met alleen-lezen of verlopen API-referenties zal bij de volgende geplande uitvoering stilzwijgend falen; vervang en test de referenties volgens een vast schema, niet alleen wanneer een verlenging mislukt.
• Permanente record gepubliceerd onder het verkeerde CA-account. Omdat de accounturi-waarde de record koppelt aan een specifieke ACME-account, zal een record dat voor de verkeerde account is aangemaakt, worden gevalideerd voor de verkeerde CA of helemaal niet.
• Er vindt geen monitoring plaats van de permanente registratie zelf. Aangezien het register de uitgifte op doorlopende basis autoriseert, heeft een onopgemerkte wijziging ervan een grotere impact dan een gemiste eenmalige validatie vroeger had.

Veilig terugdraaien

Als de persistente DCV voor een domein moet worden teruggedraaid, verwijdert u ofwel het TXT-record _validation-persist, ofwel deactiveert u het bijbehorende ACME-account (RFC 8555 Sectie 7.5.2), waardoor de uitgifteautorisatie onmiddellijk wordt ingetrokken. Houd de conventionele DNS-01-validatie beschikbaar als terugvaloptie voor elk domein dat is gemigreerd naar persistente DCV, en test deze terugvaloptie voordat u er in productie op vertrouwt. Schakel voor DNS-connectoren de specifieke providerintegratie uit in plaats van de platformbrede API-toegang in te trekken, zodat andere providers blijven functioneren terwijl u problemen oplost.

Matrix van voorwaarden voor actie

Eerste vereiste	Actie	Eigendomsteam
Certificaatinventaris onvolledig	Voer een certificaatdetectie uit op openbare en privénetwerken; tag elk certificaat met domein, SAN-lijst en eigenaar.	PKI/certificaatteam
Toegang tot de DNS-provider-API is nog niet verleend.	Vraag om API-referenties met beperkte toegang en schrijfrechten voor TXT-records voor elke provider.	Platform-/infrastructuurteam
CA ondersteunt DNS-PERSIST-01 nog niet.	Bevestig de permanente DCV-ondersteuning rechtstreeks bij elke uitgevende CA; gebruik in de tussentijd de conventionele DNS-01 met connectors.	PKI/certificaatteam
Geen eigenaar opgegeven voor geautomatiseerde DNS-wijzigingen	Wijs een eigenaar aan en documenteer deze voor controledoeleinden.	Beveiligings-/nalevingsteam
Geen geplande DCV-automatisering in het lifecycle-platform.	Configureer terugkerende, CA-onafhankelijke domeinvalidatie afgestemd op de vernieuwingsfrequentie.	PKI/certificaatteam

Voor en na: DNS-validatieprocessen

Operationele stap	Voorheen (handleiding)	Na (permanente DCV- en DNS-connectoren)
Een DNS-wijziging aanvragen	Ticket ingediend bij het netwerkteam, in de wachtrij geplaatst achter andere wijzigingsverzoeken.	Het certificaatplatform schrijft het record rechtstreeks via de API van de provider.
Het domeineigendom verifiëren	Herhaald bij elke verlenging, tot wel ~35 keer per jaar per domein in 2029.	Eenmalige registratie voor bestaande domeinen; geen DNS-verwerking bij verlenging.
Goedkeuringstermijn	Uren tot dagen, afhankelijk van de tijdsvensters voor wijzigingsbeheer.	Minuten, aangezien er geen menselijke goedkeuring in het DNS-pad zit.
Storing bij hoge vernieuwingsfrequentie	Een gemiste of vertraagde DNS-wijziging zorgt ervoor dat de vernieuwing zelf mislukt.	De vernieuwing verloopt onafhankelijk van DNS, zodra het permanente record is aangemaakt.
Controlespoor	Verspreid over het ticketsysteem, de DNS-console en het CA-portaal.	Gecentraliseerd in de connector en DCV-logboeken van het certificaatlevenscyclusplatform.

Beslissingstabel: Welk DNS-01-automatiseringspad past bij uw organisatie?

Niet elke situatie vereist hetzelfde uitgangspunt. Gebruik de onderstaande tabel om uw huidige situatie te koppelen aan de juiste volgende stap.

Jou situatie	Aanbevolen pad	Waarom
Klein landgoed (minder dan 50 openbare certificaten), jaarlijkse verlengingsfrequentie vandaag	Handmatige of geautomatiseerde verlenging op korte termijn is nog steeds mogelijk, maar streef naar een geldigheidsduur van 100 dagen tegen maart 2027.	Het aantal verlengingen is nog steeds laag genoeg om handmatig te verwerken, maar de drempel van 2027 verviervoudigt de verlengingsfrequentie ruwweg.
DNS-wijzigingen worden afgehandeld via een ticket- of wijzigingsbeheerproces.	Geef eerst prioriteit aan DNS-connectoren.	Elimineert de menselijke overdracht die het zwakke punt wordt zodra de validatie om de paar weken moet worden herhaald.
Een groot of SAN/wildcard-rijk domein dat zich uitstrekt over meerdere domeinen.	Gebruik persistente DCV (DNS-PERSIST-01) voor bestaande domeinen, in combinatie met DNS-connectoren voor nieuwe domeinen.	Elimineert volledig de DNS-werkzaamheden bij elke verlenging voor reeds gevalideerde domeinen, waardoor DNS-wijzigingen van honderden per jaar worden teruggebracht tot een eenmalige configuratie per domein.
Multicloud- of hybride PKI-omgeving die meerdere publieke en private CA's omvat.	Implementeer CA-onafhankelijke automatisering zoals CertSecure Manager v3.3, waarbij geplande DCV, DNS-connectoren en gecentraliseerde auditregistratie worden gecombineerd.	Zorgt ervoor dat de validatie consistent en controleerbaar blijft, ongeacht welke openbare of particuliere certificeringsinstantie (CA) een bepaald certificaat uitgeeft, en voorkomt dat de workflow opnieuw moet worden opgebouwd bij het consolideren van CA's of cloudproviders.

Eigenaar- en actiematrix per team

Team	Verantwoordelijkheid	Kernactie
PKI/certificaatteam	Beheert de certificatenvoorraad en de relaties met certificeringsinstanties.	Bepaal welke domeinen in aanmerking komen voor permanente DCV en sorteer de uitrol op risico (eerst SAN/wildcard).
Beveiligingsteam	Beschikt over eigen inloggegevens en sleutelbeveiliging.	Beschouw ACME-accountsleutels achter permanente records als gevoelige inloggegevens; controleer op ongeautoriseerde wijzigingen.
Platform-/infrastructuurteam	Beschikt over toegang tot de DNS-provider en API-gegevens.	Verleen en roteer DNS API-referenties met een beperkte reikwijdte; verbind elke provider met het lifecycle-platform.
Complianceteam	Beschikt over auditbewijsmateriaal voor gereguleerde kaders.	Bevestig dat de DCV- en connectoractiviteit wordt geregistreerd, bewaard en gekoppeld aan de DORA-, NIS2- of FedRAMP/CMMC-controlevereisten.

Succesindicatoren om na de implementatie te volgen

Houd deze statistieken bij vóór en na de uitrol, zodat de impact van de automatisering meetbaar is in plaats van te worden aangenomen. Rapporteer, indien u beschikt over concrete cijfers uit uw eigen omgeving, deze per kwartaal in plaats van als een eenmalig cijfer.

• Tijd bespaard bij verlenging per certificaat, waarbij handmatige DNS-coördinatie wordt vergeleken met connectorgestuurde validatie.
• Aantal certificaten onder geplande, CA-onafhankelijke DCV-automatisering, als percentage van het totale openbare TLS-vermogen.
• Vermindering van handmatige DNS-wijzigingstickets ingediend voor certificaatvalidatie.
• Storingen of bijna-storingen als gevolg van certificaten, kwartaalijks vergeleken met de basislijn van vóór de automatisering.
• Implementatie tijd voor het toevoegen van een nieuwe DNS-provider of domein aan de geautomatiseerde workflow.

We hebben hier geen specifiek referentiecijfer van de eerste partij aan deze statistieken gekoppeld, omdat we liever een geverifieerd cijfer van een voltooide uitrol rapporteren dan een schatting. Als u deze gegevens intern bijhoudt, kan ons PKI Services-team u helpen bij het vaststellen van de basislijn en het rapporteren ervan.

Wat te doen Volgende

• PKI-teams: Voer nu een detectieronde uit en markeer alle certificaten die na 15 maart 2026 verlopen voor prioritaire migratie.
• Beveiligingsteams: Voeg ACME-accountsleutels toe aan uw bestaande programma voor het bewaken van geheimen voordat u persistente DCV op grote schaal implementeert.
• Platformteams: Vraag dit kwartaal toegang tot de DNS-provider-API aan, zodat de onboarding van de connector later niet wordt geblokkeerd door een vertraging in de authenticatie.
• Nalevingsteams: Controleer of uw auditkader geautomatiseerde DCV-logboeken al als bewijs accepteert, of signaleer deze lacune nu.

CertSecure Manager v3.3: CA-onafhankelijke DNS-01-automatisering

CertSecure Manager is het leveranciersneutrale platform voor certificaatlevenscyclusbeheer van Encryption Consulting. Dankzij het CA-agnostische ontwerp detecteert, verstrekt, vernieuwt en beheert één centraal controlepaneel certificaten van alle certificeringsinstanties waarmee een organisatie werkt. Hierdoor worden toekomstige wijzigingen in geldigheid en validatie centraal afgehandeld in plaats van per instantie, en kan een certificaat opnieuw worden uitgegeven door een andere CA als een certificaat niet meer geldig is.

Deze neutraliteit is vooral belangrijk op het niveau van publieke vertrouwensinstanties, waar de termijn van 47 dagen de grootste impact heeft. CertSecure Manager integreert naadloos met de belangrijkste publieke vertrouwensinstanties, waaronder DigiCert , GlobalSign , Sectigo, Let's Encrypt en Google Public CA, naast private instanties zoals Microsoft AD CS, AWS Private CA en HashiCorp Vault. Ongeacht welke publieke CA een certificaat uitgeeft, worden de ontdekking, uitgifte, verlenging en validatie beheerd vanuit dezelfde console, namelijk de onboarding- en DCV-schermen voor DNS-providers die in de bovenstaande implementatiestappen zijn beschreven.

Voor organisaties die specifiek DNS-01-validatie willen beheren of automatiseren, is CertSecure Manager v3.3 precies voor deze overgang ontwikkeld. Encryption Consulting ondersteunt teams actief bij:

• Integreer hun openbare DNS-providers door de providers te koppelen die uw DNS-zones hosten, zodat DNS-01-uitdagingsrecords programmatisch worden aangemaakt en geverifieerd bij een breed scala aan providers. Dit elimineert de handmatige overdracht tussen certificaat- en DNS-teams.
• Beheer DCV via geplande automatisering door terugkerende domeinvalidatie uit te voeren die is afgestemd op de vernieuwingsfrequentie van certificaten met een geldigheidsduur van 100 en 47 dagen, zodat het DNS-01-bewijs actueel blijft zonder dat er per cyclus tussenkomst nodig is.
• Zorg ervoor dat de validatie CA-onafhankelijk blijft door dezelfde DNS-01-automatisering toe te passen, ongeacht welke openbare CA het certificaat uitgeeft. Op die manier hoeft de validatieworkflow niet opnieuw te worden opgebouwd bij het samenvoegen of overstappen naar een andere provider.
• Bouw automatiseringsklare workflows binnen de gehele organisatie door middel van continue detectie, beleidshandhaving en zero-touch verlengingsagents, zodat verlengingen in machinetempo niet leiden tot evenredige handmatige inspanning.

Het doel is het operationele model dat de nieuwe tijdlijn veronderstelt: domeinvalidatie wordt behandeld als een gecoördineerd, geautomatiseerd systeem in plaats van een eenmalige taak die bij elke verlenging wordt herhaald. Door vroegtijdig te beginnen met inventarisatie, het onboarden van DNS-providers en geplande DCV-automatisering krijgen teams een geprioriteerde routekaart ruim voordat de verplichte drempelwaarden van kracht worden.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is specialist op het gebied van toegepaste cryptografie en PKI. Naast CertSecure Manager biedt onze PKI Services-praktijk organisaties ondersteuning bij de volledige implementatie van kortere certificaatlevensduren, van de eerste inventarisatie tot volledig geautomatiseerde, CA-onafhankelijke domeinvalidatie. Wij helpen teams bij:

• Beoordeel de gereedheid van het TLS-certificaat voor 47 dagen. Ontdek alle publiekelijk vertrouwde certificaten, breng de hiaten in de certificaatdetectie aan het licht die stille storingen veroorzaken, en stel een migratieplan op met prioriteiten voor de mijlpalen van 2026 tot 2029.
• Automatiseer de DNS-01-validatie. Integreer uw openbare DNS-providers en implementeer geplande, CA-onafhankelijke domeinvalidatie, inclusief permanente DCV (DNS-PERSIST-01) voor bestaande domeinen, zodat verlengingen losgekoppeld zijn van handmatig DNS-werk.
• CertSecure Manager implementeren en integreren. Implementeer het platform in uw openbare en private CA's, met verlengingsagents voor zero-touch verlenging op webservers, loadbalancers en interne applicaties.
• PKI ontwerpen en beheren. Dit omvat het ontwerp en de implementatie van PKI, samen met beheermogelijkheden via PKI-as-a-Service en HSM-as-a-Serviceinclusief de bescherming van de ACME-accountsleutels, wat door de permanente DCV-beveiliging cruciaal is.
• Bouw crypto-flexibiliteit en PQC-gereedheid op. Dit betekent naleving van de CA/Browser Forum-standaarden, RFC-conforme validatie en gereedheid na de quantumimplementatie, gebaseerd op onze PQC Centrum van Uitmuntendheid en 9-fasen PQC-gereedheid routekaart, ondersteund door een levende CBOM Secure Een inventarisatie van al uw cryptografische activa, zodat de automatisering die u nu bouwt ook bij de volgende overgang blijft bestaan. CBOM: van inventarisatie tot intelligentie Deze handleiding beschrijft hoe je die inventaris omzet in een concreet programma voor crypto-flexibiliteit.

Om uw certificatenportfolio te beoordelen aan de hand van de termijn van 47 dagen en een routekaart voor DNS-01-automatisering op te stellen, kunt u contact opnemen met het PKI Services-team van Encryption Consulting.

Gerelateerde artikelen van Encryption Consulting

Meer informatie over de hierboven besproken deadlines, protocollen en automatisering is beschikbaar:

• Het mandaat van CA/Browser Forum Dit artikel behandelt de beperkingen op de geldigheidsduur, de deadline van juni 2026 voor het duale EKU-programma en de bijbehorende vereisten.
• Openbare CA versus particuliere CA legt uit wanneer je welke methode moet gebruiken en hoe je automatisering kunt opzetten voor de periode van 47 dagen.
• Het kiezen van een certificaatinschrijvingsprotocol Vergelijkt ACME, EST, SCEP en CMP voor kortlopende certificaten.
• Wat is het ACME-protocol? legt uit hoe challenge-response-validatie, inclusief DNS-01, daadwerkelijk werkt.
• ACME-clients op Linux Dit artikel behandelt Certbot, acme.sh, de dekking van DNS-providers en de rol van centraal beheer.
• Schaalvergroting van certificaatlevenscyclusprocessen met automatisering laat zien hoe je frequente verlengingen kunt omzetten in een gebeurtenisgestuurd, automatisch proces.
• CertSecure Manager v3.3 beschrijft in detail wat de release toevoegt voor de hogere vernieuwingsfrequentie.
• Centraliseer de uitgifte van Let's Encrypt- en DNS-01-certificaten met CertSecure Manager. Omvat de validatie van de DNS-01-uitdaging bij alle openbare DNS-providers, centraal beheerd.
• Handleiding voor de migratie van post-kwantumcryptografie (9 fasen) schetst de routekaart voor de algoritmetransitie die volgt op de huidige wijzigingen in de levensduur en validatie van certificaten.
• Hoe bouw je een cryptografische inventaris (CBOM)? In dit artikel wordt de discipline van het ontdekken van cryptografie uitgebreid van TLS-certificaten naar uw volledige cryptografische infrastructuur.
• CBOM: Van inventaris naar intelligentie Dit laat zien hoe je een cryptografische inventaris kunt omzetten in een doorlopend programma voor cryptografische flexibiliteit en PQC-gereedheid.

Conclusie

De ontwikkeling is onomstotelijk. Tegen 2029 zullen openbare TLS-certificaten 47 dagen geldig zijn en zal het bewijs van domeinvalidatie elke 10 dagen verlopen. Dit maakt van wat ooit een jaarlijkse formaliteit was een continue operationele taak. Handmatige DNS-updates en validatie via e-mail kunnen dit tempo niet bijhouden. Persistent DCV (DNS-PERSIST-01) elimineert de DNS-wijziging bij elke verlenging voor bestaande domeinen, en DNS-connectoren automatiseren de resterende wijzigingen; samen zorgen ze ervoor dat domeinvalidatie kan meegroeien met de uitgiftefrequentie in plaats van dat deze daardoor vastloopt.

De organisaties die deze transitie soepel doorstaan, zijn de organisaties die zich voorbereiden voordat de drempelwaarden ingaan. Ze inventariseren hun domeinen, voegen hun DNS-providers toe en zetten domeinvalidatie nu al over op geplande, CA-onafhankelijke automatisering, zolang certificaten met een geldigheidsduur van 200 dagen nog ruimte bieden voor aanpassingen. Domeinvalidatie wordt steeds meer een achtergrondproces; de uitdaging is om ervoor te zorgen dat het soepel verloopt voordat de deadline van 2027 dit afdwingt.

Dit bericht wordt elk kwartaal herzien, rekening houdend met de actieve beleidsschema's SC-081v3 en SC-088v3 van het CA/Browser Forum, en onmiddellijk wanneer het CA/Browser Forum de hergebruiksperioden van DCV bijwerkt, nieuwe permanente DCV-vereisten toevoegt of wanneer een belangrijke DNS-provider het authenticatiegedrag van de API wijzigt.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie van deze handleiding over persistente DCV- en DNS-connectoren?

De geldigheidsduur van openbare TLS-certificaten wordt vanaf maart 2029 teruggebracht tot 47 dagen, waardoor domeineigendom ongeveer 35 keer per jaar opnieuw moet worden bewezen. Persistent DCV (DNS-PERSIST-01) elimineert de noodzaak voor DNS-wijzigingen bij elke verlenging voor bestaande domeinen door gebruik te maken van één vast TXT-record, en DNS-connectoren automatiseren de resterende DNS-wijzigingen. Samen zorgen ze ervoor dat domeinvalidatie kan meegroeien met de uitgiftefrequentie in plaats van een volgend knelpunt te worden.

Waarom is dit belangrijk voor het beheer van de levenscyclus van bedrijfscertificaten?

Certificaatlevenscyclusbeheer kampt nu al met problemen op het gebied van inzicht: onderzoek van DigiCert uit 2026 wees uit dat slechts 34% van de organisaties een volledig en actueel overzicht van hun certificaten heeft. Naarmate de vernieuwingsfrequentie tegen 2029 verachtvoudigt, wordt elke handmatige stap in de validatie, met name de DNS-coördinatie, een proportioneel grotere bron van gemiste vernieuwingen en storingen, tenzij deze stap van tevoren wordt geautomatiseerd.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

Deze taak wordt doorgaans door vier teams gedeeld: het PKI- of certificaatteam beheert de inventaris en de CA-relaties, het platform- of infrastructuurteam beheert de toegang tot DNS-providers en de onboarding van connectors, het beveiligingsteam beschermt de ACME-accountsleutels waarop persistente DCV is gebaseerd, en het compliance-team zorgt ervoor dat geautomatiseerde validatieactiviteiten worden vastgelegd voor auditdoeleinden. De bovenstaande matrix met verantwoordelijkheden en acties geeft een gedetailleerde uitleg hiervan.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Uit het Trust Pulse-onderzoek van DigiCert bleek dat 45% van de bedrijven het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaatproblemen, waarvan 37.5% direct te wijten was aan een verlopen certificaat. Meer dan de helft van deze incidenten veroorzaakte 5 tot 24 uur downtime. Handmatige DNS-coördinatie is de meest voorkomende oorzaak van problemen wanneer de validatie om de paar weken in plaats van jaarlijks moet worden herhaald, omdat een enkele gemiste of vertraagde DNS-wijziging ervoor kan zorgen dat de verlenging zelf mislukt.

Hoe vermindert automatisering het risico op certificaatuitval?

Automatisering elimineert de menselijke tussenkomst, de ticketwachtrij en het goedkeuringsvenster die momenteel in het DNS-proces aanwezig zijn. Persistent DCV maakt de DNS-stap volledig overbodig voor bestaande domeinen, en DNS-connectoren voeren eventuele resterende DNS-wijzigingen via de API van de provider binnen enkele minuten uit in plaats van uren of dagen. Omdat verlenging niet langer afhankelijk is van een menselijke tussenkomst bij het tijdig voltooien van een DNS-wijziging, wordt de meest voorkomende oorzaak van certificaatuitval weggenomen.

Welke statistieken moeten teams bijhouden na de implementatie?

Houd bij hoeveel tijd er per certificaat wordt bespaard bij het vernieuwen van certificaten, het percentage van de openbare TLS-omgeving dat onder geplande CA-onafhankelijke DCV-automatisering valt, de vermindering van handmatige DNS-wijzigingstickets, certificaatgerelateerde storingen of bijna-storingen ten opzichte van een basislijn van vóór de automatisering, en de implementatietijd voor het onboarden van nieuwe DNS-providers of domeinen. Rapporteer deze gegevens per kwartaal, zodat de trend, en niet slechts een momentopname, laat zien of de automatisering standhoudt naarmate de vernieuwingsfrequentie toeneemt.

Hoe hangt dit samen met de 47-daagse TLS-certificaatgereedheid?

Het CA/Browser Forum heeft in het kader van Ballot SC-081v3 de maximale geldigheidsduur van TLS-certificaten teruggebracht tot 200 dagen op 15 maart 2026, 100 dagen op 15 maart 2027 en 47 dagen op 15 maart 2029. Tegelijkertijd wordt de hergebruiksperiode van DCV-certificaten teruggebracht tot 10 dagen. Permanente DCV- en DNS-connectoren zijn de specifieke mechanismen die het operationeel mogelijk maken om deze frequentie te halen zonder een evenredige toename van handmatig DNS-werk.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Gebruik een CA-onafhankelijk platform voor de levenscyclus van certificaten, zoals CertSecure Manager, dat dezelfde logica voor geplande DCV en DNS-connectoren toepast, ongeacht of een certificaat door een openbare of private CA is uitgegeven en ongeacht in welke cloud de DNS-zone wordt gehost. Dit voorkomt dat de validatieworkflow telkens opnieuw moet worden opgebouwd wanneer een certificaat opnieuw wordt uitgegeven door een andere CA of wanneer een DNS-zone tussen providers wordt verplaatst, wat vaak voorkomt in multi-cloud- en hybride PKI-omgevingen.

Welke voorwaarden zijn nodig vóór de implementatie?

U hebt een actuele, eigenaar-gelabelde certificaatinventaris nodig; API-referenties met schrijftoegang tot TXT-records voor elke gebruikte DNS-provider; bevestiging van welke uitgevende CA's momenteel DNS-PERSIST-01 ondersteunen; een benoemde eigenaar voor geautomatiseerde goedkeuring van DNS-wijzigingen; en een certificaatlevenscyclusplatform dat in staat is om terugkerende DCV-aanroepen in te plannen en DNS-connectoroproepen uit te voeren. De sectie met vereisten hierboven beschrijft elk van deze punten in detail.

Welke veelgemaakte fouten moeten teams vermijden?

De meest voorkomende fouten: het publiceren van een permanent record onder het verkeerde ACME-account (de mismatch in de accounturi zorgt ervoor dat de CA het record stilzwijgend afwijst); het niet controleren van het _validation-persist-record op ongeautoriseerde wijzigingen (een permanent record is een belangrijker doelwit dan een record dat per verlenging wordt vernieuwd); het niet controleren van de propagatie van een nieuw geschreven TXT-record voordat de uitgifte wordt geactiveerd (de vertraging in de DNS-propagatie zorgt ervoor dat de op MPIC gebaseerde multi-perspectiefcontrole van de CA vanuit één regio mislukt); en het niet roteren van de DNS-connector API-referenties volgens een kalender (verlopen referenties mislukken stilzwijgend bij de volgende geplande uitvoering, niet wanneer ze verlopen).

Wat moet er elk kwartaal worden bijgewerkt voor het beheer van DCV-automatisering?

Driemaandelijks: controleer of alle permanente records correct worden opgelost en overeenkomen met geautoriseerde ACME-accounts; roteer en test de API-referenties van de DNS-connector; controleer de logboeken met mislukte connectoroproepen van het voorgaande kwartaal; controleer of nieuwe domeinen die sinds de laatste controle zijn toegevoegd, de dekking van permanente records garanderen; controleer CA/Browser Forum SC-081v3 en SC-088v3 op updates met betrekking tot de hergebruiksperioden van DCV of de vereisten voor permanente records; en bevestig de PQC-gereedheidsplanning voor de belangrijkste ACME-algoritmen via het PQC Center of Excellence . Deze post wordt driemaandelijks gecontroleerd, rekening houdend met het actieve beleidsschema van CA/Browser Forum.