Det pågår en tyst nedräkning över internet. I mars 2029 kommer domänkontrollvalidering (DCV), beviset på att du kontrollerar en domän, bara att vara giltigt i 10 dagar, och ett publikt Transport Layer Security (TLS) -certifikat kommer bara att vara giltigt i 47 dagar. Fram tills nyligen kunde det beviset återanvändas i över ett år, och certifikat kunde vara lika giltiga; sedan den 15 mars 2026 är båda begränsade till 200 dagar. Detta är en av de största förändringarna i hur webben bevisar förtroende, och de flesta team har inte känt av det än.
Du har förmodligen hört talas om 47-dagarscertifikatet . Det är ena halvan av historien. Den andra halvan är 10-dagars domänvalideringsfönstret. Båda spelar roll, och tillsammans omformar de hur du utfärdar och förnyar certifikat. Låt oss gå igenom vad som förändras, varför det händer och hur du förbereder dig utan panik i sista minuten.
Vad är domänkontrollvalidering?
Domänkontrollvalidering, eller DCV, är den kontroll som en certifikatutfärdare (CA) kör innan den utfärdar ett TLS-certifikat. Den bekräftar en enkel sak. Kontrollerar du faktiskt domänen du vill säkra?
Du bevisar kontroll genom att göra något som bara den verkliga ägaren kan göra. Du kan lägga till en speciell DNS-post eller placera en fil på din webbserver. CA letar efter det beviset. Om den hittar det utfärdas certifikatet.
När du har godkänt kontrollen glömmer inte CA:n det direkt. Den kan återanvända beviset under en viss period. Under det fönstret kan du få nya certifikat för samma domän utan att bevisa kontroll igen. Sedan den 15 mars 2026 är det fönstret upp till 200 dagar, en minskning från 398 dagar tidigare. Det är därför det har känts enkelt att förnya. Den svåra delen var redan cachad.
Vad förändras och när?
I april 2025 godkände CA/Browser Forum en åtgärd som heter Ballot SC-081v3 . Forumet är den grupp av CA:er och webbläsartillverkare som sätter reglerna för offentliga certifikat. Webbläsarna bakom Chrome, Safari, Firefox och Edge röstade alla ja.
Valomröstningen gör två saker samtidigt. Den minskar hur länge ett certifikat kan leva och den minskar hur länge domänvalidering kan återanvändas. Båda sker i steg.
| Giltigt datum | Maximal livslängd för certifikat | Maximal återanvändning av domänvalidering |
|---|---|---|
| Fram till 15 mars 2026 | 398 DAYS | 398 DAYS |
| 15 mars 2026 | 200 DAYS | 200 DAYS |
| 15 mars 2027 | 100 DAYS | 100 DAYS |
| 15 mars 2029 | 47 DAYS | 10 DAYS |
Observera att återanvändningsfönstret år 2029 är kortare än själva certifikatet. Den praktiska effekten är enkel. Domänvalidering kommer att behöva ske vid nästan varje förnyelse, inte bara då och då.
Det finns ytterligare en förändring för certifikat med högre säkerhet. Om du använder certifikat som valideras av organisationen (OV) eller utökad validering (EV) kallas den validerade identitetsinformationen som stöder certifikatets ämnesfält för ämnesidentitetsinformation. Från och med den 15 mars 2026 kan den informationen endast återanvändas i 398 dagar, en minskning från 825. Så din företagsidentitetskontroll går från en ungefär tvåårig cykel till en årlig.
Två snabba anmärkningar. Vissa CA:er utfärdar redan certifikat en eller två dagar under det officiella maximumet, eftersom giltigheten mäts ner till sekunden, så förnya tidigt och ha en buffert. Och dessa regler gäller endast för offentligt betrodda certifikat. En privat intern CA som webbläsare inte litar på, och som är en del av din egen Public Key Infrastructure (PKI), omfattas inte, även om det fortfarande är god hygien att förkorta dess livslängd.
Hur domänvalidering fungerar
För att förbereda sig för mycket mer frekvent validering är det bra att förstå de vanligaste sätten som en certifikatutfärdare (CA) verifierar domänkontroll.
E-postvalidering skickar ett meddelande till en adress som [email protected] och ber dig bekräfta ägarskap genom att följa en länk. Det är enkelt men kräver vanligtvis manuell åtgärd, vilket gör det opraktiskt när valideringen måste upprepas var tionde dag. E-postbaserad validering fasas också gradvis ut av CA/B-forumet under Ballot SC-090.
HTTP-baserad validering (vanligtvis ACME HTTP-01-utmaningen) ber dig placera en liten tokenfil på en specifik sökväg på din webbserver. Det fungerar bra för enskilda servrar men blir svårare att hantera över lastbalanserare, CDN:er och stora distribuerade miljöer.
DNS-baserad validering (vanligtvis ACME DNS-01-utmaningen) kräver att en TXT-post publiceras i din domäns DNS. Det är standardmetoden för jokerteckencertifikat och kan automatiseras helt via DNS-leverantörs-API:er, vilket gör det till det föredragna valet för frekventa certifikatförnyelser och DCV-omvalidering.
Tekniken som knyter ihop allt detta är ACME-protokollet (Automated Certificate Management Environment) , definierat i RFC 8555. ACME automatiserar hela loopen. Din klient begär ett certifikat, CA returnerar en utmaning, din klient publicerar beviset och CA kontrollerar det och utfärdar certifikatet. Inga mänskliga klick krävs. Det är samma protokoll som gjorde automatiserad certifikatutfärdande till standard på den moderna webben.
För denna nya era är DNS-01 med ACME den starkaste vägen. Ett användbart knep är CNAME-delegering. Du pekar valideringsposten till en liten dedikerad zon, så din automatisering berör bara det smala utrymmet och inte din huvudsakliga DNS. En sak till att förvänta sig. CA:er bekräftar nu domänkontroll från flera nätverksplatser samtidigt, en skyddsåtgärd som kallas multiperspektivvalidering som gör attacker som BGP-kapning mycket svårare.
I praktiken innebär det att din validering måste se korrekt ut från alla perspektiv, så en instabil DNS-installation eller en halvfärdig ändring kan orsaka fel. En relaterad regel (Ballot SC-085v2, gällande från och med 15 mars 2026) kräver också att CA:er kontrollerar DNSSEC när det finns, så en trasig DNSSEC-installation kan också orsaka fel.
Varför branschen gör detta
Kortare livstider handlar inte om att göra ditt liv svårare. De åtgärdar en verklig svag punkt.
När ett certifikat eller dess privata nyckel blir stulen, varar skadan så länge certifikatet är giltigt. Webbläsare är inte bra på att snabbt återkalla certifikat, eftersom återkallningskontroller ofta hoppas över eller tar utgång. Ett certifikat med lång livslängd är en långvarig risk. Ett kortvarigt certifikat begränsar skadefönstret på egen hand, ungefär som en nyckel som slutar fungera efter några veckor, även om ingen märkte att den kopierades.
Det finns också en framåtblickande anledning. Branschen förbereder sig för post-kvantkryptografi . NIST slutförde sina tre första post-kvantstandarder den 13 augusti 2024, kända som FIPS 203 (ML-KEM), 204 (ML-DSA) och 205 (SLH-DSA). Att byta algoritmer mellan tusentals certifikat är smärtsamt om allt är långlivat och manuellt. Korta livslängder plus automatisering gör den övergången mycket enklare. Inget av detta är nya råd. NIST SP 1800-16 , en praktikguide om hantering av TLS-servercertifikat, rekommenderade certifikatinventeringar, övervakning och automatisering för flera år sedan. De nya reglerna gör helt enkelt den vägledningen icke-valfri.
Vad det kortare fönstret betyder för dig
Låt oss konkretisera arbetsbelastningen. Ett 47-dagars certifikat behöver förnyas ungefär åtta gånger om året. De flesta team förnyar det ungefär en gång om året idag. Med återanvändningsfönstret på 10 dagar måste domänvalidering ske för nästan alla dessa förnyelser.
Multiplicera nu det över en verklig miljö. Webbservrar, API:er, lastbalanserare, e-postgateways och kortlivade arbetsbelastningar i Kubernetes har alla certifikat. En manuell process som klarar sig bra med en förnyelse per år blir en konstant källa till avbrott när det stiger till åtta. Och ett enda utgånget certifikat kan stänga av ett betalningsflöde, ett API eller en inloggningssida på några sekunder.
Branschanalytiker påpekar samma sak. Gartner noterar att organisationer rutinmässigt drabbas av avbrott på grund av ohanterade certifikat, och att 47-dagarskravet gör hanteringen av certifikatens livscykel ännu mer brådskande . Efterlevnad ökar också pressen, eftersom standarder som PCI DSS förväntar sig stark och aktuell kryptografi på data under överföring. För team med statliga tidslinjer sätter NSA:s CNSA 2.0-svit konkreta milstolpar efter kvantmigrering. FIPS 140-3- validering styr också modulerna som skyddar HSM-baserade nycklar.
Hur man ligger steget före
Du behöver inte lösa allt detta på en gång. Den etappvisa tidslinjen är din väg att gå. Börja här.
- Hitta alla certifikat. Du kan inte förnya det du inte kan se. Bygg en fullständig inventering över moln-, lokala och interna system, och ge varje certifikat en tydlig ägare.
- Automatisera utfärdande och förnyelse. Använd ACME och en metod för hantering av certifikatlivscykeln så att förnyelser sker utan mänsklig inblandning.
- Föredra DNS-01 med delegering. Flytta validering till DNS-poster som drivs av ett API och använd CNAME-delegering för att hålla ändringarna inneslutna.
- Ta bort manuell och e-postvalidering från produktion. Allt som kräver att en person klickar på en länk kommer att sluta fungera med den här hastigheten.
- Övervaka och förnya tidigt. Spåra utgångsdatum, varna innan de inträffar och förnya med en buffert istället för att pressa in den sista dagen.
- Bygga krypto-agility nu. Betrakta snabb, automatiserad rotation som en kärnfunktion. Den skyddar dig idag och förbereder dig för post-kvantmigrering.
Några fällor att undvika. Anta inte att din privata PKI är påverkad, för det är den inte. Glöm inte den årliga identitetskontrollen av OV eller EV, eftersom det steget förblir manuellt. Förlita dig inte på en enda nätverksväg för validering. Och lämna inte ett certifikat utan en namngiven ägare, eftersom föräldralösa certifikat är de som förfaller obemärkt.
Hur krypteringskonsulting kan hjälpa
CertSecure Manager är Encryption Consultings plattform för hantering av certifikatlivscykeln, specialbyggd för att hantera exakt de utmaningar som beskrivs ovan.
Den integreras med befintliga ACME-klienter och fungerar som företagets registreringssystem och policymotor för både offentliga och privata certifikatutfärdare. ACME-klienterna fortsätter att göra det de gör, medan CertSecure Manager spårar varje certifikat de utfärdar, tillämpar dina kryptografiska policyer och ger dig en enhetlig bild av hela livscykeln i din Linux- och Windows-infrastruktur.
CertSecure Manager integreras med publika certifikatutfärdare som Let's Encrypt och med sin egen anpassade ACME-slutpunkt, så utfärdande och förnyelse förblir helt automatiserade. Det minskar också certifikatrelaterade avbrott genom att tillhandahålla konfigurerbara 30-dagars eller längre förvarningar.
På distributionssidan hanterar Ansibles playbooks konsekvent ACME-klientkonfiguration, certifikatdistribution och tjänsteomladdningar över Apache, Nginx, Tomcat och IIS i både lokala och hybridmolnmiljöer, allt utan manuell åtgärd.
Allt eftersom din miljö växer kan CertSecure Manager skalas med. Den tillhandahåller en enhetlig certifikatinventering, tillämpar kryptografiska standarder i alla team och ger insyn i livscykelhändelser. Dess operativa integrationer för aviseringar, ärendehantering och revisionsloggning förvandlar certifikathantering från en reaktiv brandbekämpningsövning till en kontrollerad, granskningsbar process.
Slutsats
Nedräkningen är redan igång. Certifikatens livslängd sjunker till 200 dagar år 2026, 100 dagar år 2027 och 47 dagar år 2029, medan återanvändningen av domänvalidering sjunker hela vägen till 10 dagar. Kortare certifikat och konstant, automatiserad validering är nu två sidor av samma sak.
De team som börjar nu kommer knappt att märka av deadlines, eftersom de kommer att ha en inventering, automatisering och tydligt ägarskap på plats. De team som väntar kommer att känna av varje förnyelse. Om du är osäker på var dina certifikat finns eller hur de förnyas är det det första du behöver åtgärda. Kartlägg det, automatisera det, och resten blir mycket enklare.
