Automatisera DNS-validering med CertSecure Manager: Persistenta DCV- och DNS-kopplingar

Ett certifikat som tidigare förnyades en gång om året måste nu valideras på nytt ungefär var femte till sjätte vecka, och i mars 2029 har den kadensen minskat till var 47:e dag. Persistent DCV (DNS-PERSIST-01) och DNS-kopplingar är de två kontrollerna som gör att domänkontrollvalideringen hänger med: persistent DCV låter en domän verifieras på nytt mot en enda DNS TXT-post som publicerats en gång, och DNS-kopplingar automatiserar de DNS-ändringar som fortfarande finns kvar, så att certifikatteam kan uppfylla CA/Browser Forums krympande giltighetsschema utan manuellt DNS-arbete vid varje förnyelse.

Den här guiden beskriver vad varje funktion gör, de exakta deadlines som tvingar fram förändringen, förutsättningarna och det stegvisa arbetsflödet för att implementera båda, vilka team som ansvarar för att agera utifrån den, och de mätvärden som visar om automatiseringen faktiskt fungerar.

Snabbt svar: Vad är persistenta DCV- och DNS-kopplingar?

Persistent DCV (DNS-PERSIST-01) låter en domänägare publicera en TXT-post på _validation-persist.[domain] som en CA kontrollerar automatiskt vid varje förnyelse, vilket eliminerar DNS-arbete per förnyelse. DNS-kopplingar automatiserar DNS-ändringarna som finns kvar via leverantörens API. Tillsammans krävs de för att upprätthålla CA/Browser Forums 47-dagars TLS-giltighetsschema (mars 2029, Ballot SC-081v3) utan proportionell manuell ansträngning.

Key Takeaways

• CA/Browser Forums omröstning SC-081v3 minskar den maximala giltighetstiden för offentliga TLS-certifikat till 200 dagar den 15 mars 2026, 100 dagar den 15 mars 2027 och 47 dagar den 15 mars 2029, medan återanvändningsperioderna för DCV krymper enligt samma schema ner till 10 dagar.
• Persistent DCV (DNS-PERSIST-01), tillåten sedan november 2025 enligt Ballot SC-088v3, låter en domän omvalideras mot en TXT-post som publicerats en gång, vilket helt tar bort DNS-arbete per förnyelse för etablerade domäner.
• DNS-kopplingar automatiserar de DNS-ändringar som kvarstår, inklusive nya domäner och initial installation, genom att kommunicera direkt med DNS-leverantörens API istället för att dirigera via ett manuellt ärende.
• DigiCerts Trust Pulse-undersökning (2 juli 2025) fann att 45 % av företagen hade certifikatrelaterade driftstopp under det senaste året, och 37.5 % spårade ett avbrott specifikt till ett utgånget certifikat.
• PKI-, säkerhets-, plattforms- och efterlevnadsteamen äger var och en en egen del av denna utrullning; ägar-/åtgärdsmatrisen och checklistan för förutsättningar nedan visar exakt vem som gör vad.

Hoppa till: Sammanfattning | Implementeringsarbetsflöde | Matris för förutsättningar för åtgärd | Matris för ägare/åtgärder | Framgångsmått | CertSecure Manager v3.3 | Vanliga frågor

Vem borde bry sig om beständiga DCV- och DNS-kopplingar

De operativa konsekvenserna av CA/Browser Forums schema för giltighetsminskning drabbar certifikatteam, DNS-team, säkerhetsarkitekter, plattformsingenjörer och compliancefunktioner samtidigt. Var och en äger en distinkt felpunkt. Ett certifikatteam som automatiserar förnyelse men inte automatiserar DNS-validering stöter fortfarande på väggen när återanvändningsfönstret för DCV löper ut. Ett DNS-team som beviljar API-åtkomst men inte övervakar rotation av anslutningsuppgifter skapar ett tyst felläge. Vid 47 dagars giltighet från mars 2029 producerar varje lucka förnyelsefel åtta gånger snabbare än före 2029.

Roll	Varför det gäller	Åtgärdsobjekt
PKI- och certifikatteam	Äg certifikatinventeringen och CA-relationerna; måste identifiera vilka domäner som kvalificerar sig för ihållande DCV och sekvensutrullning efter risk (SAN- och wildcard-domäner först, eftersom de har den högsta koordineringskostnaden); DigiCerts Trust Pulse Survey (2 juli 2025) fann att 45 % av företagen hade certifikatrelaterad driftstopp under det senaste året, och vid 47 dagars giltighetstid producerar varje manuell valideringsfel ett avbrott åtta gånger oftare än tidigare; endast 34 % av organisationerna har en fullständig och aktuell bild av sina certifikat (DigiCert PKI Under Pressure-rapport, 2 juni 2026), vilket gör upptäckt till en förutsättning för att avblockera allt annat.	Kör ett fullständigt certifikatidentifieringspass med CertSecure-hanterare att bygga en ägartaggad inventering av alla offentligt betrodda certifikat och dess SAN-lista; använda CBOM-säkerhet att utöka identifieringen bortom TLS-certifikat till hela kryptografiska tillgången; prioritera SAN- och jokerteckensdomäner för permanent DCV-onboarding först; bekräfta vilka utfärdande CA:er som redan stöder DNS-PERSIST-01 och använda konventionell DNS-01 med kopplingar för de som ännu inte stöder det.
Plattforms- och infrastrukturteam	Egen DNS-leverantörsåtkomst och API-autentiseringshantering, vilket är gating-förutsättningen för onboarding av connector; den långsammaste delen av DNS-baserad validering är vanligtvis inte DNS-sökningen utan den mänskliga överlämningen mellan certifikat- och DNS-team; en förnyelse som misslyckas på grund av att en DNS-ändringsbiljett inte behandlades i tid producerar exakt de avbrott som DigiCerts undersökning från juli 2025 mätte; connector-API-autentiseringsuppgifter måste vara korrekt omfattade, roteras enligt schema och testas proaktivt snarare än att upptäckas vara utgångna först när en förnyelse misslyckas	Begär scoped API-autentiseringsuppgifter med skrivåtkomst till TXT-poster för varje DNS-leverantör som används (Route 53, Cloudflare, Azure DNS, Google Cloud DNS och alla andra); anslut varje leverantör till CertSecure-hanterare använda DNS-anslutningsintegrationen; testa att en skriv-validera-borttagnings-TXT-postcykel slutförs programmatiskt utan en biljett innan något produktionscertifikat är beroende av den; kalenderlägg kvartalsvis rotation av autentiseringsuppgifter och testa varje anslutning efter rotation för att bekräfta att den fortfarande skriver poster korrekt
Säkerhetsarkitekter	Äg den styrningsmodell för autentiseringsuppgifter och övervakning som gör persistent DCV säker snarare än att skapa en ny stående attackyta; persistent DCV flyttar tillgången för att skydda mot DNS-skrivåtkomst (som måste vara tillgänglig vid varje förnyelse) till ACME-kontonyckeln (som endast krävs för att konfigurera den persistenta posten); en komprometterad eller oövervakad ACME-kontonyckel som backar upp en persistent post kan auktorisera certifikatutfärdande för en etablerad domän utan att utlösa en DNS-ändringsvarning; själva _validation-persist-posten måste övervakas för obehörig modifiering.	Lägg till ACME-kontonycklar som stöder permanenta DCV-poster till organisationens befintliga program för hantering och rotation av hemligheter innan permanent DCV implementeras i stor skala; konfigurera övervakningsvarningar på _validation-persist TXT-posten för varje domän så att alla oväntade förändringar utlöser en utredning; definiera den obehöriga handlingsplanen för permanenta poster (inaktivera ACME-kontot enligt RFC 8555 avsnitt 7.5.2 för att omedelbart återkalla utfärdandebehörighet); planera PQC-beredskap för ACME-nyckelalgoritmer genom PQC:s kompetenscentrum och PQC-beredskap tjänster
Compliance-team	Måste bekräfta att automatiserad DCV- och DNS-anslutningsaktivitet loggas och är granskningsbar för reglerade ramverk; DORA, NIS2, FedRAMP och CMMC kräver alla bevis på vem som validerade vilken domän och när; automatiserade processer som inte lämnar någon revisionsspår misslyckas med detta krav lika säkert som manuella; CA/Browser Forum SC-081v3-schemat (47 dagars giltighetstid senast mars 2029) innebär också att efterlevnadsbevis för DCV måste produceras åtta gånger oftare än före 2029, vilket gör manuell insamling av revisionsbevis ohållbar enligt samma logik som gör manuell validering ohållbar.	Bekräfta att certifikatets livscykelplattform loggar varje DCV-händelse (domän, metod, tidsstämpel, CA-konto, resultat) med tillräcklig detaljrikedom för revisionsbevis; mappa DCV- och anslutningsaktivitetsloggar till tillämpliga ramverkskontrollkrav (DORA artikel 9, NIS2 artikel 21, FedRAMP SC-12, CMMC Practice CM.L2-3.4.2); kräva att logglagringsperioden uppfyller ramverkskraven innan DCV övergår till full automatisering; utvärdera PKI som en tjänst för organisationer där hanterade PKI-åtgärder inkluderar inbyggd granskningsloggning för DCV-aktivitet
CISO: er	Certifikatavbrott orsakade av missade valideringar är operativt likvärdiga med avbrott på grund av utgångna certifikat, men svårare att diagnostisera eftersom certifikatet verkar giltigt och pålitligt men inte kan förnyas; DigiCerts Trust Pulse Survey (2 juli 2025) fann att 37.5 % av certifikatrelaterade avbrott spårades till ett utgånget certifikat, och över hälften orsakade 5 till 24 timmars driftstopp med ekonomiska förluster mellan 50 000 och 250 000 dollar i 31 % av de drabbade organisationerna; CA/Browser Forums schema för giltighetsminskning är fast oavsett organisationens beredskap, vilket gör automatiseringsinvesteringar före 2026 till ett riskreducerande beslut snarare än en valfri uppgradering.	Finansiera utrullning av ihållande DCV och DNS-anslutning som en investering i minskad operativ risk innan tröskelvärdena i mars 2026 och mars 2027 träder i kraft; kräva att täckning av certifikatautomation (procentandel av offentlig TLS-egendom under schemalagd CA-agnostisk DCV) rapporteras som en KPI på styrelsenivå kvartalsvis; kräva att skydd av ACME-kontonycklar inkluderas i granskningen av programmet för hantering av hemligheter; utvärdera PKI som en tjänst för organisationer som behöver en hanterad certifikatlivscykeloperation med inbyggd DCV-automatisering och DNS-anslutningstäckning

Sammanfattning för chefer inom säkerhet, PKI, plattform och efterlevnad

Om du leder en av dessa funktioner, här är beslutet som den här artikeln stöder och en snabbchecklista för att agera utifrån det.

• PKI/certifikatteam: inventera den publika TLS-egendomen, identifiera vilka domäner som kvalificerar sig för persistent DCV och prioritera SAN- och jokerteckendomäner för onboarding först.
• Säkerhetsteam: behandla ACME-kontonyckeln bakom en beständig post som en känslig autentiseringsuppgift och lägg till risk för certifikatavbrott på samma övervakningsnivå som andra tillgänglighetsrisker.
• Plattforms-/infrastrukturteam: Anslut DNS-leverantörer till certifikatlivscykelplattformen via API-baserade kopplingar så att DNS-ändringar inte längre väntar på ett ändringshanteringsärende.
• Compliance-team: bekräfta att automatiserad DCV- och DNS-anslutningsaktivitet loggas och är granskningsbar, eftersom reglerade miljöer (DORA, NIS2, FedRAMP, CMMC) behöver bevis på vem som validerade vad och när.

Deadlines som driver förändringen

I april 2025 godkände CA/Browser Forum omröstning SC-081v3 , ”Inför ett schema för att minska giltighets- och dataåteranvändningsperioder”, med 29 röster för och ingen emot. Omröstningen, som ursprungligen föreslogs av Apple, fastställer en stegvis minskning av både den maximala livslängden för offentligt betrodda TLS-certifikat och den period under vilken valideringsdata får återanvändas. Alla offentligt betrodda TLS-certifikat påverkas, för DV, OV och EV, inklusive jokertecken- och multidomäncertifikat (SAN). Sectigos egen analys av omröstningen från den 14 april 2025 ramar in samma schema som ett stegvis steg, inte en abrupt förändring, mot automatiserad, kvantklar certifikathantering.

Giltigt datum	Maximal TLS-giltighet	DCV-återanvändningsperiod	SII-återanvändning (OV/EV)
Till och med 14 mars 2026	398 DAYS	398 DAYS	825 DAYS
Mar 15, 2026	200 DAYS	200 DAYS	398 DAYS
Mar 15, 2027	100 DAYS	100 DAYS	398 DAYS
Mar 15, 2029	47 DAYS	10 DAYS	398 DAYS

Giltighets- och DCV-återanvändningsgränser gäller baserat på det datum då ett certifikat utfärdas, inte det datum då en beställning görs.

Återanvändningsfönstret för ämnesidentitetsinformation (SII) för OV- och EV-certifikat minskar också från 825 dagar till 398 dagar den 15 mars 2026. Denna ändring avslutar modellen "ställ in det och glöm det" för certifikat med hög garanti. För en fullständig uppsättning relaterade mandat, inklusive den separata Chrome-deadline för dual-EKU den 15 juni 2026, se vår analys av CA/Browser Forum-mandatet . Samma förändring förändras också när man ska förlita sig på en offentlig kontra en privat CA.

Varför kortare certifikat inte fungerar vid manuell domänvalidering

Utmaningen ligger inte i själva certifikatet. Den kommer från hur ofta det utfärdas på nytt. Tänk dig en organisation med 1 000 offentligt betrodda certifikat. Idag, med en giltighetstid på 398 dagar, genererar den licensen ungefär 1 000 förnyelser per år. År 2029, med en giltighetstid på 47 dagar, genererar samma licens mer än 8 000 förnyelser per år, en åttafaldig ökning av identiskt arbete.

Valideringen påverkas ännu mer direkt. När återanvändningsfönstret för DCV sjunker till 10 dagar medan certifikat varar i 47 dagar, måste domänägarskapet bevisas på nytt ungefär 35 gånger per år, per domän. E-postbaserad validering och engångsplacering av HTTP-filer kan inte köras med den takten. De team som är mest utsatta är de som hanterar stora domäner, SAN-certifikat som aggregerar många domäner under en validering och jokerteckendomäner. Exponeringen är störst där DNS-ägarskapet är uppdelat mellan nätverks-, infrastruktur- och plattformsteam, och där varje ändring väntar på en ändringshanteringsbiljett.

Implikationen är tydlig. Vid maskinellt snabba förnyelsefrekvenser är manuell certifikathantering inte längre genomförbar, och certifikatautomatisering blir baslinjen. Frågan är vilken form av automatisering som eliminerar den största operativa risken.

Uppgifterna bakom brådskan

Matematiken ovan är inte teoretisk. Ny forskning inom branschen kvantifierar exakt vad som händer när validering och förnyelse inte kan hålla jämna steg med ett komprimerat certifikatschema:

• 45 % av företagen upplevde driftstopp kopplade till en certifikatrelaterad incident under det senaste året, och 37.5 % spårade ett avbrott specifikt till ett utgånget certifikat., enligt DigiCerts Trust Pulse-undersökning, publicerad 2 juli 2025. Över hälften av de drabbade organisationerna upplevde 5 till 24 timmars driftstopp, och 31 % rapporterade ekonomiska förluster mellan 50 000 och 250 000 dollar.
• 72 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under det senaste året., enligt CyberArks Rapport om maskinidentitetssäkerhetens tillstånd 2025, som undersökte 1 200 säkerhetschefer i sex länder.
• Endast 34 % av organisationerna har en fullständig och aktuell bild av sina digitala certifikat., och nästan 75 % är mycket eller extremt oroade över avbrott orsakade av utgångna certifikat, enligt DigiCerts "PKI under press: Vändpunkten för modernisering" rapport, publicerad 2 juni 2026, baserad på en undersökning av fler än 400 ledande IT- och säkerhetschefer.
• Automatiserad, DNS-validerad utfärdande är redan normenLet's Encrypts automatiserade ACME-utgivning står ensam för mer än 60 % av alla TLS-certifikat som används, och över 94 % av alla certifikat som utfärdas idag är domänvaliderade, de flesta utfärdas direkt genom automatiserade processer, från och med första kvartalet 2026 (SSL-påminnelse, ”TLS-status Q1 2026”).

Persistenta DCV- och DNS-kopplingar är de mekanismer som gör att domänvalidering kan hålla jämna steg med den övergången mot alltid automatiserad utfärdande, snarare än att bli nästa operativa flaskhals när förnyelsefrekvensen mångdubblas.

Vad är domänkontrollvalidering (DCV)?

Domänkontrollvalidering är den process som en CA använder för att bekräfta att en certifikatansökande kontrollerar domänen som anges i begäran. CA/Browser Forum Baseline Requirements definierar flera accepterade metoder. De tre som används ofta är:

• DNS-baserad validering kräver att sökanden publicerar en TXT-post under domänen, som CA sedan kontrollerar. Detta är den enda metoden som hanterar jokerteckendomäner och skalar rent genom automatisering.
• HTTP-baserad validering kräver att sökanden placerar en fil på en känd sökväg på webbservern. Det fungerar för enskilda värdar men blir krångligt över distribuerade eller lastbalanserade maskinparker.
• E-postbaserad validering kräver att sökanden svarar på ett meddelande som skickas till en domänkontakt. Denna metod är mänskligt styrd och fasas ut för automatiserad utfärdande.

För organisationer som arbetar i stor skala är DNS-baserad validering det praktiska valet. Det fungerar för jokertecken, det kan drivas helt via API:er och det ligger till grund för de automatiserade utfärdandeprotokoll som den nya tidslinjen i praktiken gör obligatoriska, framför allt ACME och dess DNS-01-utmaning. Både persistenta DCV- och DNS-kopplingar bygger direkt på denna DNS-baserade grund.

Vad är beständig DCV (DNS-PERSIST-01)?

Persistent DCV är en DNS-baserad valideringsmetod som eliminerar behovet av att skapa och ta bort en DNS-post för varje utfärdande. Den lades till i baskraven som avsnitt 3.2.2.4.22, med titeln "DNS TXT Record with Persistent Value" och kallas allmänt för DNS-PERSIST-01, genom Ballot SC-088v3 , och blev en tillåten metod i november 2025. Den föreslogs av Amazon Trust Services och godkändes av bland annat Google Chrome, DigiCert och Sectigo.

Mekaniken är enkel. Istället för att tillhandahålla en ny, tillfällig post för varje valideringshändelse publicerar domänägaren en enda kontoberoende TXT-post en gång, med etiketten _validation-persist.[domain]. Den posten identifierar sökandens CA-konto. Från och med då utför CA återkommande valideringskontroller automatiskt mot samma post, utan att ytterligare DNS-ändringar krävs. Viktigt är att ihållande DCV inte försvagar verifieringen av domänägarskap. CA/Browser Forum kräver att den tillhandahåller säkerhet motsvarande befintliga DNS-baserade metoder. Den ändrar när och hur verifiering sker, och går från händelsedrivna kontroller till kontinuerlig, automatiserad omvalidering. CA:er är fortfarande bundna av samma 10-dagars återanvändningsgräns, och ihållande DCV innebär att den underliggande posten aldrig behöver byggas om för att uppfylla den.

Det persistenta TXT-postformatet

Själva posten kodar vem som är behörig att utfärda. En beständig TXT-post har formen:

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

Postnamnet identifierar domänen; myndigheten namnger CA:n; accounturi identifierar det ACME-konto som är behörigt att utfärda (enligt RFC 8657, och stabilt över nyckelrotationer enligt RFC 8555 avsnitt 7.3.5); och det valfria `persistUntil` anger ett utgångsdatum. CA:n kontrollerar sedan denna enda post igen vid varje utfärdande.

Den operativa besparingen skalas med värdet. En organisation som validerar 100 domäner fyra gånger om året utför ungefär 400 DNS-ändringar årligen under konventionell DNS-01, jämfört med 100 engångsposter under permanent DCV.

En avvägning kräver uttrycklig uppmärksamhet. Eftersom en permanent post auktoriserar utfärdande, måste tillgången skydda skift från DNS-skrivåtkomst till ACME-kontonyckeln. Behandla nyckeln som en känslig autentiseringsuppgift, övervaka den permanenta posten för oväntade ändringar och observera att utfärdandet kan återkallas omedelbart genom att inaktivera ACME-kontot (RFC 8555 avsnitt 7.5.2).

Traditionell DCV kontra ihållande DCV

Traditionell DNS-baserad DCV	Permanent DCV (DNS-PERSIST-01)
En unik, tillfällig TXT-post skapas för varje utfärdandehändelse.	En enda beständig TXT-post publiceras en gång på _validation-persist.
Posten läggs till, valideras, tas sedan bort eller roteras varje cykel.	CA kontrollerar samma post igen vid varje utfärdande; ingen DNS-ändring behövs.
DNS-koordinering upprepas vid varje förnyelse, vilket är den felpunkt som skalas med frekvensen.	DNS-koordinering sker en gång vid installationen; förnyelser är frikopplade från DNS-arbetet.
Blir 8 gånger mer frekvent när giltigheten krymper till 47 dagar.	Utgivningsfrekvensen driver inte längre DNS-arbetsbelastningen.

Vad är DNS-kopplingar?

Persistent DCV minskar hur ofta DNS-ändringar behövs; DNS-kopplingar hanterar de ändringar som återstår. En DNS-koppling är en integration mellan en certifikatlivscykelplattform och en DNS-leverantör som låter plattformen skapa, uppdatera och validera TXT-poster programmatiskt, via leverantörens API, snarare än att be en DNS-administratör att göra varje ändring manuellt.

Detta är viktigt eftersom den långsammaste delen av DNS-baserad validering vanligtvis inte är DNS-sökningen utan den mänskliga överlämningen. Ett certifikatteam begär en post, ett nätverksteam schemalägger ändringen, ett godkännandefönster godkänns och först då kan valideringen slutföras. Vid en årlig kadens är den fördröjningen tolererbar. Vid en kadens av dussintals valideringar per domän per år blir den den dominerande källan till både driftstörningar och avbrottsrisker, eftersom en förnyelse kan misslyckas helt om dess valideringspost inte är på plats i tid. Anslutningar tar bort överlämningen: plattformen kommunicerar direkt med DNS-leverantören och posten visas, valideras och hanteras utan en supportförfrågan.

Hur persistenta DCV- och DNS-kopplingar fungerar tillsammans

De två funktionerna kompletterar varandra, inte är utbytbara. Persistent DCV eliminerar DNS-kontaktpunkter under förnyelsecykeln. DNS-kopplingar automatiserar de DNS-ändringar som fortfarande är nödvändiga, inklusive publicering av den initiala persistenta posten och onboarding av nya domäner. Tillsammans ger de ett team två distinkta verktyg:

• Där en beständig post kan användas tas DNS-ändringar under förnyelsen bort helt, så utgivningsfrekvensen driver inte längre DNS-arbetsbelastningen.
• Om en DNS-ändring fortfarande krävs (nya domäner, initial installation, leverantörer utan permanent stöd), kör en koppling den automatiskt, utan manuell samordning.

Nettoeffekten är ett valideringsarbetsflöde som skalas upp smidigt i takt med att både certifikatvolymen och förnyelsefrekvensen ökar, vilket är precis vad tidsfristerna 2027 och 2029 kräver.

DCV-automation: Krav, fellägen och övervakningssignaler

Använd den här tabellen för att mappa varje DCV-automationskrav till dess valideringsmetod, felläget när kravet inte uppfylls, övervakningssignalen som visar felet och den auktoritativa policykällan. CA/Browser Forum SC-081v3 och SC-088v3 granskas kvartalsvis och kan uppdateras oberoende av varandra.

Krav	Valideringsmetod	Feltillstånd	Övervakningssignal	Policykälla
Permanent TXT-post löses korrekt från alla auktoritativa namnservrar	Fråga _validation-persist.[domain] från flera DNS-resolvrar i olika geografiska regioner; bekräfta att samma postvärde returneras från alla resolvrar; testa med publika DNS-resolvrar (Google 8.8.8.8, Cloudflare 1.1.1.1); DNS-valideringskontroll för CLM-plattformen	DNS-spridningsfördröjning eller zonöverföringsgap gör att CA:s valideringskontroll misslyckas ur ett eller flera perspektiv; MPIC (CA/Browser Forum SC-067) kontrollerar nu CAA och DCV från flera nätverksplatser, så en inkonsekvens som är synlig från en region misslyckas med valideringen; förnyelse misslyckas trots att posten verkar korrekt från en enda utgångspunkt.	CLM-plattformsvarning om DCV-valideringsfel för en domän med en permanent post på plats; certifikatförnyelsefel korrelerat med DNS-spridningsfel i CA-loggar; DNS-övervakningsvarning om TXT-postspridningsfel till en eller flera auktoritativa namnservrar	CA/Browser Forum Ballot SC-088v3 (DNS-PERSIST-01, november 2025); Ballot SC-081v3 (återanvändningsperioder för DCV); Ballot SC-067 (MPIC, september 2025)
API-uppgifterna för DNS-anslutningen är giltiga, begränsade och testade	Testa en skriv-validera-borttagningscykel för TXT-poster genom anslutningen innan något produktionscertifikat är beroende av den; bekräfta att autentiseringsuppgifterna har skrivåtkomst till TXT-poster begränsad till de specifika zoner som är involverade (inte kontoövergripande); verifiera autentiseringsuppgifternas utgångsdatum; kalenderkvartalsvis rotation och test efter rotation	Anslutning med skrivskyddade, utgångna eller överskridna API-autentiseringsuppgifter misslyckas tyst vid nästa schemalagda körning; DNS-ändring görs inte; CA:s valideringskontroll hittar ingen post; förnyelse misslyckas; felet kan visas som ett DCV-fel snarare än ett autentiseringsuppgifterfel, vilket gör diagnosen långsammare.	CLM-plattformsvarning vid fel på anslutningsanrop; DNS-leverantörsgranskningslogg som visar misslyckad API-autentisering; topp i certifikatförnyelsefel korrelerad med utgångsdatum för autentiseringsuppgifter; instrumentpanel för hälsokontroll av anslutningen som visar tidsstämpeln för den senaste lyckade skrivningen	CA/Browser Forum-omröstning SC-081v3 (återanvändningsperioder för DCV som kräver automatisk validering); dokumentation för autentisering av DNS-leverantörs-API; intern policy för rotation av autentiseringsuppgifter
Kontoinnehavaren för beständiga poster matchar det aktiva ACME-kontot för varje utfärdande CA.	Jämför accounturi-värdet i TXT-posten _validation-persist med ACME-konto-URL:en som returneras av CA:ns kontoslutpunkt (RFC 8555 avsnitt 7.3); bekräfta att kontot är aktivt och inte inaktiverat; testa att CA:n accepterar den permanenta posten för en testutfärdande.	En beständig post som skapats för fel konto (fel CA, migrerat konto eller roterad konto-URL) validerar för fel CA eller validerar inte alls; certifikatförnyelsen misslyckas; CA returnerar ett DCV-fel som inte explicit anger konto-urin-matchningen, vilket gör diagnosen långsam.	CLM-plattformens DCV-valideringsfel för en domän med en permanent post; CA-felsvar som anger att kontot inte är auktoriserat eller att posten inte känns igen; CLM-plattformsvarning om permanent postkontovärde har ändrats sedan senaste granskning	CA/Browser Forum-omröstning SC-088v3 avsnitt 3.2.2.4.22 (krav på accounturi-fält); RFC 8657 (stabilitet vid ACME-kontonyckelöverföring); RFC 8555 avsnitt 7.3.5 (stabilitet vid konto-URL över nyckelrotationer)
Persistent post övervakas för obehöriga ändringar	Konfigurera DNS-övervakning för TXT-posten _validation-persist.[domain] som varnar vid alla värdeändringar; bekräfta övervakningsplattformens kontroller från flera geografiska platser; testa varningen genom att tillfälligt ändra postvärdet i en icke-produktionszon.	En obehörig ändring av den beständiga posten upptäcks inte; den modifierade posten kan ge en annan CA- eller ACME-konto behörighet att utfärda certifikat för domänen; eftersom posten är permanent snarare än per förnyelse, är exponeringsfönstret kontinuerligt snarare än begränsat av en förnyelsecykel.	DNS-övervakningsvarning vid ändring av _validation-persist TXT-postvärde; CLM-plattformsvarning vid oväntad ändring av CA eller konto i den permanenta posten; extern DNS-övervakningstjänstvarning vid postmodifiering	CA/Browser Forum-omröstning SC-088v3 (säkerhetskrav för beständiga register); RFC 8555 avsnitt 7.5.2 (deaktivering av ACME-konto för att återkalla utfärdandebehörighet); CA/Browser Forum-grundkrav avsnitt 4.9 (skyldigheter för återkallelse av certifikat)
DCV-automatisering körs enligt ett schema som är anpassat till förnyelsetakten	Bekräfta att CLM-plattformen är konfigurerad för att köra domänvalidering före varje förnyelse med en frekvens som håller sig inom det tillämpliga DCV-återanvändningsfönstret (200 dagar till och med mars 2027, 100 dagar till och med mars 2029, 10 dagar från mars 2029); testa att DCV körs automatiskt utan manuell utlösare; bekräfta CA-agnostisk schemaläggning så att samma automatisering gäller oavsett vilken offentlig CA som utfärdar certifikatet.	DCV-automatisering är inte schemalagd eller är konfigurerad för ett återanvändningsfönster som är längre än den tillämpliga gränsen; CA:s DCV-bevis löper ut före nästa förnyelse; CA vägrar att utfärda eftersom domänvalideringsdata är inaktuella; detta felläge blir vanligare när återanvändningsfönstret krymper	CLM-plattformsvarning om att DCV-bevisets utgång närmar sig förnyelsedatum; certifikatförnyelsefel med hänvisning till utgångna DCV-bevis i CA-loggar; CLM-plattformsinstrumentpanelen visar domäner med DCV:s senaste tidsstämpel som är äldre än det tillämpliga återanvändningsfönstret.	CA/Browser Forum-omröstning SC-081v3 (DCV-återanvändningsperioder: 200 dagar mars 2026, 100 dagar mars 2027, 10 dagar mars 2029); CA/Browser Forum-grundkrav avsnitt 3.2.2.4 (DCV-metodkrav)

Förutsättningar innan du implementerar

Bekräfta att dessa är på plats innan du implementerar permanenta DCV- eller DNS-kopplingar, så att utrullningen inte stannar halvvägs:

1. En aktuell certifikatinventering. Du behöver en lista över alla offentligt betrodda certifikat och den/de domän(er) det täcker, baserat på identifiering, innan du kan avgöra vilka domäner som kvalificerar sig för permanent DCV.
2. API-åtkomst till varje DNS-leverantör som används. DNS-kopplingar autentiserar mot leverantörens API (Route 53, Cloudflare, Azure DNS, Google Cloud DNS och liknande), så du behöver API-autentiseringsuppgifter med behörighet att skriva TXT-poster, begränsade till de berörda zonerna.
3. Ett CA-konto som stöder ACME och, där det är tillgängligt, DNS-PERSIST-01. Bekräfta vilka av era utfärdande CA:er som redan stöder ihållande DCV, eftersom det är en nyligen tillåten metod som CA:er fortfarande rullar ut.
4. En namngiven ägare för godkännande av DNS-ändring. Även automatiserade DNS-ändringar behöver en definierad ägare av register för granskningsändamål, vanligtvis plattforms- eller infrastrukturteamet.
5. En plattform för hantering av certifikatlivscykeln såsom CertSecure-hanterare kapabel att schemalägga återkommande DCV och köra DNS-anslutningsanrop, snarare än engångsskript.

Steg-för-steg implementeringsarbetsflöde

När ovanstående förutsättningar är uppfyllda följer utrullningen fem steg. Varje steg anger det resultat du bör se innan du går vidare till nästa.

Steg 1: Inventera certifikatförmögenheten

Upptäck alla offentligt betrodda certifikat, med särskild uppmärksamhet på de som löper ut efter den 15 mars 2026. Upptäcktsluckor, certifikat som ingen kommer ihåg, är den enskilt största källan till tysta avbrott. Märk varje certifikat med dess ägande domän, SAN-lista och företagsägare. Resultat: en komplett, ägartaggad inventering av den offentliga TLS-egendomen.

Steg 2: Registrera DNS-leverantörer

Anslut varje DNS-leverantör som är värd för dina zoner till certifikatlivscykelplattformen med hjälp av dess API-inloggningsuppgifter, så att DNS-01-utmaningsposter kan skapas och verifieras programmatiskt. Detta eliminerar den manuella överlämningen mellan certifikat- och DNS-team. Resultat: varje DNS-leverantör i databasen är ansluten och plattformen kan skriva en test-TXT-post utan en manuell supportförfrågan.

Figur 1. Onboarding av DNS-leverantör och konfiguration av DNS-01-anslutning i CertSecure Manager.

Steg 3: Publicera den permanenta valideringsposten

För domäner som kvalificerar sig, publicera den engångs-TXT-posten på _validation-persist.[domain] i formatet som visades tidigare, med hjälp av connectorn istället för en manuell DNS-biljett. Prioritera SAN- och jokerteckendomäner först, eftersom de har den högsta koordineringskostnaden enligt den gamla modellen. Resultat: den persistenta posten löses korrekt och den utfärdande CA:n bekräftar att den känner igen kontot.

Steg 4: Konfigurera schemalagd DCV-automation

Ställ in certifikatlivscykelplattformen så att den kör återkommande domänvalidering i linje med den förnyelsetakt som dina certifikat nu kräver, istället för att utlösa validering manuellt vid varje förnyelse. Håll detta CA-agnostiskt så att samma schema gäller oavsett vilken offentlig CA som utfärdar ett givet certifikat. Resultat: DCV körs automatiskt före varje förnyelse, utan några åtgärder per cykel.

Figur 2. Schemalagd DNS-01-domänvalideringsstatus i CertSecure Manager.

Steg 5: Validera, övervaka och ställ in återställningsskydd

Bekräfta att en fullständig förnyelsecykel slutförs från början till slut utan manuell åtgärd, aktivera sedan övervakning för den beständiga posten (oväntade ändringar av den är en varningssignal) och för fel på anslutningsanrop. Dokumentera återställningsvägen innan du behöver den. Resultat: minst en fullständig automatiserad förnyelsecykel slutförs korrekt, med aviseringar på plats för posten och anslutningen.

Återställningsvägledning och vanliga fel

Vanliga fel att se efter

• DNS-spridningsfördröjningar. En nyskriven TXT-post som inte har spridits över alla auktoritativa namnservrar kommer att orsaka att CA:s valideringskontroll misslyckas; bygg in en spridningskontroll i arbetsflödet innan utfärdandet utlöses.
• API-autentiseringsuppgifternas omfattning är för smal eller har löpt ut. En DNS-anslutning med skrivskyddade eller utgångna API-autentiseringsuppgifter kommer att misslyckas tyst vid nästa schemalagda körning; rotera och testa autentiseringsuppgifterna i en kalender, inte bara när en förnyelse misslyckas.
• Beständig post publicerad under fel CA-konto. Eftersom accounturi-värdet kopplar posten till ett specifikt ACME-konto kommer en post som skapats för fel konto att validera för fel CA eller inte alls.
• Ingen övervakning av själva den beständiga posten. Eftersom posten godkänner utfärdande löpande är en obemärkt ändring av den en händelse med större påverkan än en missad engångsvalidering tidigare.

Rulla tillbaka säkert

Om persistent DCV behöver återställas för en domän, ta antingen bort TXT-posten _validation-persist eller inaktivera det associerade ACME-kontot (RFC 8555 avsnitt 7.5.2), vilket återkallar utfärdandebehörigheten omedelbart. Håll konventionell DNS-01-validering tillgänglig som en reservväg för alla domäner som migreras till persistent DCV och testa den reservvägen innan du förlitar dig på den i produktion. För DNS-anslutningar, inaktivera den specifika leverantörsintegrationen istället för att återkalla plattformsomfattande API-åtkomst, så att andra leverantörer fortsätter att fungera medan du felsöker.

Matris från förutsättning till handling

Förutsättning	Handling	Ägande team
Certifikatförteckning ofullständig	Kör identifiering över offentliga och privata nätverk; tagga varje certifikat med domän, SAN-lista och ägare	PKI/certifikatteam
Åtkomst till DNS-leverantörens API har ännu inte beviljats	Begär scoped API-autentiseringsuppgifter med skrivbehörighet för TXT-poster för varje leverantör	Plattforms-/infrastrukturteam
CA stöder ännu inte DNS-PERSIST-01	Bekräfta permanent DCV-stöd direkt med varje utfärdande CA; använd konventionell DNS-01 med kopplingar under tiden	PKI/certifikatteam
Ingen namngiven ägare för automatiska DNS-ändringar	Tilldela och dokumentera en registeransvarig för revisionsändamål	Säkerhets-/efterlevnadsteam
Ingen schemalagd DCV-automatisering i livscykelplattformen	Konfigurera återkommande, CA-agnostisk domänvalidering anpassad till förnyelsekadens	PKI/certifikatteam

Före och efter: DNS-valideringsåtgärder

Operativt steg	Före (manuell)	Efter (persistenta DCV + DNS-kopplingar)
Begär en DNS-ändring	Ärendet har skickats in till nätverksteamet, i kö efter andra ändringsförfrågningar	Certifikatplattformen skriver posten direkt via leverantörens API
Validerar domänägande	Upprepas vid varje förnyelse, upp till ~35 gånger per år per domän senast 2029	Engångspost publicerad för etablerade domäner; inget DNS-arbete per förnyelse
Godkännandevändning	Timmar till dagar, beroende på fönster för ändringshantering	Minuter, eftersom inget mänskligt godkännande finns i DNS-sökvägen
Felpunkt vid hög förnyelsefrekvens	Missad eller försenad DNS-ändring gör att själva förnyelsen misslyckas	Förnyelsen sker oberoende av DNS, när den permanenta posten är på plats
Verifieringskedja	Spridda över ärendesystem, DNS-konsol och CA-portal	Centraliserad i certifikatlivscykelplattformens anslutnings- och DCV-loggar

Beslutstabell: Vilken DNS-01-automatiseringsväg passar din organisation

Inte alla fastigheter behöver samma utgångspunkt. Använd tabellen nedan för att matcha din nuvarande miljö med rätt nästa steg.

Din situation	Rekommenderad väg	Varför
Litet dödsbo (färre än 50 offentliga certifikat), årlig förnyelsetakt idag	Fortsätt med manuell eller manusbaserad förnyelse på kort sikt, men planera för 100 dagars giltighet senast i mars 2027	Förnyelsevolymen är fortfarande tillräckligt låg för att absorberas manuellt, men tröskeln för 2027 fyrdubblar ungefär förnyelsefrekvensen.
DNS-ändringar går igenom en ärende- eller ändringshanteringsprocess	Prioritera DNS-kopplingar först	Tar bort den mänskliga överlämningen som blir felpunkten när valideringen måste upprepas med några veckors mellanrum.
Stor eller SAN/wildcard-tung egendom som spänner över flera domäner	Använd permanent DCV (DNS-PERSIST-01) för etablerade domäner, i kombination med DNS-kopplingar för nya domäner	Tar helt bort DNS-arbetet per förnyelse för domäner som redan validerats, vilket minskar antalet DNS-ändringar från hundratals per år till en engångsinstallation per domän.
Multimoln- eller hybrid-PKI-miljö som omfattar flera publika och privata CA:er	Implementera CA-agnostisk automatisering som CertSecure Manager v3.3, som kombinerar schemalagd DCV, DNS-kopplingar och centraliserad granskningsloggning	Håller valideringen konsekvent och granskningsbar oavsett vilken offentlig eller privat CA som utfärdar ett givet certifikat, och undviker att arbetsflödet behöver byggas om vid konsolidering av CA:er eller molnleverantörer

Ägare och åtgärdsmatris per team

Team	Ansvar	Nyckelåtgärd
PKI/certifikatteam	Äger certifikatinventeringen och CA-relationerna	Identifiera vilka domäner som kvalificerar sig för permanent DCV och sekvensera utrullningen efter risk (SAN/jokertecken först)
Säkerhetsteam	Äger skydd av autentiseringsuppgifter och nyckeluppgifter	Hantera ACME-kontonycklar bakom beständiga poster som känsliga inloggningsuppgifter; övervaka obehöriga ändringar
Plattforms-/infrastrukturteam	Äger DNS-leverantörsåtkomst och API-inloggningsuppgifter	Bevilja och rotera scoped DNS API-inloggningsuppgifter; anslut varje leverantör till livscykelplattformen
Compliance-teamet	Äger revisionsbevis för reglerade ramverk	Bekräfta att DCV- och anslutningsaktivitet loggas, behålls och mappas till DORA-, NIS2- eller FedRAMP/CMMC-kontrollkrav.

Framgångsmått att spåra efter implementering

Spåra dessa mätvärden före och efter utrullningen så att automatiseringens effekt är mätbar snarare än antagen. Om du har verkliga siffror från din egen miljö, rapportera dem per kvartal snarare än som en engångssiffra.

• Sparad förnyelsetid per certifikat, jämförande av manuell DNS-koordinering med anslutningsdriven validering.
• Antal certifikat under schemalagd, CA-agnostisk DCV-automatisering, som en procentandel av den totala offentliga TLS-egendomen.
• Minskning av manuella DNS-ändringsärenden inlämnad för certifikatvalidering.
• Certifikatrelaterade avbrott eller tillbud, spåras kvartalsvis mot baslinjen före automatisering.
• Implementeringstid för att registrera en ny DNS-leverantör eller domän i det automatiserade arbetsflödet.

Vi har inte kopplat någon specifik förstapartsreferenssiffra till dessa mätvärden här, eftersom vi hellre rapporterar en verifierad siffra från en slutförd utrullning än en uppskattning. Om du spårar dessa internt kan vårt PKI-tjänsteteam hjälpa dig att beräkna och rapportera dem.

Vad göra här näst

• PKI-team: Kör ett Discovery Pass nu och flagga alla certifikat som löper ut efter den 15 mars 2026 för prioriterad migrering.
• Säkerhetsteam: Lägg till ACME-kontonycklar till ditt befintliga program för övervakning av hemligheter innan du implementerar permanent DCV i stor skala.
• Plattformsteam: begär åtkomst till DNS-leverantörens API detta kvartal så att onboarding av anslutningssystemet inte blockeras senare av en fördröjning i autentiseringsuppgifterna.
• Compliance-team: bekräfta att ert revisionsramverk redan accepterar automatiserade DCV-loggar som bevis, eller lyft fram luckan nu.

CertSecure Manager v3.3: CA-Agnostic DNS-01 Automation

CertSecure Manager är Encryption Consultings leverantörsneutrala plattform för hantering av certifikatlivscykeln. Dess CA-agnostiska design innebär att ett enda kontrollplan upptäcker, utfärdar, förnyar och styr certifikat för varje auktoritet som en organisation använder, så att giltighets- och valideringsändringar hanteras centralt snarare än auktoritet för auktoritet, och ett certifikat kan utfärdas på nytt från en annan CA om en avbryts.

Denna neutralitet är viktigast på det offentliga förtroendelagret, där tidslinjen på 47 dagar har störst inverkan. CertSecure Manager integreras direkt med de stora leverantörerna av offentliga förtroendecertifikat, inklusive DigiCert , GlobalSign , Sectigo, Let's Encrypt och Google Public CA, tillsammans med privata certifikatutfärdare som Microsoft AD CS, AWS Private CA och HashiCorp Vault. Oavsett vilken offentlig certifikatutfärdare som utfärdar ett givet certifikat styrs identifiering, utfärdande, förnyelse och validering från samma konsol, vilket är exakt den onboarding av DNS-leverantör och schemalagda DCV-skärmar som gicks igenom i implementeringsstegen ovan.

För organisationer som vill hantera eller automatisera DNS-01-validering specifikt är CertSecure Manager v3.3 byggd för just denna övergång. Encryption Consulting stöder aktivt team med att:

• Registrera deras publika DNS-leverantörer genom att ansluta leverantörerna som är värdar för dina DNS-zoner, så att DNS-01-utmaningsposter skapas och verifieras programmatiskt över en mängd olika leverantörer. Detta eliminerar den manuella överlämningen mellan certifikat- och DNS-team.
• Hantera DCV genom schemalagd automatisering genom att köra återkommande domänvalidering i linje med den förnyelsekadens som 100-dagars- och 47-dagarscertifikat kräver, så att DNS-01-bevis förblir aktuella utan ingripanden per cykel.
• Håll valideringen CA-agnostisk genom att tillämpa samma DNS-01-automatisering oavsett vilken offentlig CA som utfärdar certifikatet, så att konsolidering eller byte av leverantörer inte kräver att valideringsarbetsflödet återuppbyggs.
• Bygg automatiseringsklara arbetsflöden över hela databasen genom kontinuerlig identifiering, policytillämpning och zero-touch-förnyelseagenter, så att förnyelser i maskintakt inte leder till proportionell manuell ansträngning.

Målet är den operativa modell som den nya tidslinjen antar: domänvalidering behandlas som ett samordnat, automatiserat system snarare än en engångsuppgift som upprepas vid varje förnyelse. Att engagera sig tidigt genom inventering, onboarding av DNS-leverantörer och schemalagd DCV-automatisering ger teamen en prioriterad färdplan långt innan de obligatoriska tröskelvärdena träder i kraft.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är specialister på tillämpad kryptografi och PKI. Utöver att tillhandahålla CertSecure Manager , hjälper vår PKI-tjänsteverksamhet organisationer att operationalisera övergången till kortare certifikatlivslängder från början till slut, från första inventering till helautomatisk, CA-agnostisk domänvalidering. Vi hjälper team att:

• Bedöm om TLS-certifikatet är berett efter 47 dagar. Upptäck alla offentligt betrodda certifikat, avslöja luckor i certifikatidentifieringen som orsakar tysta avbrott och skapa en prioriterad migreringsfärdplan mot milstolparna 2026 till 2029.
• Automatisera DNS-01-validering. Registrera dina publika DNS-leverantörer och genomför schemalagd, CA-agnostisk domänvalidering, inklusive persistent DCV (DNS-PERSIST-01) för etablerade domäner, så att förnyelser frikopplas från manuellt DNS-arbete.
• Implementera och integrera CertSecure Manager. Stärk plattformen för era publika och privata certifikatutfärdare, med förnyelseagenter för zero-touch-förnyelse på webbservrar, lastbalanserare och interna applikationer.
• Designa och driva PKI. Detta omfattar PKI-design och implementering, tillsammans med hanterade alternativ genom PKI-som-en-tjänst och HSM-som-en-tjänst, inklusive skydd av ACME-kontonycklarna som ihållande DCV gör säkerhetskritiska.
• Bygg kryptoflexibilitet och PQC-beredskap. Detta innebär efterlevnad av CA/Browser Forum, RFC-anpassad validering och post-quantum-beredskap byggd på vår PQC:s kompetenscentrum och 9-fas PQC-beredskap färdplan, stödd av en levande CBOM-säkerhet inventering av varje kryptografisk tillgång i din ägo, så att den automatisering du bygger nu bär upp nästa övergång. CBOM: från inventering till intelligens guidade vägledningar genom att omvandla det lagret till ett handlingsbart kryptoagilitetsprogram.

För att bedöma era certifikattillgångar mot tidslinjen på 47 dagar och skapa en DNS-01-automatiseringsplan, prata med Encryption Consultings PKI Services-team.

Relaterad läsning från Encryption Consulting

Ytterligare resurser om deadlines, protokoll och automatisering som diskuterats ovan:

• CA/Browser Forum-mandatet täcker giltighetsminskningarna, deadline för dubbel EKU i juni 2026 och vad de kräver.
• Offentlig CA kontra privat CA förklarar när man ska använda varje punkt och hur man bygger automatisering för 47-dagars tidslinjen.
• Att välja ett certifikatregistreringsprotokoll jämför ACME, EST, SCEP och CMP för kortlivade certifikat.
• Vad är ACME-protokollet förklarar hur challenge-response-validering, inklusive DNS-01, faktiskt fungerar.
• ACME-klienter på Linux täcker Certbot, acme.sh, DNS-leverantörstäckning och var central styrning passar in.
• Skalning av certifikatlivscykeloperationer med automatisering visar hur man förvandlar frekventa förnyelser till en händelsedriven, hands-off-process.
• CertSecure Manager v3.3 specificerar vad utgåvan lägger till för den högre förnyelsekadensen.
• Centralisera Let's Encrypt och DNS-01-utgivning med CertSecure Manager täcker DNS-01-utmaningsvalidering över publika DNS-leverantörer, styrt centralt.
• Guide för migrering av kvantkryptografi efter kvantkryptering (9 faser) lägger fram färdplanen för algoritmövergången som följer den nuvarande certifikatlivslängden och valideringsändringarna.
• Hur man bygger ett kryptografiskt inventarium (CBOM) utökar identifieringsdisciplinen i den här artikeln från TLS-certifikat till hela din kryptografiska tillgång.
• CBOM: Från inventering till intelligens visar hur man omvandlar en kryptografisk inventering till ett pågående program för kryptoagilitet och PQC-beredskap.

Slutsats

Utvecklingen är fastställd. År 2029 kommer publika TLS-certifikat att gälla i 47 dagar och bevis för domänvalidering kommer att löpa ut var tionde dag. Detta förvandlar det som en gång var en årlig formalitet till en kontinuerlig operativ uppgift. Manuella DNS-uppdateringar och e-postbaserad validering kan inte hålla den takten. Persistent DCV (DNS-PERSIST-01) tar bort DNS-ändringen per förnyelse för etablerade domäner, och DNS-kopplingar automatiserar de ändringar som återstår; tillsammans låter de domänvalidering skalas med utfärdandefrekvensen istället för att brytas under den.

De organisationer som smidigt navigerar denna övergång kommer att vara de som förbereder sig innan tröskelvärdena träder i kraft. De inventerar sina tillgångar, registrerar sina DNS-leverantörer och flyttar domänvalidering till schemalagd, CA-agnostisk automatisering nu, medan 200-dagars certifikat fortfarande lämnar utrymme för justeringar. Domänvalidering håller på att bli bakgrundsinfrastruktur; uppgiften framför oss är att få den att fungera korrekt innan deadline 2027 tvingar fram problemet.

Det här inlägget granskas kvartalsvis med hänsyn till de aktiva policyschemana för CA/Browser Forum SC-081v3 och SC-088v3, och omedelbart när CA/Browser Forum uppdaterar återanvändningsperioder för DCV, lägger till nya beständiga DCV-krav eller en större DNS-leverantör ändrar API-autentiseringsbeteendet.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen från den här guiden om beständiga DCV- och DNS-kopplingar?

Giltighetstiden för offentliga TLS-certifikat krymper till 47 dagar i mars 2029, vilket tvingar domänägande att bevisas på nytt ungefär 35 gånger per år per domän. Persistent DCV (DNS-PERSIST-01) tar bort DNS-arbete per förnyelse för etablerade domäner genom att använda en stående TXT-post, och DNS-kopplingar automatiserar de DNS-ändringar som fortfarande finns kvar. Tillsammans är de det som gör att domänvalidering skalas med utfärdandefrekvensen istället för att bli nästa flaskhals.

Varför är detta viktigt för hantering av företagscertifikats livscykel?

Hantering av certifikatlivscykeln kämpar redan med insyn: DigiCerts forskning från 2026 visade att endast 34 % av organisationerna har en komplett, aktuell bild av sina certifikat. I takt med att förnyelsefrekvensen åttafaldigas fram till 2029, kommer alla manuella steg i valideringen, särskilt DNS-koordinering, att multipliceras till en proportionellt större källa till missade förnyelser och avbrott, såvida det inte automatiseras i förväg.

Vilka team är ansvariga för att agera utifrån denna vägledning?

Fyra team delar vanligtvis på detta arbete: PKI- eller certifikatteamet äger inventeringen och CA-relationerna, plattforms- eller infrastrukturteamet äger DNS-leverantörsåtkomst och onboarding av anslutningar, säkerhetsteamet äger skyddet av ACME-kontonycklarna som persistent DCV förlitar sig på, och compliance-teamet äger ansvarigt för att säkerställa att automatiserad valideringsaktivitet loggas för revisionsändamål. Ägar-/åtgärdsmatrisen ovan beskriver detta i detalj.

Vilka risker ökar om detta ämne hanteras manuellt?

DigiCerts Trust Pulse-undersökning visade att 45 % av företagen hade certifikatrelaterade driftstopp under det senaste året, varav 37.5 % kunde spåras direkt till ett utgånget certifikat. Över hälften av dessa incidenter orsakade 5 till 24 timmars driftstopp. Manuell DNS-koordinering är den vanligaste felpunkten när valideringen måste upprepas med några veckors mellanrum istället för en gång om året, eftersom en enda missad eller försenad DNS-ändring kan orsaka att själva förnyelsen misslyckas.

Hur minskar automatisering risken för certifikatavbrott?

Automatisering tar bort den mänskliga överlämningen, ärendekön och godkännandefönstret som finns i DNS-sökvägen idag. Persistent DCV eliminerar DNS-steget helt för etablerade domäner, och DNS-kopplingar utför eventuella återstående DNS-ändringar via leverantörens API på minuter istället för timmar eller dagar. Eftersom förnyelse inte längre är beroende av att en människa slutför en DNS-ändring i tid, tas det vanligaste felläget bakom certifikatavbrott bort.

Vilka mätvärden bör team spåra efter implementeringen?

Spåra sparad förnyelsetid per certifikat, andelen publika TLS-tillgångar under schemalagd CA-agnostisk DCV-automatisering, minskningen av manuella DNS-ändringsärenden, certifikatrelaterade avbrott eller nära-missar jämfört med en baslinje före automatisering, och distributionstid för onboarding av nya DNS-leverantörer eller domäner. Rapportera dessa kvartalsvis så att trenden, inte bara en enskild ögonblicksbild, visar om automatiseringen håller i sig när förnyelsefrekvensen ökar.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

CA/Browser Forums Ballot SC-081v3-schema minskar den maximala giltighetstiden för TLS-certifikat till 200 dagar den 15 mars 2026, 100 dagar den 15 mars 2027 och 47 dagar den 15 mars 2029, med återanvändningsperioder för DCV som krymper till 10 dagar inom samma tidsram. Persistenta DCV- och DNS-kopplingar är de specifika mekanismer som gör det operativt möjligt att nå den kadensen utan en proportionell ökning av manuellt DNS-arbete.

Hur bör detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Använd en CA-agnostisk certifikatlivscykelplattform, till exempel CertSecure Manager, som tillämpar samma schemalagda DCV- och DNS-anslutningslogik oavsett vilken offentlig eller privat CA som utfärdar ett givet certifikat, och oavsett vilket moln som är värd för DNS-zonen. Detta undviker att valideringsarbetsflödet måste byggas om varje gång ett certifikat utfärdas på nytt från en annan CA eller en DNS-zon flyttas mellan leverantörer, vilket är vanligt i multimoln- och hybrid-PKI-områden.

Vilka förkunskaper krävs innan implementering?

Du behöver en aktuell, ägartaggad certifikatinventering; API-autentiseringsuppgifter med skrivåtkomst till TXT-poster för varje DNS-leverantör som används; bekräftelse på vilka utfärdande certifikatutfärdare som stöder DNS-PERSIST-01 idag; en namngiven ägare för automatiskt godkännande av DNS-ändringar; och en certifikatlivscykelplattform som kan schemalägga återkommande DCV och köra DNS-anslutningsanrop. Avsnittet om förutsättningar ovan täcker vart och ett av dessa i detalj.

Vilka vanliga misstag bör team undvika?

De vanligaste misstagen: publicering av en permanent post under fel ACME-konto (accounturi-matchningen gör att CA avvisar posten i tysthet); att inte övervaka _validation-persist-posten för obehöriga ändringar (en permanent post är ett mål med högre värde än en post som uppstår per förnyelse); att inte spridningskontrollera en nyskriven TXT-post innan utfärdandet utlöses (DNS-spridningsfördröjning gör att CA:s MPIC-baserade multiperspektivkontroll misslyckas från en region); och att inte rotera DNS-anslutningens API-inloggningsuppgifter i en kalender (utgångna inloggningsuppgifter misslyckas i tysthet vid nästa schemalagda körning, inte när de löper ut).

Vad bör uppdateras kvartalsvis för DCV-automationsstyrning?

Kvartalsvis: bekräfta att alla beständiga poster löses korrekt och matchar auktoriserade ACME-konton; rotera och testa DNS-anslutningens API-autentiseringsuppgifter; granska anslutningens anropsfelloggar för föregående kvartal; granska nya domäner som lagts till sedan den senaste granskningen för att säkerställa täckning av beständiga poster; verifiera CA/Browser Forum SC-081v3 och SC-088v3 för uppdateringar av DCV-återanvändningsperioder eller krav på beständiga poster; och bekräfta PQC:s beredskapsplanering för ACME-nyckelalgoritmer genom PQC Center of Excellence . Detta inlägg granskas kvartalsvis med hänsyn till det aktiva policyschemat för CA/Browser Forum.