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

CA/Browser Forum-omröstningen SC-081v3, godkänd i april 2025, minskar den maximala giltighetstiden för offentligt betrodda TLS-certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, i tre faser. Om din organisation fortfarande förlitar sig på manuella förnyelseflöden, kalenderpåminnelser eller någon annan mänskligt beroende process för att spåra certifikatutgång, slutar den operativa matematiken att fungera innan den sista fasen anländer. Den första åtgärden som krävs är en fullständig certifikatinventering: du kan inte automatisera det du inte hittar.

Snabbt svar: Vad är 47-dagars TLS-certifikatmandatet?

CA/Browser Forum Ballot SC-081v3 minskar den maximala giltighetstiden för TLS-certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, genom tre faser: 200 dagar från den 15 mars 2026 (redan i kraft), 100 dagar från den 15 mars 2027 och 47 dagar från den 15 mars 2029. Återanvändning av domänkontrollvalidering (DCV) krymper enligt samma schema och når 10 dagar år 2029. Manuella förnyelseprocesser är inte kompatibla med detta schema. ACME-baserad automatisering krävs.

Key Takeaways

• CA/Browser Forum-omröstningen SC-081v3 minskar den maximala giltighetstiden för TLS-certifikat från 398 dagar till 47 dagar i tre faser: 200 dagar från 15 mars 2026, 100 dagar från 15 mars 2027 och 47 dagar från 15 mars 2029. Fas 1 har redan trätt i kraft.
• Återanvändningsperioderna för domänkontrollvalidering (DCV) krymper enligt samma schema och når bara 10 dagar år 2029, vilket gör ACME-baserad automatiserad domänvalidering till ett hårt operativt krav, inte en optimering.
• 72 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under de senaste 12 månaderna, och endast 34 % har en fullständig, aktuell bild av sina egna certifikat. 47-dagarsschemat komprimerar samma arbetsbelastning till sex gånger kortare cykler.
• Manuell förnyelse och kalenderpåminnelser skalas inte till 47-dagars certifikat. ACME-baserad automatisering, distributionsverifiering och en central certifikatinventering är nu grundläggande krav.
• Certifikatfästning är fundamentalt inkompatibel med 47-dagars giltighet. Miljöer som använder fästning måste migrera till standard CA-baserad förtroendeverifiering före mars 2029.
• Gapet mellan förnyelse och driftsättning, där ett förnyat certifikat erhålls men inte driftsätts, är ett kritiskt felläge vid 47 dagars giltighetstid. Automatisering måste inkludera verifiering efter driftsättning.

Vad ändrade Ballot SC-081v3 och när träder varje fas i kraft?

Omröstning SC-081v3 föreslogs ursprungligen av Apple i januari 2025. CA/Browser Forum godkände den den 11 april 2025, med 25 certifikatutfärdare som röstade för och inga emot. Alla fyra stora webbläsarleverantörer, Apple, Google, Microsoft och Mozilla, röstade ja. Granskningsperioden för IP-rättigheter avslutades den 13 maj 2025 utan invändningar, vilket gjorde omröstningen helt verkställbar från det datumet.

Omröstningen ändrar två avsnitt i CA/Browser Forum TLS-baskraven:

• 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 tre faser, alla den 15 mars varje år:

Fas	Giltigt datum	Maximal giltighetstid för TLS-certifikat	Maximal DCV-återanvändningsperiod	Nuvarande status
Fas 1	Mars 15, 2026	200 DAYS	200 DAYS	Gäller i praktiken. Alla nya TLS-certifikat som utfärdas på eller efter detta datum har en maximal giltighetstid på 200 dagar.
Fas 2	Mars 15, 2027	100 DAYS	100 DAYS	Kommande. Förnyelsefrekvensen fördubblas i förhållande till fas 1.
Fas 3	Mars 15, 2029	47 DAYS	10 DAYS	Kommande. Certifikat förnyas ungefär var sjätte vecka. DCV måste verifieras på nytt vid nästan varje förnyelse.

Domänkontrollvalidering (DCV) är den process som en certifikatutfärdare använder för att verifiera att en certifikatansökande kontrollerar den begärda domänen. Historiskt sett kunde dessa validerade bevis återanvändas i upp till 398 dagar. SC-081v3 minskar detta återanvändningsfönster till bara 10 dagar senast i mars 2029, vilket innebär att domänägande måste verifieras på nytt vid nästan varje certifikatförnyelse. För en detaljerad genomgång av hur man automatiserar DCV-steget, se vår guide till persistenta DCV- och DNS-kopplingar.

Varför fattade CA/Browserforumet detta beslut?

Utvecklingen mot kortare giltighetstid för certifikat har pågått i över ett decennium. TLS-certifikat var giltiga i upp till fem år fram till 2015. Maximalt sänktes till tre år 2015, två år 2018 och 398 dagar 2020 när Apple ensidigt begränsade förtroendet för nya certifikat i Safari. SC-081v3 fortsätter den utvecklingen med en fast slutpunkt. CA/Browser Forum formulerade fyra skäl för förändringen:

• Begränsa explosionsradien för komprometterade certifikat: När en privat nyckel blir stulen, ett certifikat utfärdas på bedrägligt sätt eller en signeringsalgoritm visar sig vara svag, är skadan direkt proportionell mot hur länge certifikatet är giltigt. Ett 47-dagars certifikat representerar ett betydligt mindre fönster för exploaterbart förtroende än ett 398-dagars certifikat.
• Att återkallandet blir giltigt: Återkallelse av certifikat fungerar i stor utsträckning i praktiken. Online Certificate Status Protocol (OCSP) fungerar på en mjukfelsbasis i de flesta webbläsare, vilket innebär att om OCSP-respondern inte kan nås fortsätter webbläsarna istället för att blockera anslutningen. Listor över återkallelse av certifikat (CRL) uppdateras sällan och kontrolleras inkonsekvent. Let's Encrypt fasade ut OCSP helt 2024 och slutförde övergången 2025. Vid 47 dagars giltighet blir naturligt utgångsdatum den primära återkallelsesmekanismen.
• Tillämpa 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 fortsätta vara i produktion fram till 2025 med en giltighetstid på 398 dagar. Kortare giltighetsperioder tvingar fram mer frekvent utfärdande och mer frekvent tillämpning av nuvarande algoritm- och nyckelstandarder.
• Att driva implementeringen av automatisering: CA/Browser Forum angav uttryckligen att ett mål med SC-081v3 är att tvinga fram införandet av automatiserad hantering av certifikatlivscykeln. Ett 47-dagars certifikat som förnyas var sjätte vecka är operativt inkompatibelt med manuella processer, vilket gör automatisering till ett strukturellt krav snarare än en bästa praxis.

Vad visar informationen om nuvarande mognad för certifikathantering?

Störningen som SC-081v3 skapar är inte hypotetisk. Branschundersökningar visar att miljön redan är uttänjd med en giltighetstid på 398 dagar:

• 72 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under de senaste 12 månaderna, och 45 % uppgav att avbrott inträffade varje vecka, en ökning från endast 12 % som rapporterade veckovisa avbrott år 2022, enligt 2025 års rapport om tillståndet för maskinidentitetssäkerhet.
• Endast 34 % av organisationerna har en fullständig, aktuell bild av sina egna digitala certifikat, och nästan tre fjärdedelar är mycket eller extremt oroade över avbrott orsakade av utgångna certifikat, enligt en global undersökning från 2026 med fler än 400 ledande IT- och säkerhetschefer.
• Maskinidentiteter överstiger nu mänskliga identiteter med uppskattningsvis 82 till 1, och 79 % av säkerhetschefer förväntar sig att det förhållandet kommer att växa ytterligare med så mycket som 150 % under det kommande året.

Dessa siffror beskriver en bransch som redan misslyckades med årliga förnyelsecykler. Att komprimera samma arbetsbelastning till 47-dagarscykler, med ett 10-dagars återanvändningsfönster för DCV som kräver omverifiering av domänen vid nästan varje förnyelse, är inte något som manuella processer kan hantera. För mer information om hur tillväxt av maskinidentiteter förvärrar detta problem för PKI-team, se vår guide till maskinidentitet för PKI-team.

Vad betyder 47-dagarscertifikat operativt?

De operativa konsekvenserna av SC-081v3 varierar beroende på certifikattillgångens storlek och komplexitet samt det nuvarande läget för certifikathantering. Tre områden skapar de mest konsekventa operativa utmaningarna:

Synlighet för certifikatinventering

Du kan inte automatisera förnyelsen av certifikat du inte vet existerar. Spridning av certifikat över flera team, molnmiljöer, Kubernetes- kluster, CDN-konfigurationer och äldre servrar ä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ärdande. Att bygga omfattande insyn i certifikatinventeringen i alla miljöer, inklusive interna tjänster, icke-kundvändig infrastruktur och certifikat som hanteras av externa team, är den grundläggande förutsättningen för allt annat.

Gapet mellan förnyelse och utplacering

Ett av de vanligaste fellägena i automatiserade certifikatmiljöer är gapet mellan förnyelse och distribution: ACME-klienten hämtar ett nytt certifikat, men distributionssteget som installerar det på relevant server, lastbalanserare eller Kubernetes-ingång misslyckas tyst. Det förnyade certifikatet ligger oanvänt medan det gamla certifikatet fortsätter att hantera trafik tills det löper ut. Vid 47 dagars giltighetstid är detta gap ett kritiskt felläge. Certifikatförnyelse måste integreras med distributionsverifiering som bekräftar att det nya certifikatet faktiskt hanteras av klienter innan förnyelsen markeras som slutförd.

Äldre infrastruktur och certifikatfästning

Äldre applikationer med hårdkodade certifikat, IoT-enheter med firmware-inbäddade CA:er och miljöer som använder certifikatfästning representerar alla punkter där 47-dagars certifikat skapar utmaningar som automatisering ensamt inte kan lösa. Certifikatfästning, 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 CA, är fundamentalt oförenlig med 47-dagars giltighet. Den enda gångbara metoden för fästa miljöer är att migrera från fästning till standard CA-baserad förtroendeverifiering före mars 2029.

Manuell kontra automatiserad certifikathantering: Vilken metod överlever i 47 dagar?

Jämförelsen nedan visar varför manuella processer slutar vara genomförbara innan fas 3 anländer:

Krav vid 47 dagars giltighetstid	Manuellt eller kalenderstyrt	Automatiserad CLM (ACME + CertSecure Manager)
Förnyelser per certifikat per år	1 idag, stigande till 8 eller fler i mars 2029	Samma volym, ingen ytterligare personalstyrka
Domänvalidering (10-dagars DCV-återanvändning senast 2029)	Kör om manuellt vid varje förnyelsecykel	Maskin-till-maskin-utmaningssvar via ACME-protokoll (HTTP-01, DNS-01)
Certifikatförteckning	Kalkylblad, stamkunskap och manuella skanningar	Kontinuerlig identifiering i molnet, lokalt och Kubernetes
Gapet mellan förnyelse och driftsättning	Vanligt; förnyade certifikat kan ligga oanvända medan gamla löper ut	Implementeringen verifieras automatiskt innan förnyelsen markeras som slutförd
Avbrottsrisk	Hög, i linje med den ovan nämnda avbrottsfrekvensen på 72 % inom branschen	Lägre; förnyelse utlöses av utgångsdata, inte en kalenderpåminnelse
Revisions- och efterlevnadsrapportering	Manuella logghämtningar; inkonsekvent täckning mellan miljöer	Centraliserad, exporterbar förnyelse- och utgivningshistorik i alla miljöer
DCV-automation	Manuellt slutförande av utmaningar; pausar vid 10-dagars återanvändningsfönster	ACME automatiserar slutförandet av utmaningar; DNS-kopplingar möjliggör ihållande DCV

Hur bör organisationer förbereda sig för 47-dagars certifikatschemat?

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. Sjustegssekvensen nedan återspeglar den ordning i vilken beroenden måste lösas:

1. Bygg en komplett certifikatinventering: Upptäck alla publika TLS-certifikat 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. CBOM-säkerhet utför kontinuerlig kryptografisk identifiering i moln-, lokala och Kubernetes-miljöer, vilket ger dig en komplett bild av varje certifikat innan något automatiseras. Detta är det grundläggande steget: allt annat beror på att du vet vad du har. Bevisartefakt: komplett certifikatinventering med CA, utgångsdatum, installerad plats och ägare för varje certifikat.
2. Upprätta förnyelseaviseringar med fasanpassade ledtider: Under 200 dagars giltighetstid (fas 1), ställ in förnyelseaviseringar till 60 dagar före utgångsdatum. Under 100 dagars giltighetstid (fas 2), ställ in aviseringar till 30 dagar. Under 47 dagars giltighetstid (fas 3) bör aviseringar utlösas vid 25 till 30 dagar, med eskalerande aviseringar vid 14 dagar och 7 dagar. Bevisartefakt: CLM-plattformens aviseringskonfiguration som visar tröskelvärde per miljö och fas.
3. Standardisera ACME för certifikatutfärdande: ACME-protokollet (Automated Certificate Management Environment) (RFC 8555) är den mekanism som är specifikt utformad för automatiserad utfärdande och förnyelse av certifikat. CertSecure-hanterare stöder ACME inbyggt tillsammans med SCEP- och EST-protokoll, och integreras direkt med både publika och privata CA:er. Bevisartefakt: ACME-klientdistributionsregister; automatiserade loggar för lyckade förnyelser som visar slutförd domänvalidering.
4. Eliminera hårdkodade förnyelseintervaller: Granska alla skript, cron-jobb och automatiseringskonfigurationer för hårdkodade förnyelseintervall som "förnya var 60:e dag" eller "förnya var 90:e dag". Ersätt med dynamisk förnyelselogik baserad på certifikatets utgångsdatum eller ACME ARI-signaler (Automatic Renewal Information). Bevisartefakt: konfigurationsgranskningsresultat; uppdaterad automatisering som visar utgångsbaserad förnyelselogik.
5. Täck gapet mellan förnyelse och driftsättning: För varje certifikat som omfattas, verifiera att förnyelseprocessen inkluderar ett distributionssteg och ett verifieringssteg efter distribution som bekräftar att det förnyade certifikatet faktiskt levereras till klienter. Detta är viktigast i miljöer där förnyelse och distribution hanteras av separata system eller team. Bevisartefakt: distributionsverifieringsloggar som visar att det levererade certifikatet matchar det förnyade certifikatet för varje förnyelsehändelse.
6. Åtgärda äldre infrastruktur och certifikatfästning: Identifiera alla system som inte kan delta i automatisk förnyelse: äldre servrar, firmware-inbäddade certifikat och fästa konfigurationer. Definiera en migreringsväg för var och en före fas 3. Dessa ändringar är vanligtvis de mest tidskrävande och måste påbörjas i god tid före mars 2029. Bevisartefakt: inventering av äldre infrastruktur; migreringsplan med ägare och måldatum för varje system; register över borttagning av fästade certifikat.
7. Upprätta centraliserad CLM-styrning: Byt till en central plattform för hantering av certifikatlivscykeln 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ö. Bevisartefakt: CLM-plattformsdistribution som täcker alla miljöer inom omfattningen; efterlevnadsrapport visar noll certifikat inom 7 dagar efter utgångsdatum.

Checklista för TLS 47-dagars beredskapsgranskning

Använd den här checklistan för att bedöma din organisations beredskap för varje SC-081v3-fas. Punkterna är organiserade efter vilken fas de blir kritiska:

Kontrollområde	Krav	Kritisk av	Bevisartefakt	Status
Certifikatförteckning	Komplett inventering av alla publika TLS-certifikat med CA, utgångsdatum, installerad plats och ansvarigt team	Nu (fas 1 gäller)	CLM-lagerexport eller CBOM Secure Discovery-rapport	Till handling
Fas 1-efterlevnad	Alla nya TLS-certifikat som utfärdas från och med den 15 mars 2026 har en giltighetstid på högst 200 dagar.	15 mars 2026 (redan i kraft)	Konfiguration av policy för utfärdande av certifikatutfärdare; certifikatgranskning bekräftar att inga nya certifikat överstiger 200 dagar	Till handling
ACME-automatiseringsdistribution	ACME-baserad automatiserad förnyelse distribuerad för alla publika TLS-certifikat	Före fas 2 (mars 2027)	ACME-klientdistributionsregister; automatiserade loggar för lyckade förnyelser	Till handling
DCV-automation	Automatiserad domänkontrollvalidering som kan slutföra HTTP-01- eller DNS-01-utmaningar utan manuell åtgärd	Före fas 2 (mars 2027); kritisk senast fas 3 (10 dagars återanvändningsfönster)	Loggar för slutförande av ACME-utmaningar; konfiguration av DNS-anslutning	Till handling
Tröskelvärden för förnyelseaviseringar	Konfigurerade varningströsklar per fas: 60 dagar för fas 1, 30 dagar för fas 2, 25 till 30 dagar för fas 3	Löpande; uppdatering i varje fas	CLM-plattformens varningskonfiguration; bevis på varningsleverans	Till handling
Hårdkodad granskning av förnyelseintervall	Inga automatiseringsskript eller cronjobb använder hårdkodade förnyelseintervall; alla använder utgångsbaserad eller ACME ARI-logik.	Före fas 2 (mars 2027)	Resultat av konfigurationsgranskning; uppdaterade skript som visar dynamisk förnyelselogik	Till handling
Överbryggning av gapet i förnyelse och utplacering	Automatisering av certifikatförnyelse inkluderar verifiering efter driftsättning som bekräftar att det nya certifikatet levereras till klienter	Före fas 2 (mars 2027)	Verifieringsloggar för distribution per förnyelsehändelse	Till handling
Fas 2-efterlevnad	Alla nya TLS-certifikat som utfärdas från och med den 15 mars 2027 har en giltighetstid på högst 100 dagar.	Mars 15, 2027	Konfiguration av policy för utfärdande av certifikatutfärdare; certifikatrevision som bekräftar efterlevnad	Till handling
Migrering av äldre infrastruktur	Alla system som använder manuell certifikatdistribution, hårdkodade certifikat eller inbyggda certifikatutfärdare har en dokumenterad migreringsplan med måldatum före mars 2029.	Före fas 3 (mars 2029)	Inventering av äldre infrastruktur; migreringsplan med ägare och måldatum	Till handling
Borttagning av certifikatfästning	Inga produktionssystem använder certifikat eller publik nyckelfästning för offentligt betrodda certifikat	Före fas 3 (mars 2029)	Granskning av programkod; fästa borttagningsposter; standard CA-baserad förtroendeverifiering bekräftad	Till handling
Fas 3-efterlevnad	Alla nya TLS-certifikat som utfärdats från och med den 15 mars 2029 har en maximal giltighetstid på 47 dagar; återanvändning av DCV överstiger inte 10 dagar.	Mars 15, 2029	CA-utgivningspolicy; DCV-automatiseringsloggar; certifikatrevision som bekräftar efterlevnad	Till handling
CLM:s centrala styrning	Centraliserad CLM-plattform tillhandahåller enhetlig inventering, automatisering av förnyelser, distributionsorkestrering och efterlevnadsrapportering i alla miljöer	Före fas 3 (mars 2029)	CLM-plattformens täckningsrapport; efterlevnadsrapport som visar noll certifikat inom 7 dagar efter utgångsdatum	Till handling
Kryptoagilitet för autentiseringssystem	CLM-plattformen stöder utfärdande av post-quantum-certifikat för framtida migrering i takt med att NIST PQC-standarder antas av webbläsarens rotprogram.	Planering nu; genomförande 2028 till 2030	Leverantörens PQC-färdplan; CLM-plattformens PQC-supportdokumentation	Till handling

Hur krypteringskonsulting kan hjälpa till med 47-dagarsövergången

Encryption Consulting är ett ISO/IEC 27001:2022- och SOC 2-certifierat företag inom tillämpad kryptografi. Vår portfölj täcker alla komponenter i den 47 dagar långa övergången: automatiserad livscykelhantering, kryptografisk upptäckt, fullständigt hanterad PKI och post-kvantumberedskap.

• CertSecure-chef: CertSecure-hanterare är Encryption Consultings plattform för hantering av certifikatlivscykel och det mest direkta operativa svaret på vad 47-dagarsmandatet kräver. Den automatiserar utfärdande, förnyelse och distribution av certifikat i stor skala med hjälp av ACME-, SCEP- och EST-protokoll. Den automatiserar registrering och förnyelse över webbservrar inklusive Apache, Tomcat och IIS, och lastbalanserare inklusive F5 BIG-IP. Förnyelser utlöses dynamiskt från certifikatutgångsdata, inte hårdkodade intervall, vilket gör den i sig kompatibel med varje SC-081v3-fas. Den är byggd med kryptoagilitet i kärnan, vilket gör det möjligt för organisationer att migrera till post-kvantumcertifikat på ett kontrollerat, fasvis sätt allt eftersom NIST PQC-standarder antas av webbläsarens rotprogram. Se vår Guide för migrering av kvantkryptografi efter kvantkryptering för det fullständiga migreringsramverket i nio faser.
• CBOM Secure (kryptografiskt inventarium): CBOM-säkerhet upptäcker alla certifikat i din infrastruktur, inklusive molnkonton, lokala miljöer och Kubernetes-kluster, så att du vet exakt vad som behöver hanteras automatiskt innan varje deadline inträffar. Detta är det grundläggande steget i den sjustegsförberedelsesekvensen: du kan inte automatisera det du inte kan hitta. Se även vår guide till Den kryptografiska blinda fläcken som gömmer sig i din egen infrastruktur för varför de flesta lager saknar viktiga certifikat.
• PKI som en tjänst: För organisationer som behöver hantera den betydligt ökade belastningen på certifikatutfärdande med 47 dagars livslängd utan att behöva se över den interna PKI-infrastrukturen, PKI-som-en-tjänst tillhandahåller en helt hanterad CA byggd för att skalas med den nya förnyelsefrekvensen. I takt med att utfärdandegraden sexfaldigas 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.
• Persistenta DCV- och DNS-kopplingar: För organisationer som behöver automatisera själva domänvalideringssteget, vår permanent DCV och DNS-anslutning Guiden täcker ACME-utmaningsautomation för det 10-dagars återanvändningsfönster för DCV som anländer i fas 3.

Slutsats

CA/Browser Forums beslut att minska TLS-certifikatets giltighetstid till 47 dagar senast i mars 2029 är den mest betydande förändringen i hanteringen av certifikatens livscykel på mer än ett decennium. Fas 1 har redan trätt i kraft. Fas 2 träder i kraft i mars 2027. Slutdatumet på 47 dagar i mars 2029 är en fast deadline som webbläsartillämpningen kommer att göra icke-förhandlingsbar.

De organisationer som navigerar varje fas smidigt är de som behandlar hanteringen av certifikatlivscykeln 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 allt oftare i takt med att giltighetstiderna fortsätter att förkortas.

Vanliga frågor om partihandel med mat och dryck

Vad är CA/Browser Forums regel för certifikatgiltighet på 47 dagar?

Omröstning SC-081v3, godkänd i april 2025, minskar den maximala giltighetstiden för offentligt betrodda TLS-certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, i tre faser: 200 dagar från den 15 mars 2026, 100 dagar från den 15 mars 2027 och 47 dagar från den 15 mars 2029. Alla större webbläsarleverantörer, inklusive Apple, Google, Microsoft och Mozilla, röstade för. Fas 1 har redan trätt i kraft.

Behöver certifikat som utfärdats före en fasdeadline ersättas i förtid?

Nej. Ett certifikat som utfärdats före en fas ikraftträdandedatum behåller sin ursprungliga giltighetsperiod tills det löper ut på naturlig väg. Den nya maximala giltighetstiden gäller endast för certifikat som utfärdats eller förnyats på eller efter varje deadline. Det finns ingen respitperiod: alla certifikat som utfärdats på eller efter den 15 mars 2026 måste uppfylla den maximala giltighetstiden på 200 dagar för den fasen.

Vad är återanvändning av domänkontrollvalidering (DCV) och varför är det viktigt?

DCV-återanvändning är hur länge en certifikatutfärdare kan förlita sig på en tidigare verifiering av domänägarskap innan den kräver nytt bevis. SC-081v3 minskar detta till 10 dagar senast i mars 2029, vilket innebär att domänägarskap måste verifieras på nytt vid nästan varje certifikatförnyelse. Detta gör ACME-baserad automatiserad domänvalidering till ett svårt operativt krav snarare än en bekvämlighet.

Gäller 47-dagarsregeln interna eller privata certifikat?

Nej. SC-081v3 reglerar endast offentligt betrodda TLS-certifikat som utfärdats av CA:er i webbläsarens rotprogram. Privat eller intern PKI omfattas inte av CA/Browser Forums baslinjekrav och kan fortsätta att använda längre giltighetsperioder. Många organisationer väljer att anpassa intern policy till det offentliga schemat för konsekvens och för att förenkla CLM-automatisering.

Vad är certifikatfästning och varför är det inkompatibelt med 47-dagarscertifikat?

Certifikatfästing hårdkodar ett specifikt certifikat eller en offentlig nyckel till en klientapplikation eller enhet. Vid 47-dagars förnyelsecykler måste klienten också uppdateras var sjätte vecka, vilket är operativt ohanterligt. Den enda gångbara metoden är att migrera från certifikatfästing till standard CA-baserad förtroendeverifiering före mars 2029.

Vad är gapet mellan förnyelse och driftsättning och hur överbryggar organisationer det?

Gapet mellan förnyelse och driftsättning uppstår när ett nytt certifikat erhålls men inte driftsätts, vilket lämnar det gamla certifikatet i drift tills det löper ut. Vid 47 dagars giltighetstid är detta ett kritiskt felläge. För att stänga det kräver det att automatiseringen av certifikatförnyelsen inkluderar ett verifieringssteg efter driftsättning som bekräftar att det nya certifikatet faktiskt driftsätts innan förnyelsen markeras som slutförd.

Hur bör organisationer förbereda sig för 47-dagars TLS-certifikat?

Sekvensen i sju steg är: (1) bygga en komplett certifikatinventering; (2) etablera fasanpassade tröskelvärden för förnyelseaviseringar; (3) standardisera ACME-automation; (4) eliminera hårdkodade förnyelseintervall; (5) täppa till gapet mellan förnyelse och driftsättning; (6) åtgärda äldre infrastruktur och certifikatfästning; och (7) etablera centraliserad CLM-styrning. Börja med inventeringen, eftersom alla andra steg är beroende av att du vet vilka certifikat du har.