PKI år 2026: Hur man överlever 47-dagarseran med TLS-certifikat

47-dagars TLS-certifikateran är CA/Browser Forums etappvisa minskning av maximal giltighetstid för offentliga TLS-certifikat, godkänd som Ballot SC-081v3 den 11 april 2025, vilket sänker taket från 398 dagar till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. Detta gör certifikatförnyelse från en årlig uppgift till en kontinuerlig, automatiserad sådan. Under större delen av det senaste decenniet var ett offentligt TLS-certifikat något man skapade en gång och knappt tänkte på i ett år eller mer. Det förändras snabbt. CA/Browser Forum godkände Ballot SC-081v3 , ett fast schema som minskar den maximala livslängden för ett offentligt TLS-certifikat från 398 dagar till 47 dagar år 2029. Den första minskningen har redan trätt i kraft: sedan den 15 mars 2026 kan ingen offentlig certifikatutfärdare (CA) utfärda ett certifikat som varar längre än 200 dagar.

För säkerhetsteam, PKI-ingenjörer, CISO:er, molnarkitekter och DevSecOps-grupper är detta inte en liten policyförändring. Den förvandlar hantering av certifikatlivscykeln från en uppgift som görs en gång om året till en konstant, automatiserad sådan. I den här bloggen ska vi titta på vad som förändrades och varför, var dina certifikat faktiskt gömmer sig, hur automatiseringen fungerar och hur allt detta kopplas till den större utvecklingen mot postkvantkryptografi.

Hoppa till: Sammanfattning | Snabbchecklista | Ägar- och åtgärdsmatris | Policykällor | Vad man ska göra härnäst

Sammanfattning

CA/Browser Forums omröstning SC-081v3, godkänd den 11 april 2025, fasar ner den maximala giltighetstiden för offentliga TLS-certifikat från 398 dagar till 200 dagar (gäller från och med 15 mars 2026, redan i kraft), 100 dagar (15 mars 2027) och 47 dagar (15 mars 2029), medan återanvändningen av Domain Control Validation krymper enligt samma schema ner till bara 10 dagar. DigiCerts Trust Pulse-undersökning fann att 45 % av organisationerna upplevde certifikatrelaterade driftstopp under det senaste året, och 37.5 % spårade ett avbrott till ett utgånget certifikat, så de operativa insatserna är redan verkliga innan de kortaste fönstren ens anländer. Den här guiden anger de exakta datumen, vilka förändringar som sker vid varje datum, vem som påverkas, en beredskapschecklista, en ägar- och åtgärdsmatris för PKI-, säkerhets-, plattforms- och efterlevnadsteam samt en migreringsfärdplan för att täppa till gapet innan manuell certifikatspårning blir matematiskt omöjlig.

Snabb checklista för 47 dagars beredskap

Använd den här checklistan för att bedöma hur nära din organisation är att vara redo för ett TLS-certifikat på 47 dagar.

• Bekräfta att du har ett enda, kontinuerligt uppdaterat inventarium för certifikatidentifiering i lokala, moln- och hybridmiljöer.
• Bekräfta att varje certifikat har en namngiven, ansvarig ägare registrerad.
• Bekräfta förnyelse, utfärdande och återkallelse genom certifikatautomatisering snarare än manuell spårning.
• Bekräfta att din ACME-klient är ARI-medveten och kontrollerar förnyelsefönster oftare än en gång i veckan.
• Bekräfta att DNSSEC- och CAA-posterna är rena, eftersom SC-085v2 kan blockera automatisk utfärdande om de inte är det.

Ägare och åtgärdsmatris per team

Att minska gapet på 47 dagar kräver tydligt ansvarstagande mellan fyra team. Så här bör PKI-, säkerhets-, plattforms- och compliance-team fördela ansvaret.

Team	Primärt ansvar	Nyckelåtgärd
PKI-teamet	Egen policy för certifikatutgivning och CA-relationer	Testa ACME-automation nu och bekräfta redundansväxling till en andra CA före 2029
Säkerhetsteam	Eget nyckelskydd och kryptografisk risk	Kräv HSM-baserad nyckelgenerering för varje förnyelse och övervaka certifikattransparensloggar för utfärdande utanför policyn
Plattforms- och DevOps-teamet	Egen automatiserad förnyelse och driftsättning	Anslut ARI-medvetna ACME-klienter till lastbalanserare, Kubernetes och CI/CD-pipelines
Efterlevnadsteam	Egna revisionsbevis för certifikatboet	Spåra automatiseringstäckning, lagerfullständighet och policyefterlevnadsmått för revisorer

Policykällor och ikraftträdandedatum

Varje deadline i den här guiden kan spåras tillbaka till en primär policykälla, inte en sekundär sammanfattning. CA/Browser Forums egen omröstningslista är den auktoritativa källan för 47-dagars TLS-certifikatschemat: Ballot SC-081v3 godkändes den 11 april 2025 och publiceras på cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods . En sekundär branschsammanfattning av samma schema finns tillgänglig från Sectigo på sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days . Det relaterade DNSSEC-valideringskravet är Ballot SC-085v2, som trädde i kraft samma datum som 200-dagarsövergången.

Uppdateringslogg: Ursprungligen publicerad maj 2026; senast uppdaterad för att lägga till statistik om driftstopp, en mer fullständig tidslinjetabell, en ägar- och åtgärdsmatris, ett FAQ-block och schemamarkering, samt för att bekräfta varje datum mot CA/Browser Forums primära omröstningspost snarare än en sekundär sammanfattning. Detta inlägg granskas mot CA/Browser Forums offentliga omröstningslogg kvartalsvis, eller omedelbart efter eventuella nya CA/Browser Forum-, webbläsarrotprogram- eller Encryption Consulting-produktändringar som påverkar certifikatets giltighet.

Vad förändras år 2026

Giltig datum	Krav	Vilka påverkas	Åtgärd behövs	Källa
Fram till 14 mars 2026	Maximal giltighet och DCV-återanvändning: 398 dagar	Alla innehavare av offentliga TLS-certifikat	Baslinje; inga åtgärder krävs utöver standardförnyelse	Omröstning för CA/Webbläsarforum SC-081v3
15 mars 2026 (i kraft)	Maximal giltighet och återanvändning av DCV minskad till 200 dagar	Alla innehavare av offentliga TLS-certifikat; OV/EV-innehavare ser även återanvändning av ämnesidentitetsinformation minskad från 825 till 398 dagar.	Bekräfta att förnyelseautomation finns för alla offentliga certifikat; slutför certifikatidentifiering av hela certifikattillgången	Omröstning för CA/Webbläsarforum SC-081v3
Mars 15 2027	Maximal giltighet och återanvändning av DCV minskad till 100 dagar	Alla innehavare av offentliga TLS-certifikat; team förlitar sig fortfarande på manuell utfärdande	Ta bort manuell utfärdande från produktionen; anslut automatisering till lastbalanserare, Kubernetes och CI/CD	Omröstning för CA/Webbläsarforum SC-081v3
Mars 15 2029	Maximal giltighetstid minskad till 47 dagar; återanvändning av DCV minskad till 10 dagar	Alla innehavare av offentliga TLS-certifikat	Kör helautomatiska, repeterbara förnyelser från början till slut; behandla alla manuella förnyelser som ett undantag	Omröstning för CA/Webbläsarforum SC-081v3
15 mars 2026 (i kraft)	DNSSEC-signaturvalidering krävs vid CAA- och domänvalideringssökningar	Domäner med DNSSEC implementerat	Bekräfta att DNSSEC- och CAA-posterna är rena innan du förlitar dig på automatiserad utfärdande	Omröstning för CA/Webbläsarforum SC-085v2

Källhänvisningar för denna tidslinje: CA/Browser Forum Ballot SC-081v3, godkänd 11 april 2025 ( cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods ); sekundär sammanfattning via Sectigo ( sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days ).

Ett par punkter missas ofta. För det första gäller detta bara publika CA:er som webbläsare litar på. Din egen interna eller privata PKI är inte bunden av dessa regler, men det är fortfarande smart att följa samma väg, eftersom de manuella vanor som bryter mot publika förnyelser också kommer att bryta mot interna. För det andra är siffrorna i detta schema tak, inte typiska utfärdandelängder. CA:er utfärdar något under varje tak för att upprätthålla en säkerhetsbuffert. Ett certifikat som utfärdats bara en sekund över gränsen behandlas som felaktigt utfärdat och måste återkallas, så ingen CA kommer nära det.

Det finns också en relaterad förändring värd att notera. En separat omröstning från CA/B-forumet, SC-085v2, trädde i kraft samma dag. Om en domän har DNSSEC (Domain Name System Security Extensions) implementerat krävs det att CA:er validerar dessa signaturer under de CAA- och domänvaliderings-DNS-sökningar de kör innan utfärdande. Så rena DNS- och CAA-poster är nu viktigare än någonsin. Innan man bestämmer sig för hur man ska reagera är det bra att förstå varför branschen valde denna väg, eftersom anledningen pekar mot rätt lösning.

Varför certifikat blir kortare

Målet är att minska risken innan den blir ett problem. Ett certifikat är en ögonblicksbild av förtroendet i det ögonblick det utfärdas. Ju längre det är giltigt, desto större är risken att det som registreras, till exempel vem som äger domänen eller om nyckeln fortfarande är säker, inte längre stämmer överens med verkligheten. Kortare livslängder håller informationen aktuell och minskar fönstret inom vilket ett inaktuellt eller felaktigt utfärdat certifikat förblir tillförlitligt.

Det finns en andra anledning. Återkallelse har aldrig fungerat bra på internetnivå. Återkallningslistor är långa, statuscheckprotokollet ( OCSP ) medför fördröjningar och integritetsproblem, och webbläsare släpper ofta igenom en anslutning när en statuskontroll tar slut. En kort livslängd fungerar som en återkallelse som alltid lyckas, eftersom ett riskabelt certifikat helt enkelt löper ut inom några veckor. Kortare certifikat gör det också mycket lättare att snabbt ta bort svaga algoritmer, vilket är av stor betydelse för övergången till postkvantkryptografi.

Det är verkliga fördelar, men de lägger arbetet på den som äger certifikatet. För att förstå varför automatisering nu är ett måste, hjälper det att omvandla schemat till den faktiska arbetsbelastning som ditt team kommer att bära.

Vad detta innebär för din arbetsbelastning

Matematiken är enkel. Ett certifikat som brukade förnyas en gång om året med 398 dagars mellanrum förnyas nu ungefär var 47:e dag, vilket är ungefär åtta gånger om året. En liten uppsättning på 100 publika certifikat hoppar från cirka 100 förnyelser per år till cirka 800. Det är ungefär en åttafaldig ökning, men det större problemet är det minskande utrymmet för fel. På en årscykel lämnade en missad förnyelse dagar eller veckor för att åtgärda saker. Vid 47 dagar är bufferten bara timmar, och 10-dagars DCV-fönstret innebär att du måste bevisa domänkontrollen igen vid nästan varje förnyelse.

Team som använder OV- eller EV-certifikat har en extra belastning: SC-081v3 minskar också återanvändningsfönstret för Subject Identity Information (SII), den organisationsidentitetsdata som ligger bakom dessa certifikat, från 825 dagar till 398 dagar, vilket tvingar fram mer frekvent omvalidering av affärsuppgifter.

Kostnaden för att göra detta fel är väl dokumenterad. I en studie från 2023 uppgav 77 % av organisationerna att de hade minst två större avbrott på grund av utgångna certifikat under de två föregående åren, och mer än hälften uppgav att dessa avbrott drabbade kundvända tjänster. Mer nyligen fann DigiCerts Trust Pulse Survey, publicerad den 2 juli 2025, att 45 % av organisationerna upplevde certifikatrelaterade driftstopp under det senaste året, och 37.5 % spårade ett avbrott specifikt till ett utgånget certifikat. Källa: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations.

Det här är inte ovanliga händelser. I februari 2020 gick Microsoft Teams ner världen över efter ett utgånget certifikat. Konsekvenserna är inte heller alltid så synliga. Under Equifax-intrånget 2017 gjorde ett utgånget certifikat att en säkerhetsenhet inte kunde upptäcka angripare under en längre tid. Årligen var dessa fel tillräckligt sällsynta för att överleva. Vid 47 dagar blir en missad manuell förnyelse en mycket frekvent och mycket allmän risk.

Innan du kan automatisera förnyelser måste du dock veta vad du förnyar. Den svåraste delen av att förbereda sig är oftast inte själva förnyelsen. Det är att hitta alla certifikat som behöver ett.

Var dina certifikat gömmer sig

De flesta företag har betydligt fler certifikat än de tror, ​​och det gapet är inte ofarligt. Du kan inte förnya det du inte kan se, och ett okänt certifikat på en 47-dagarsklocka är ett avbrott som väntar på att hända. Certifikat hopar sig långt bortom de uppenbara webbservrarna:

• Lastbalanserare (F5 BIG-IP, NetScaler, HAProxy), där ett förnyat certifikat också måste kopplas till rätt virtuell server eller profil på nytt.
• Kubernetes och service meshes, där ingress controllers och service-to-service mTLS utfärdar och roterar certifikat hela tiden.
• CI/CD-pipelines och hemlighetslager (Azure Key Vault, AWS Secrets Manager), där nycklar och certifikat hämtas till byggen och appar.
• Molnbaserade och kortlivade arbetsbelastningar som containrar och serverlösa funktioner, vars adresser kommer och går snabbare än något kalkylblad kan spåra.
• Enheter och IoT, interna mTLS API:er, e-post (S/MIME) och kodsigneringssystem, vart och ett med sin egen konfiguration och ägare.

En riktig inventering kräver mer än en engångsskanning. Bra CLM-plattformar kombinerar flera identifieringsmetoder: agentlös nätverksskanning, agentbaserad skanning på värdar, direkta anslutningar till dina CA:er och molnleverantörer, samt övervakning av certifikattransparensloggar (CT). NIST:s vägledning om TLS-certifikathantering behandlar denna typ av alltid aktuell inventering, med en tydlig ägare för varje certifikat, som det första steget i alla hanterade program.

När du väl kan se helhetsbilden av din organisation är nästa fråga hur du ska hantera den i stor skala. Det handlar om tre förmågor som är beroende av varandra.

De tre pelarna för beredskap

Att förbereda sig handlar mindre om ett verktyg och mer om tre förmågor som fungerar tillsammans. Försvagar man det ena kan de andra två inte kompensera för det.

1. Upptäckt och inventering

Kontinuerlig identifiering ger tillgång till en central, tydlig lista där varje certifikat har en känd plats, utgångsdatum, nyckeltyp, utfärdande certifikatutfärdare och ägare. Detta är den enda sanningskällan som allt annat är beroende av. Utan den förnyar automatiseringen bara de certifikat du redan känner till medan de okända fallerar i tysthet.

2. Styrning och ägarskap

En bra inventering är värdelös om ingen äger varje certifikat. Det är här många team har en verklig lucka. En Gartner-undersökning från 2024 med 335 IAM-ledare visade att identitetsteam endast ansvarar för 44 % av en organisations maskinidentiteter. Resten sitter hos appteam, DevOps eller ingen. Styrning åtgärdar detta genom att sätta tydliga regler för utfärdande (godkända nyckeltyper och algoritmer, vilken CA som ska användas, maximal giltighet och namngivning), genomdriva dessa regler i förfrågningsprocessen, ge varje certifikat en ägare och använda rollbaserad åtkomst och flerpersonsgodkännanden (M av N) för känsliga certifikat.

3. Automatisering

Automation är det som gör den nya takten överlevbar. ACME-protokollet låter programvara begära, validera och förnya certifikat, medan ACME-klienten hanterar distributionen av dem till målsystemet. Självbetjäning låter utvecklare få godkända certifikat på begäran utan att öppna ärenden. Men efter 47 dagar är grundläggande automatisering nödvändig, inte tillräckligt, och hur den är uppbyggd spelar stor roll.

Det är just den byggdetaljen som många program i tysthet misslyckas med, så det är värt att titta närmare på de verktyg som håller automatiseringen tillförlitlig i den här takten.

Hur en 47-dagarsklar uppställning ser ut

En stark uppsättning länkar samman de tre pelarna i en kontinuerlig loop. Identifiering håller det centrala lagret aktuellt. En policykontroll granskar varje begäran mot dina regler innan den utfärdas. En ACME-klient (eller SCEP och EST) skapar ett nytt nyckelpar, helst med den privata nyckeln genererad inuti eller skyddad av en HSM eller molnnyckellagring och aldrig kopierad i klartext, och CA utfärdar efter automatisk validering. Det nya certifikatet och nyckeln distribueras sedan på ett repeterbart sätt till var de än hör hemma, oavsett om det är en lastbalanseringsprofil, en ingångskontroller, en service-mesh-sidecar eller ett hemlighetslager, och det gamla materialet roteras ut snyggt.

Runt den kärnan körs två loopar hela tiden. ACME Renewal Information (ARI, RFC 9773) låter ACME-klienter hämta CA:s föreslagna förnyelsefönster och förnya tidigt inom det. Samtidigt genererar CT-loggövervakning varningar för certifikat som utfärdats utanför organisationens policy. Dashboards och ITSM-integrationer (till exempel ServiceNow) ger certifikatägare insyn och en komplett revisionslogg. En bra tumregel är att starta förnyelsen ungefär en tredjedel av certifikatets livslängd, eller när ARI föreslår, så att det finns utrymme för två fullständiga försök innan det löper ut. Den enda vanan förhindrar de flesta fel som inträffar samma dag.

Att veta hur upplägget ser ut är en sak. Att veta när man ska göra varje del är en annan, och eftersom förändringen sker i etapper är det smarta draget att anpassa arbetet till deadlines.

En enkel plan för 2026 till 2029

Varje fas tar bort ytterligare ett lager av manuella fel, så det du fokuserar på förändras med varje milstolpe. Behandla datumen som deadlines för att bygga kapacitet, inte bara rutor att kryssa i.

Fas	Maximal giltighet	Vad man ska fokusera på
Nu till 2027 mars	200 DAYS	Slutför identifieringen och bygg masterinventariet, tilldela ägare, pilottestera ACME-automation på en upptagen domän och kontrollera DNSSEC- och CAA-poster.
mars 2027	100 DAYS	Ta bort manuell utfärdande från produktion, lansera ARI-medvetna klienter, anslut plattformen till lastbalanserare, Kubernetes och CI/CD, och tillämpa policyer i pipelinen.
mars 2029	47 DAYS	Kör helautomatiska, repeterbara förnyelser från början till slut, bekräfta redundansväxling till en andra CA, testa brådskande tidig förnyelse via ARI och behandla alla manuella förnyelser som ett undantag.

En plan betyder bara något om man kan visa framsteg mot den, och det är där några enkla siffror förvandlar goda avsikter till bevis.

Hur du mäter dina framsteg

Dessa siffror ger PKI- ansvariga en tydlig bild av var de står och vad som behöver åtgärdas härnäst:

• Automatiseringstäckning: andelen certifikat som förnyas utan mänsklig hjälp. Detta är det viktigaste numret och det bör vara nästan totalt före 2029.
• Inventeringens fullständighet: kända certifikat kontra de som hittats genom identifiering och CT-loggövervakning. Gapet är din ohanterade risk.
• Dags att förnya eller ersätta: hur snabbt du kan utfärda och driftsätta ett certifikat på nytt, vilket anger värsta tänkbara avbrott och din reaktionshastighet på en påtvingad återkallelse.
• Avbrott och nära missar från utgångsdatum: målet är noll, och nära missar är en tidig varning.
• Policyefterlevnad: andelen certifikat som följer dina godkända nyckeltyper, algoritmer och giltighet, plus antalet utfärdade utanför policyn.

Samma siffror gör dubbelt jobb eftersom de är precis de bevis som revisorerna efterfrågar, vilket kopplar certifikatverksamheten direkt till ert efterlevnadsarbete.

Hur detta kopplas till efterlevnad

Ett 47-dagarsprogram är lättare att förklara och finansiera när man kopplar det till de standarder som er organisation redan följer. Länkarna är direkta:

Standard	Varför det är viktigt med 47-dagarscertifikat
NIST SP 1800-16	Företagsguide för TLS-certifikathantering: inventering, ägande, automatisering och snabb ersättning.
NIST FIPS 203/204/205	Postkvantstandarder som samma automatisering och kryptoagilitet hjälper dig att driftsätta.
PCI DSS v4.0.1	Kräver användning av stark kryptografi och sund kryptografisk nyckelhantering.
IETF RFC 8555 och RFC 9773	Automatiserings- och förnyelsetidsstandarderna bakom hela pipelinen.

Även med standarder och mätvärden på plats, är det samma handfull misstag som drabbar de flesta team. Att känna till dem i förväg är den billigaste försäkringen man kan få.

Vanliga misstag att undvika

• Förnyar för sent. Att sikta på de sista dagarna ger inget utrymme för en misslyckad kontroll eller driftsättning. Förnya tidigt, ungefär efter en tredjedel av certifikatets livslängd.
• Behandla privata nycklar som portabla. Skapa en ny nyckel för varje förnyelse och skydda den med en HSM eller nyckellagring. Återanvändning av en nyckel vid många förnyelser gör varje läcka mycket mer skadlig, medan frekvent rotation begränsar den.
• Att förlita sig på en enda CA. Att stödja mer än en CA skyddar dig mot CA-avbrott eller en påtvingad massåterkallelse.
• Ignorera icke-webbcertifikat. Interna tjänster, mTLS, enheter och kodsignering utsätts för samma press, även där de offentliga reglerna inte gäller.
• Använder ARI-medvetna klienter som bara körs varje vecka. Hur ofta klienten körs är det verkliga kravet, inte en kryssruta.
• Glömde DNSSEC- och CAA-hygienen, nu när DNSSEC-kontroller krävs och kan blockera automatisk utfärdande.

Att undvika dessa misstag gör mer än att förhindra avbrott. Det bygger upp exakt den kompetens som nästa stora kryptografiska förändring kommer att behöva.

Förbereder sig också för postkvantum

Kortare livslängder är god praxis för en större förändring framöver. I augusti 2024 släppte NIST sina första postkvantkryptografistandarder, FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) , och uppmanar organisationer att börja agera nu.

Att flytta en hel PKI till kvantsäkra algoritmer innebär att byta algoritmer över tusentals certifikat inom en deadline, vilket är precis vad 47-dagars certifikatautomation tvingar dig att bygga idag. Ett team som kan rotera varje certifikat var sjätte vecka, med en fullständig inventering och tydliga regler, är ett team som kan köra en post-kvantmigrering. Kryptoagilitet , möjligheten att ändra algoritmer snabbt och säkert, backad av en kryptografisk materiallista ( CBOM ) som registrerar var varje algoritm och nyckel finns, är den röda tråden som förbinder 47-dagars TLS-certifikatbytet med en kvantsäker framtid. Vårt inlägg om CBOM: från inventering till intelligens förklarar hur den inventeringen blir en handlingsplan.

För att bedöma exakt var er organisation står centraliserar vårt PQC Center of Excellence forskning, verktyg och vägledning för den kommande migreringen, och vår PQC-beredskapsbedömning kartlägger ert certifikat och er kryptografiska tillgång mot den övergången, så att kryptoflexibilitet byggs in innan 47-dagarsschemat och deadlines efter kvantum når samman.

Att bygga allt detta, från identifiering till styrning, automatisering, nyckelskydd och en kryptoagilitetsplan, är ett stort jobb, och det är där vår certifikatlivscykelhanterare hjälper mest.

Hur krypteringskonsulting kan hjälpa

CertSecure Manager från Encryption Consulting LLC är byggt för att hantera utmaningarna med att övergå till kortare certifikatlivslängder, som 47 dagar. Med dessa förändringar blir automatisering avgörande för att effektivt hantera den nya certifikatmiljön.

1. Implementera en CLM-lösning

En CLM-lösning är nyckeln till att effektivt hantera interna och externa certifikat, säkerställa kryptografisk efterlevnad och effektivisera certifikatinventering och rapportering. CertSecure Manager tillhandahåller till exempel en omfattande lösning som automatiserar hela certifikatlivscykeln från upptäckt till distribution, förnyelse och återkallelse, vilket minimerar den manuella ansträngningen som krävs för att hantera certifikat.

Den automatiserar även efterlevnadskontroller för att säkerställa att alla certifikat uppfyller branschstandarder som PCI-DSS , GDPR och ISO. Omfattande rapporter genereras för revisioner, vilket förenklar efterlevnadsprocesserna.

2. Automatiserad certifikatupptäckt och inventering

CertSecure Manager upptäcker automatiskt alla certifikat i din infrastruktur, oavsett om det är lokalt, i molnet eller i hybridmiljöer. Den tillhandahåller en komplett certifikatinventering, vilket säkerställer att inga certifikat lämnas ohanterade, inklusive självsignerade certifikat som kan utgöra en säkerhetsrisk. Med denna centraliserade inventering kan du snabbt identifiera certifikat som behöver förnyas, vilket avsevärt minskar risken för att utgångna certifikat orsakar problem.

3. Avancerad ACME-protokollintegration

Genom att utnyttja ACME-protokollet automatiserar CertSecure Manager utfärdandet och förnyelsen av certifikat på ett säkert och standardiserat sätt. Detta eliminerar manuella åtgärder och säkerställer att certifikat alltid förnyas i tid, även med de frekventa förnyelsecykler som krävs av kortare giltighetsperioder som 47 dagar.

4. Automatisk förnyelse, återutgivning och återkallelse

CertSecure Manager automatiserar förnyelse och återutgivning av certifikat, vilket säkerställer att certifikaten alltid är uppdaterade. Den återkallar även komprometterade eller onödiga certifikat, vilket minskar säkerhetsriskerna och säkerställer efterlevnad.

Denna automatisering säkerställer oavbruten drift inom en organisation och förbättrar säkerheten genom att snabbt åtgärda komprometterade eller onödiga certifikat. Den gör det enklare att uppfylla efterlevnadskrav genom att hantera certifikat i tid, föra tydliga register och förbättra säkerheten, samtidigt som den minskar arbetsbelastningen och bygger förtroende.

5. Efterlevnad och rapportering

CertSecure Manager automatiserar efterlevnadskontroller och säkerställer att dina certifikat uppfyller branschstandarder som NIST, HIPAA och GDPR. Programmet genererar omfattande rapporter för revisionsändamål, vilket gör det enklare att följa myndighetskrav. Dessa rapporter hjälper dig också att bedöma din certifikatinfrastruktur och identifiera potentiella svagheter innan de blir problematiska.

6. Sömlösa integrationer och förnyelseagenter för förbättrad certifikathantering

CertSecure Manager integreras med olika verktyg och plattformar, inklusive Terraform, Ansible, Azure Key Vault och Splunk , för att säkerställa effektiv certifikathantering. Det automatiserar certifikatprovisionering, förnyelse och distribution inom CI/CD-pipelines över databaser, webbservrar (Apache, IIS, NGINX) med mera. Förnyelseagenter är anpassade för dessa tjänster, vilket säkerställer att certifikaten är konsekvent uppdaterade och säkra.

I takt med att branschen nu övergår till 47-dagars giltighetsperioder för certifikat, hjälper CertSecure Managers integrationer och automatiserade processer till att upprätthålla säkerhet, efterlevnad och drifttid genom att hantera förnyelser och certifikat i olika miljöer med minimal manuell ansträngning.

Vad göra här näst

Att uppnå 47-dagars TLS-certifikatberedskap är en insats som sträcker sig över flera team. Det är här varje team bör börja.

• PKI-teamet: Bekräfta att certifikatidentifiering täcker moln-, lokala och hybridmiljöer i lika hög grad, och testa ACME-automatisering på en domän med hög volym nu, inför övergången i mars 2027.
• Säkerhetsteam: Kräv HSM-baserad nyckelgenerering vid varje förnyelse, övervaka certifikattransparensloggar för utfärdande utanför policyn och bekräfta att redundansväxling till en andra certifikatutfärdare testas.
• Plattforms- och DevOps-teamet: Flytta certifikatautomation till ARI-medvetna ACME-klienter och anslut dem till lastbalanserare, Kubernetes-ingångar och CI/CD-pipelines innan manuell utfärdande blir ohållbart vid 100-dagars och 47-dagars giltighetstid.
• Efterlevnadsteamet: Spåra automatiseringstäckning, lagerfullständighet och policyefterlevnadsmått nu så att revisionsbevis redan finns på plats när 47-dagarsfristen infaller i mars 2029.

Slutsats

Övergången till 47-dagarscertifikat är klar, den sker i etapper och den är redan igång. 200-dagarsfasen är igång, 100 dagar infaller i mars 2027 och 47-dagarsgränsen landar 2029, tillsammans med ett 10-dagars DCV-fönster som gör det omöjligt att upprätthålla manuellt arbete.

De team som hanterar detta väl kommer att behandla det som ett designproblem, inte ett förnyelseproblem: se varje certifikat, ge varje certifikat en ägare, sätt tydliga regler, automatisera med ARI i åtanke, skydda dina nycklar, följ schemat och följ dina framsteg med verkliga siffror. Bygg den basen nu, och samma uppsättning kommer att ta dig in i postkvantum-eran. Om du planerar en 47-dagarsklar , kryptoagil PKI är den bästa tiden att börja innan nästa fas anländer.

Vad är den viktigaste lärdomen från PKI år 2026: Hur man överlever 47-dagarseran med TLS-certifikat? Giltighetstiden för offentliga TLS-certifikat är fastställd enligt en fast, redan aktiv nedräkning som fastställts av CA/Browser Forum Ballot SC-081v3: 200 dagar nu, 100 dagar i mars 2027 och 47 dagar i mars 2029. För att överleva detta krävs det att certifikat behandlas som en kontinuerlig, automatiserad disciplin snarare än en årlig förnyelseuppgift, byggd på fullständig certifikatidentifiering, tydligt ägarskap och certifikatautomatisering.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel? I takt med att förnyelsefrekvensen ökar ungefär åtta gånger mellan baslinjen på 398 dagar och gränsen på 47 dagar, förvandlas varje lucka i synlighet eller ägarskap till en proportionellt mer frekvent risk för avbrott, en misslyckad granskning eller ett missat fönster för domänkontrollvalidering. DigiCerts Trust Pulse-undersökning fann att 45 % av organisationerna redan upplevde certifikatrelaterade driftstopp under det senaste året, innan de kortaste fönstren ens träder i kraft.

Vilka team ansvarar för att agera utifrån denna vägledning? Fyra team delar ägarskapet: PKI-teamet, som äger utgivningspolicy och CA-relationer; säkerhetsteamet, som äger nyckelskydd och kryptografisk risk; plattforms- och DevOps-teamet, som äger automatiserad förnyelse och driftsättning; och compliance-teamet, som äger revisionsbevis för certifikattillgångarna. Ägar- och åtgärdsmatrisen i det här inlägget beskriver varje teams specifika ansvarsområden.

Vilka risker ökar om detta ämne hanteras manuellt? Manuell hantering av certifikat ökar risken för missade förnyelser som orsakar avbrott, eftersom utrymmet för fel krymper från dagar eller veckor med en årlig kadens till timmar med 47 dagar, och återanvändningsfönstret på 10 dagar för domänkontrollvalidering innebär att domänkontroll måste bevisas på nytt vid nästan varje förnyelse. Det ökar också risken för att återanvända privata nycklar, beroenden mellan enskilda CA och felaktig DNSSEC- eller CAA-konfiguration helt blockerar automatisk utfärdande.

Hur minskar automatisering risken för certifikatavbrott? Certifikatautomatisering eliminerar missade deadlines och manuella fel som orsakar den överväldigande majoriteten av certifikatavbrott genom att hantera utfärdande, förnyelse och återkallelse enligt ett policystyrt schema, med hjälp av ACME Renewal Information (ARI) för att förnya tidigt inom certifikatutfärdarens föreslagna fönster. Det är också det enda praktiska sättet att hålla jämna steg med den ungefär åttafaldiga ökningen av förnyelsevolymen som 47-dagarsschemat skapar.

Vilka mätvärden bör team spåra efter implementeringen? Spåra automatiseringstäckning (andelen certifikat som förnyas utan mänsklig hjälp, vilket bör vara nästan totalt före 2029), fullständigheten i inventeringen (kända certifikat kontra de som hittats genom identifiering och övervakning av certifikattransparensloggen), tid för förnyelse eller ersättning, avbrott och nära missar från utgångsdatum, samt policyefterlevnad för olika nyckeltyper, algoritmer och giltighetsperioder.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap? Hela den här guiden är färdplanen för 47-dagars TLS-certifikatberedskap: CA/Browser Forums omröstning SC-081v3, godkänd den 11 april 2025, anger det fasta schemat, och beredskap innebär att certifikatidentifiering, styrning och certifikatautomatisering är helt på plats innan 47-dagars, 10-dagars DCV-golvet landar i mars 2029, snarare än att dra ihjäl när deadline har passerat.

Hur ska detta hanteras i miljöer med flera moln eller hybrida PKI-system? Miljöer med flera moln och hybrider behöver en enda, kontinuerligt uppdaterad certifikatinventering som omfattar alla molnleverantörer, lokala system och hybridanslutningspunkter, eftersom fragmenterad synlighet är exakt hur certifikat missas under en 47-dagarsperiod. Centraliserad identifiering, policytillämpning och ARI-medveten automatisering i alla miljöer, snarare än lösningar per molnpunkt, håller förnyelsetidpunkten och ägarskapet konsekvent oavsett var ett certifikat finns.