Starkare säkerhet med TLS-certifikat med 47 dagars giltighetstid senast 2029

Om er organisation hanterar offentliga TLS-certifikat idag och fortfarande förlitar sig på manuella förnyelseflöden, kalenderpåminnelser eller andra processer som kräver att en människa märker ett förestående utgångsdatum och vidtar åtgärder, kommer de kommande tre åren att bli verkligt omvälvande.

Den 11 april 2025 godkände CA/Browser Forum omröstningen SC-081v3 , formellt med titeln "Inför ett schema för att minska giltighets- och dataåteranvändningsperioder". Omröstningen var entydig: 25 certifikatutfärdare röstade för, noll emot , och alla fyra stora webbläsarleverantörer, Apple, Google, Microsoft och Mozilla, röstade ja. Resultatet är ett låst, etappvis schema som minskar den maximala giltigheten för alla offentligt betrodda TLS-certifikat från 398 dagar idag, ner till 47 dagar den 15 mars 2029.

I den här bloggen går vi igenom exakt vad SC-081v3 kräver, varför CA/Browser Forum fattade detta beslut, vilka operativa konsekvenser det får för team som hanterar TLS-certifikat och vad din organisation bör göra just nu för att ligga steget före i varje fas.

Vad som förändrades och när

Valsedel SC-081v3 föreslogs ursprungligen av Apple i januari 2025 och granskningsperioden för immateriella rättigheter avslutades den 13 maj 2025 utan invändningar, vilket gjorde valsedeln helt verkställbar från det datumet.

Omröstningen ändrar två avsnitt av TLS-grundkraven:

• Avsnitt 6.3.2: anger det etappvisa schemat för att minska maximala giltighetsperioder för TLS-certifikat.
• Avsnitt 4.2.1: anger det parallella schemat för att minska hur länge bevis för domänkontrollvalidering (DCV) kan återanvändas mellan certifikatutfärdanden.

Båda ändringarna träder i kraft i samma tre faser; alla den 15 mars varje år:

Fas	Giltig datum	Maximal giltighetstid för TLS-certifikat	DCV-återanvändningsperiod
Fas 1	Mars 15, 2026	200 DAYS	200 DAYS
Fas 2	Mars 15, 2027	100 DAYS	100 DAYS
Fas 3	Mars 15, 2029	47 DAYS	10 DAYS

Innan en certifikatutfärdare kan utfärda ett TLS-certifikat för en domän måste den först verifiera att sökanden faktiskt kontrollerar domänen. Detta är domänkontrollvalidering. I praktiken kräver en certifikatutfärdare att sökanden slutför en utmaning, vanligtvis genom att placera en specifik fil på en känd URL på domänen (HTTP-01), lägga till en specifik DNS TXT-post (DNS-01) eller svara på ett valideringsmejl som skickas till en registrerad kontaktadress för domänen. När certifikatutfärdaren bekräftar att utmaningen är uppfylld anser den att domänen är validerad. Historiskt sett kunde valideringsbeviset återanvändas i upp till 398 dagar, vilket innebär att en certifikatutfärdare kunde utfärda efterföljande certifikat för samma domän utan att kräva nytt bevis på över ett år.

SC-081v3 minskar detta återanvändningsfönster i takt med certifikatets giltighetstid, och sänker det slutligen till bara 10 dagar i mars 2029. Vid den tidpunkten måste domänägarskapet verifieras på nytt vid nästan varje certifikatförnyelse, vilket gör automatiserad DCV, genom ACME:s challenge-response-protokoll, till ett hårt operativt krav snarare än en optimering.

Från och med idag har fas 1 redan trätt i kraft, och alla nya TLS-certifikat som utfärdas har en maximal giltighetstid på 200 dagar. Certifikat som utfärdas före varje fas deadline förblir giltiga under sin ursprungliga period. Alla certifikat som utfärdas på eller efter varje deadline måste uppfylla den nya maximala giltighetstiden för den fasen eftersom det inte finns någon respitperiod för nyutfärdade certifikat.

Varför CA/Browserforumet fattade detta beslut

Utvecklingen mot kortare giltighetstid för certifikat har pågått i flera år. TLS-certifikat var giltiga i upp till fem år fram till 2015, då CA/Browser Forum minskade det till tre år. År 2018 sänktes den maximala tiden till två år. År 2020 begränsade Apple ensidigt förtroendet för nya certifikat till 398 dagar i Safari, vilket tvingade branschen att införa den gränsen över hela linjen.

• Begränsning av sprängradien: När en privat nyckel blir stulen, ett certifikat utfärdas på bedrägligt sätt eller en signeringsalgoritm upptäcks vara svag, är den potentiella skadan direkt proportionell mot hur länge certifikatet är giltigt. Ett certifikat med 47 dagars återstående giltighetstid representerar ett betydligt mindre fönster för utnyttjande av förtroende än ett med 398 dagar.
• Att återkallandet blir giltigt: Återkallelse av certifikat är i praktiken till stor del felaktigt. Online Certificate Status Protocol (OCSP) fungerar på en mjukfelsbasis i de flesta webbläsare, det vill säga om OCSP-respondern inte kan nås fortsätter webbläsarna vanligtvis istället för att blockera anslutningen. Listor över återkallelse av certifikat (CRL) uppdateras sällan och kontrolleras inkonsekvent. Let's Encrypt började fasa ut OCSP helt 2024 och slutförde övergången 2025, med hänvisning till dess ineffektivitet.
• Starkare kryptografiska metoder: Långlivade certifikat gör det möjligt för organisationer att skjuta upp algoritmmigreringar. Ett certifikat som utfärdats med en svag nyckelstorlek eller en föråldrad algoritm år 2023 kan fortfarande vara i produktion år 2026 om dess giltighetstid förlängs så långt. Kortare giltighetsperioder tvingar fram mer frekvent utfärdande, vilket innebär fler möjligheter att tillämpa nuvarande algoritm- och nyckelstandarder.
• Nödvändig automatisering: CA/Browser Forum har uttryckligen angett att ett av målen med SC-081v3 är att driva införandet av automatiserad hantering av certifikatlivscykeln. Ett 47-dagars certifikat som förnyas var sjätte vecka är inte kompatibelt med manuella processer eftersom den operativa omkostnaden helt enkelt är för hög, vilket kommer att göra denna process mer tillförlitlig, mer granskningsbar och mer motståndskraftig än någon människoberoende process.

Vad 47-dagarscertifikat betyder operativt

De operativa konsekvenserna av SC-081v3 varierar avsevärt beroende på storleken och komplexiteten på din certifikatkonfiguration och det aktuella läget för dina certifikathanteringspraxis.

Synlighet för certifikatinventering

Du kan inte hantera förnyelse av certifikat du inte vet existerar. Certifikatspridning, där certifikat utfärdas över flera team, molnmiljöer, Kubernetes- kluster, CDN-konfigurationer och äldre servrar utan central spårning, är den vanligaste förutsättningen för avbrott vid utgångsdatum. Under årliga förnyelsecykler kan ett oupptäckt certifikat gå obemärkt förbi i månader innan det löper ut. Under 47-dagarscykler kommer ett ospårat certifikat att löpa ut inom några veckor efter utfärdandet.

Att bygga heltäckande insyn i certifikatinventeringen, i alla miljöer, inklusive interna tjänster, icke-kundvändig infrastruktur och certifikat som hanteras av externa team eller tredjepartstjänster, är det grundläggande kravet för denna uppdatering av certifikatens giltighetstidslinje.

CI/CD och implementeringsintegration

Ett av de vanligaste fellägena i automatiserade certifikatmiljöer är "förnyelse-distributionsgap", där ACME-klienten framgångsrikt hämtar ett nytt certifikat, men distributionssteget som installerar det på relevant server, lastbalanserare eller Kubernetes-ingång misslyckas tyst. Det förnyade certifikatet finns i ett filsystem eller hemlighetslager medan det gamla certifikatet fortsätter att hantera trafik tills det löper ut.

Vid 47 dagars giltighetstid är distributionsgapet ett kritiskt felläge. Certifikatförnyelse måste integreras med distributionen och det nya certifikatet måste verifieras som driftsatt och hanterar trafik innan förnyelsen anses vara slutförd.

Äldre infrastruktur och certifikatfästning

Äldre applikationer med hårdkodade certifikat, IoT-enheter med inbyggda certifikatutfärdare (CAs), system som använder certifikatfästning och miljöer med manuella distributionsprocesser representerar alla punkter där 47-dagars certifikat skapar verkliga utmaningar som automatisering ensamt inte kan lösa.

Certifikatfästing, där en klient är konfigurerad att endast lita på ett specifikt certifikat eller en offentlig nyckel, snarare än något certifikat från en betrodd certifikatutfärdare, är fundamentalt oförenligt med en 47-dagars giltighetstid. Om det fästa certifikatet måste bytas ut var sjätte vecka måste klientkonfigurationen uppdateras med samma frekvens. Den enda gångbara metoden för fästa miljöer är att migrera från fästning helt och hållet till standard certifikatutfärdarbaserad förtroendeverifiering innan 47-dagarsmandatet träder i kraft.

Förbered dig för den kortare giltighetstiden för TLS-certifikatet

Med fas 1 redan i kraft och fas 2 som anländer i mars 2027 är fönstret för att bygga den infrastruktur som krävs för 47-dagarseran inte oändligt. Här är en praktisk sekvens för byggberedskap:

Steg 1: Bygg en komplett certifikatinventering

Upptäck alla publika TLS-certifikat som din organisation har utfärdat, i alla miljöer och team. Använd loggövervakning för certifikattransparens (CT), molnleverantörs-API:er, nätverksskanning och integrationer med din CA:s hanteringskonsol för att bygga en centraliserad inventering. Encryption Consultings CBOM Secure är specialbyggt för just detta. Den utför kontinuerlig kryptografisk identifiering över hela din installation, vilket ger dig en komplett bild av varje kryptografiskt objekt innan du börjar automatisera någonting. Detta är det grundläggande steget eftersom allt annat beror på att du vet vad du har i din miljö.

Steg 2: Upprätta förnyelseaviseringar med lämpliga ledtider

Aviseringströskelvärdena måste konfigureras om i varje fas. Vid 200 dagars giltighet (fas 1), sätt förnyelseaviseringar till 60 dagar före utgångsdatum. Vid 100 dagars giltighet (fas 2), sätt aviseringar till 30 dagar. Vid 47 dagars giltighet bör aviseringar utlösas vid 25–30 dagar, med eskalerande aviseringar vid 14 dagar och 7 dagar.

Steg 3: Standardisera ACME för certifikatutfärdande.

ACME (Automated Certificate Management Environment) är ett protokoll som är specifikt utformat för automatiserad utfärdande och förnyelse av certifikat. Encryption Consultings CertSecure Manager har stöd för ACME inbyggt tillsammans med SCEP- och EST-protokoll, vilket gör det till rätt plattform att standardisera för automatiserad utfärdande och förnyelse av certifikat i alla skalor. Det integreras direkt med både offentliga och privata certifikatutfärdare, vilket säkerställer att era ACME-baserade förnyelsearbetsflöden är helt kompatibla med vilken certifikatutfärdare er organisation förlitar sig på.

Steg 4: Eliminera hårdkodade förnyelseintervaller

Granska alla skript, cron-jobb och automatiseringskonfigurationer som styr certifikatförnyelse. Alla konfigurationer med ett hårdkodat förnyelseintervall som "förnya var 60:e dag" eller "förnya var 90:e dag" kommer att sluta fungera allt eftersom certifikatens livslängd fortsätter att förkortas. Ersätt med dynamisk förnyelselogik baserad på certifikatens utgångsdatum eller ACME ARI-signaler.

Steg 5: Täck gapet mellan förnyelse och driftsättning

För varje certifikat i ditt inventarium, verifiera att förnyelseprocessen inkluderar ett distributionssteg och ett verifieringssteg efter distribution, vilket bekräftar att det förnyade certifikatet faktiskt levereras till klienter. Detta är mest kritiskt i miljöer där förnyelse och distribution hanteras av separata system eller separata team.

Steg 6: Ta itu med äldre infrastruktur

Identifiera alla system som inte kan delta i automatisk förnyelse, inklusive äldre servrar, firmware-inbäddade certifikat och fästa konfigurationer. Definiera en migreringsväg för varje system innan fas 2 tvingar fram problemet. Dessa är vanligtvis de mest tidskrävande och resurskrävande ändringarna, och de måste påbörjas långt före den slutliga deadline.

Steg 7: Etablera centraliserad synlighet och styrning

Övergå till en central plattform för hantering av certifikatlivscykel (CLM), som vår CertSecure Manager, som tillhandahåller enhetlig inventering, automatisering av förnyelser, distributionsorkestrering och efterlevnadsrapportering i alla miljöer. Den operativa komplexiteten i 47-dagarseran är inte kompatibel med fragmenterad certifikathantering per miljö.

Hur krypteringskonsulting kan hjälpa

På Encryption Consulting har vi byggt en portfölj av produkter och tjänster som är specifikt utformade för att hjälpa organisationer att navigera den 47 dagar långa certifikatövergången, från automatiserad livscykelhantering och kryptografisk identifiering till helt hanterad PKI och post-quantum-beredskap.

CertSecure Manager är Encryption Consultings dedikerade plattform för hantering av certifikatlivscykler och det mest direkta svaret på vad 47-dagarsmandatet kräver. Det automatiserar utfärdande, förnyelse och driftsättning av certifikat i stor skala med hjälp av ACME-, SCEP- och EST-protokoll, och är byggt specifikt för högfrekventa förnyelsecykler där manuella processer helt enkelt inte kan hålla jämna steg.

Plattformen automatiserar certifikatregistrering och förnyelse på webbservrar inklusive Apache, Tomcat och IIS, och med lastbalanserare inklusive F5 BIG-IP. Den integreras med publika betrodda certifikatutfärdare som DigiCert och Entrust, och privata betrodda certifikatutfärdare inklusive Microsoft PKI, AWS Private CA och HashiCorp CA. Förnyelser utlöses dynamiskt från certifikatutgångsdata, inte hårdkodade intervall, vilket gör den i sig kompatibel med varje ny fas i SC-081v3-schemat.

Den är byggd med kryptoagilitet i centrum och i takt med att NISTs slutgiltiga PQC-standarder börjar påverka kraven för webbläsare och rotprogram, hjälper plattformen organisationer att bedöma sin nuvarande kryptografiska ställning och migrera till kvantsäkra certifikat på ett kontrollerat och fasvis sätt, utan plattformsbyte eller störande manuell migrering.

Tillsammans med vår CertSecure Manager erbjuder vi även PKI-as-a-Service för organisationer som behöver hantera den betydligt ökade belastningen på certifikatutgivning som följer med 47 dagars livslängd utan att bygga eller översyna intern PKI-infrastruktur. Det ger en helt hanterad PKI byggd för att skalas med den nya förnyelsefrekvensen. I takt med att certifikatutgivningstakten ökar fram till 2029 kommer organisationer som kör resursfattig intern CA-infrastruktur att möta utmaningar med dataflöde och tillgänglighet. PKI-as-a-Service absorberar den belastningen utan att kräva interna infrastrukturförändringar, vilket låter ditt team fokusera på styrning och efterlevnad snarare än CA-drift.

CBOM Secure är ytterligare en produkt från Encryption Consulting för kryptografisk identifiering och inventering som hjälper dig att uppnå och genomföra färdplanen för ett 47-dagarsskifte för TLS-certifikat. Innan du kan automatisera hanteringen av certifikat måste du veta exakt vilka kryptografiska tillgångar som finns i din miljö. CBOM Secure upptäcker varje certifikat i din infrastruktur, så att du vet exakt vad som behöver automatiseras innan varje deadline inträffar.

Slutsats

CA/Browser Forums beslut att minska giltighetstiden för TLS-certifikat till 47 dagar senast i mars 2029 är den mest betydande förändringen i hanteringen av certifikatens livscykel på mer än ett decennium. Med fas 1 redan här och fas 2 som anländer i mars 2027 är slutdatumet på 47 dagar år 2029 nu bara några månader bort i tidslinjen för infrastrukturplanering.

De organisationer som kommer att förstå och tillämpa dessa faser smidigt är de som behandlar certifikatlivscykelhantering som automatiserad, övervakad, centralt styrd och kontinuerligt testad infrastruktur snarare än som en periodisk administrativ uppgift. De organisationer som väntar på att varje fas ska tvinga fram problemet kommer att möta återkommande operativa kriser, med ökande frekvens i takt med att giltighetstiderna fortsätter att förkortas.

På Encryption Consulting finns vi här för att hjälpa till i varje steg på den resan. Tiden att bygga denna infrastruktur är nu, innan fas 2 gör luckorna smärtsamma och svåra att hantera.