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

Domänkontrollvalidering (DCV) är det steg där en certifikatutfärdare bekräftar att den som begärt ett certifikat faktiskt kontrollerar domänen det gäller. För de flesta team har det varit en uppgift som sker en gång om året, hanterad i det tysta tillsammans med en förnyelse. Det antagandet gäller inte längre. CA/Browser Forum-mandatet har låst in ett fast schema som minskar certifikatens livslängd från 398 dagar idag till 47 dagar år 2029, och det skärper hur länge domänvalideringsbevis kan återanvändas samtidigt. När ett certifikat måste utfärdas på nytt var sjätte till sjunde vecka måste valideringen bakom det hålla jämna steg.

Två funktioner gör den takten hållbar: persistent DCV (DNS-PERSIST-01-metoden), en valideringsmetod som låter en domän verifieras på nytt mot en enda post som publiceras en gång, och DNS-kopplingar, som automatiserar de DNS-ändringar som validering fortfarande kräver. Den här artikeln förklarar vad var och en är, de exakta deadlines som tvingar fram ändringen, den operativa matematiken bakom dem och en praktisk väg att förbereda sig för.

Deadlines som driver förändringen

I april 2025 godkände CA/Browser Forum omröstning SC-081v3 med titeln "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 gradvis 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 både DV, OV och EV, inklusive jokertecken- och multidomäncertifikat (SAN).

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 bryter mot 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, vilket motsvarar 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 skalning av certifikatoperationer genom automatisering blir baslinjen. Frågan är vilken form av automatisering som eliminerar den största operativa risken.

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 persistent 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.

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.

Riktlinjer: vad du ska göra innan deadlines går ut

Fönstret för att förbereda sig är öppet men krymper, och den första milstolpen med 200 dagars giltighet har redan trätt i kraft. De organisationer som gör en smidig övergång är de som bygger automatiseringen nu, inte de som reagerar när 100-dagarscertifikat gör manuella arbetsflöden ohållbara år 2027. En praktisk sekvens:

1. Inventera certifikatinnehavet. Upptäck alla offentligt betrodda certifikat, med särskild uppmärksamhet på de som löper ut efter den 15 mars 2026. Upptäcktsluckor, det vill säga certifikat som ingen kommer ihåg, är den enskilt största källan till tysta avbrott.
2. Granska åldrande DCV-poster. Identifiera valideringsdata som närmar sig sitt utgångsdatum för återanvändning så att förnyelser inte misslyckas på grund av brist på aktuella bevis.
3. Prioritera SAN- och jokerteckensdomäner. Dessa har den högsta koordineringskostnaden och den största känsligheten under komprimerade tidslinjer.
4. Använd permanent DCV för etablerade domäner. Publicera permanenta poster nu, innan förnyelsefrekvensen tvingar fram ändringen i stor skala.
5. Automatisera DNS-körning med kopplingar. Anslut dina DNS-leverantörer så att initial installation och onboarding av nya domäner aldrig är beroende av manuella poständringar.
6. Standardisera automatiserad utfärdande. Behandla offentlig TLS-utfärdande som en kontinuerlig tjänst som drivs av ACME eller ett motsvarande protokoll, och sätt en policydeadline för att dra in manuella förnyelser.

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

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örtroende, inklusive DigiCert , GlobalSign , Sectigo, Let's Encrypt och Google Public CA, tillsammans med privata utfärdare som Microsoft AD CS, AWS Private CA och HashiCorp Vault. Oavsett vilken offentlig CA som utfärdar ett givet certifikat styrs identifiering, utfärdande, förnyelse och validering från samma konsol.

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.

En titt på DNS-sektionen i CertSecure Manager visar hur detta fungerar i praktiken:

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

Figur 2. Validering av DNS-01-domän med CertSecure Manager

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.

Viktiga takeaways

• TLS-certifikatets giltighetstid minskar till 200 dagar (2026), 100 dagar (2027) och 47 dagar (2029); återanvändning av DCV minskar till 10 dagar år 2029, fastställt av CA/Browser Forum Ballot SC-081v3.
• Vid 47 dagars giltighetstid med 10 dagars återanvändning måste domänäganderätten bevisas på nytt ungefär 35 gånger per år per domän, vilket är långt utöver vad manuell validering kan klara av.
• Ihållande DCV, den DNS-PERSIST-01 Metoden som introducerades av Ballot SC-088v3 och är tillåten sedan november 2025, låter en domän omvalideras mot en enda TXT-post som publiceras en gång på _validation-persist, utan DNS-ändring per förnyelse och utan säkerhetsförlust.
• DNS-kopplingar automatiserar de DNS-ändringar som kvarstår; tillsammans med ihållande DCV gör de att valideringen skalas med frekvensen.
• CertSecure Manager v3.3 hjälper organisationer att introducera publika DNS-leverantörer och köra schemalagd DCV-automation över en CA-agnostisk egendom, före de obligatoriska deadlines.

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:

• Utvärdera 47-dagars beredskap. Upptäck alla offentligt betrodda certifikat, upptäck brister i identifiering som orsakar tysta avbrott och skapa en prioriterad migreringsfärdplan mot milstolparna 2026 till 2029.
• Automatisera DNS-01-validering. Integrera dina publika DNS-leverantörer och implementera schemalagd, CA-agnostisk domänvalidering, inklusive permanent 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 dina 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.
• Håll dig standardanpassad och kryptoagil. Detta innebär efterlevnad av CA/Browser Forum, RFC-anpassad validering och post-quantum-beredskap, så att den automatisering du bygger nu kan genomföra nästa övergång.

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.

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.

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.