Googles 90-dagarscertifikat: Snabb och effektiv övergång till 90-dagars TLS/SSL-certifikat

Snabbt svar: Offentliga TLS/SSL-certifikat är inte begränsade till 90 dagar. Enligt CA/Browser Forum Ballot SC-081v3 sjunker den maximala giltighetstiden för certifikat till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. Organisationer som fortfarande utfärdar årliga eller 398-dagars certifikat behöver automatiserad hantering av certifikatlivscykeln på plats före den första deadline.

När Google först lanserade en 90-dagarsgräns för giltigheten av offentliga TLS/SSL- certifikat rapporterades det allmänt som den kommande branschstandarden. Det specifika förslaget blev aldrig en bindande regel. Istället antog CA/Browser Forum Ballot SC-081v3, som fastställer en etappvis, flerårig minskningsplan som landar på 47 dagar till 2029, inte ett enda hopp till 90. Varje certifikathanteringsplan som fortfarande bygger på "90 dagar" är att planera mot en deadline som inte existerar.

Key Takeaways

• 90-dagarsramen är föråldrad: CA/Browser Forum Ballot SC-081v3 (meddelad av Sectigo, 14 april 2025) ersatte alla enskilda 90-dagarsförslag med ett etappvis schema.

• Tre deadlines, inte en: Maximal giltighetstid för publika TLS/SSL-certifikat sjunker till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029.

• Manuell förnyelse sker redan vid dessa intervall: DigiCerts Trust Pulse-undersökning från den 2 juli 2025 fann att 45 % av organisationerna rapporterade certifikatrelaterade driftstopp, och 37.5 % spårade avbrott direkt till utgångna certifikat.

• Spårning i kalkylblad överlever inte 47-dagarscykler: Med ungefär 7–8 förnyelser per certifikat per år multiplicerar manuell spårning den arbetsbelastning som redan idag orsakar avbrott.

• Automatisering är den praktiska vägen: En plattform för hantering av certifikatlivscykel (CLM) som CertSecure Manager är hur de flesta företag möter varje deadline utan problem i sista minuten.

Från Googles 90-dagarsförslag till CA/B-forumets bindande schema

Google tog upp idén om en maximal giltighetsperiod på 90 dagar för publika TLS-certifikat som en del av sin långvariga strävan efter kortare certifikatlivslängder och starkare automatisering i hela webb-PKI-ekosystemet. Förslaget skapade verklig debatt: kortare livslängder minskar explosionsradien för en komprometterad nyckel, men de mångdubblar också den operativa belastningen på varje organisation som fortfarande utfärdar och förnyar certifikat manuellt.

Den debatten löstes genom CA/Browser Forums omröstningsprocess, inte genom ett förslag från en enda webbläsarleverantör. Omröstningen SC-081v3 antogs och tillkännagavs av Sectigo den 14 april 2025, vilket fastställde en etappvis minskning istället för en abrupt övergång till 90 eller 47 dagar. Resultatet är ett schema som varje offentligt betrodd certifikatutfärdare och varje förlitande webbläsare måste följa: 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029.

Innehåll och vägledning som fortfarande fokuserar på "Googles 90-dagarscertifikat" beskriver ett förslag som historien har gått om. Det avgörande dokumentet är CA/B-forumets omröstning, och det operativa antalet som företag bör planera kring är 47 dagar, infasat under ungefär tre år.

Officiella policykällor och ikraftträdandedatum

TLS-certifikatets giltighetstid: 200 → 100 → 47 dagar

Varje steg nedan är bindande för alla offentligt betrodda certifikatutfärdare och upprätthålls av alla större webbläsare som är beroende av förlitande parter. Använd den här tabellen för att jämföra din förnyelsetakt, automatiseringsutrullning och revisionsbevis med de faktiska deadlines.

Implementeringsanmärkning: validera denna tabells ikraftträdandedatum mot den aktuella CA/B-forumets omröstningstext före varje förnyelsecykel, eftersom validerings- och återanvändningsperioder är föremål för ytterligare omröstningar och bör kontrolleras på nytt, inte antas vara statiska.

Varför kortare certifikatlivscykler är viktiga för hantering av företagscertifikatlivscykler

Kortare giltighetsperioder är en direkt respons på ett problem som företag redan har, inte ett nytt som skapas. DigiCerts Trust Pulse-undersökning från juli 2025 visade att 45 % av organisationerna rapporterade certifikatrelaterade driftstopp, och 37.5 % spårade ett avbrott direkt till ett utgånget certifikat. Dessa siffror beskriver dagens miljö med 398-dagars certifikat. En övergång till 47-dagars certifikat åtgärdar inte den underliggande bristen i sig; det tar bort möjligheten att hantera certifikat manuellt och komma undan med det.

Fördelar med certifikat med kortare giltighetstid

• förbättrad säkerhet

  Om en privat nyckel komprometteras, minskar en kortare giltighetsperiod det fönster en angripare kan använda den. Snabbare utgångsdatum och obligatorisk nyckelrotation begränsar skadan även om en kompromiss förblir oupptäckt ett tag.

• Starkare efterlevnadspolicy

  Frekvent, påtvingad förnyelse håller kryptografiska parametrar uppdaterade mot CA/B Forums föränderliga baskrav, vilket minskar risken för att en granskning hittar ett certifikat som utfärdats enligt en föråldrad policy.

• Snabbare anpassningsförmåga

  Organisationer är inte bundna till långsiktiga certifikatåtaganden, så ett nytt algoritmkrav eller en återkallad certifikatutfärdare lämnar inte certifikat strandsatta i ett år eller mer.

• Lägre fönstret för missbruk

  Ett stulet eller felaktigt utfärdat certifikat har kortare tid att användas innan det löper ut av sig självt, utöver eventuella återkallelsesåtgärder.

• Strängare nyckelhantering

  Mer frekventa förnyelser tvingar fram mer frekvent nyckelrotation, vilket är en av de mest effektiva och minst glamorösa kontrollerna inom nyckelhantering.

• Enklare långsiktig CLM

  När automatisering väl är på plats är kortlivade certifikat faktiskt enklare att hantera än långlivade: utfärdande, förnyelse och återkallelse sker alla i samma förutsägbara, automatiserade kadens.

Risker med manuell certifikathantering under kortare livscykler

Ett utgånget certifikat orsakar samma fel idag som det alltid har gjort; kortare cykler betyder bara att det händer oftare om inte förnyelsen är automatiserad.

• Dataöverträdelser

  När ett SSL-certifikat löper ut, försvinner den säkra anslutningen som det skyddade, och angripare kan fånga upp det som tidigare var krypterat under överföringen.

• Serviceavbrott

  Utgångna certifikat tar webbplatser och tjänster offline. Webbläsarvarningar avvisar användare innan de ens ser innehållet, vilket visas direkt i intäkter och supportärenden.

• Sökmotorstraff

  Utgångna SSL-certifikat kan försämra synligheten i sökresultaten, eftersom stora sökmotorer aktivt nedprioriterar webbplatser utan giltig HTTPS.

• Rykteskada

  Ett avbrott orsakat av något så förebyggbart som ett utgånget certifikat urholkar kundernas förtroende på ett sätt som tar betydligt längre tid att återuppbygga än vad själva förnyelsen skulle ha tagit.

Certifikatautomation: Minska risken för avbrott

Automatisering riktar sig direkt mot siffran 37.5 % för avbrott på utgångna certifikat från DigiCerts undersökning. Den tar bort de två saker som orsakar de flesta certifikatavbrott: en människa som glömmer ett datum och en förnyelseprocess som är för långsam för att slutföras innan utgångsdatum.

1. Tids- och kostnadsbesparingar

   Certifikatautomatisering eliminerar manuella överlämningar mellan system, vilket frigör IT- och säkerhetsteam att arbeta med uppgifter med högre värde istället för att jaga förnyelsedatum.

2. Färre mänskliga misstag

   En enda manuell felkonfiguration eller missad förnyelse kan orsaka ett avbrott. Automatisering tillämpar samma validerade process varje gång, vid varje certifikatantal.

3. Inga förnyelser i sista minuten

   Vid 47 dagars giltighetstid är "förnya nästa vecka" inte en gångbar strategi. Automatisk förnyelse utlöses långt före utgångsdatumet, varje cykel, utan att någon behöver komma ihåg det.

4. Starkare säkerhetsställning

   Certifikat som förnyas automatiskt och enligt schemat täcker exakt det gap (utgångna eller förfallna certifikat) som både DigiCert-undersökningen och den här artikelns risklista pekar på som den främsta orsaken till certifikatrelaterade incidenter.

Påverkan per roll och datum: Vem behöver agera och när

47-dagarsschemat berör mer än teamet som klickar på "förnya". Använd denna matris för att styra ägarskapet före deadline i mars 2026, inte efter den.

PKI- och säkerhetsteam

PKI- och säkerhetsteamen äger policybesluten: giltighetsperioder, nyckelstorlekar, servicenivåavtal för återkallelse och vilka certifikatutfärdare som är godkända. Enligt det etappvisa schemat bör dessa team behandla certifikatidentifiering som den första leveransen, inte en eftertanke, eftersom man inte kan automatisera förnyelse för certifikat man inte vet existerar.

Plattforms- och DevOps-team

DevOps- team förbrukar den största andelen certifikat i de flesta organisationer, särskilt i CI/CD -pipelines. API-driven utfärdande via protokoll som ACME, EST eller SCEP är det som gör att certifikat kan tillhandahållas automatiskt under distribution istället för via en ärendekö som inte kan hålla jämna steg med 47-dagars förnyelser.

Compliance-team

Compliance-team behöver certifikatinventering och förnyelsebevis som är aktuella mellan revisioner, inte ett kalkylblad som sammanställs precis före en. En CLM-plattform som genererar rapporter på begäran förvandlar en flera veckor lång revisionsförberedelse till en fråga mot realtidsdata.

Beredskapschecklista och migreringsfärdplan

Checklista för snabb beredskap

• Slutför en fullständig certifikatinventering, inklusive självsignerade certifikat och skuggcertifikat utanför den hanterade certifikatutfärdaren.

• Bekräfta att varje certifikat har en namngiven ägare, inte bara en teknisk kontaktperson som blivit kvar från etableringen.

• Välj och pilottesta en CLM-plattform som kan utfärda ACME-, EST- och SCEP-certifikat före mars 2026.

• Ställ in förnyelseautomationen så att den utlöses med tillräckligt med ledtid för att överleva ett misslyckat första försök.

• Kartlägg nuvarande giltighetsperioder och efterlevnadsramverk så att revisionsbevis är redo före 100-dagarssteget.

• Bekräfta certifikatförfrågningar för CI/CD- och DevOps-pipelines via API, inte manuell inskickning.

Migrationsfärdplan

En CLM-utrullning som uppfyller 47-dagarsfristen utan problem följer i allmänhet samma sekvens:

1. Lager

   Skapa en komplett inventering av alla certifikat i miljön, inklusive de som ingen äger för närvarande. Detta är det steg som de flesta försenade migreringar hoppar över.

2. Certifikatupptäckt

   Kör aktiv och passiv identifiering för att upptäcka dolda och självsignerade certifikat som aldrig har gått igenom en formell utfärdandeprocess; det är ofta dessa som orsakar oväntade avbrott.

3. Övervakning och rapportering

   Inför kontinuerlig övervakning så att avvikelser i utfärdande eller förnyelse upptäcks omedelbart och inte när en tjänst slutar fungera.

4. Automation

   Automatisera förnyelse från början till slut. Vid 47-dagarscykler är det inte längre möjligt att manuellt följa upp med certifikatägare i dagar eller veckor per certifikat.

5. Arbetsflöden och policy

   Centralisera policytillämpningen så att varje ny certifikatförfrågan valideras mot godkända giltighetsperioder, nyckelstorlekar och utfärdande certifikatutfärdare innan den ens utfärdas.

6. DevOps-integration

   Anslut CLM-plattformen till CI/CD-verktyg via API så att certifikat tillhandahålls automatiskt som en del av driftsättningen, vilket matchar behovet av kortare giltighetsperioder.

CertSecure Manager: Automatisera hanteringen av certifikatlivscykeln för 47-dagarseran

CertSecure Manager hanterar hela certifikatlivscykeln (identifiering, inventering, utfärdande, driftsättning, förnyelse, återkallelse och rapportering) genom automatisering snarare än manuell överlämning. Inbyggda varningar flaggar kommande utgångsdatum tillräckligt tidigt för att agera, och rapporteringen är utformad för att stödja efterlevnadskraven för NIST , HIPAA , GDPR och CA/B Forum utan manuell bevisinsamling före varje granskning.

Organisationer som använder CertSecure Manager är positionerade för att gå igenom varje steg i det etappvisa schemat (200 dagar, sedan 100, sedan 47) enligt samma automatiserade process, snarare än att omstrukturera certifikathanteringen varje gång CA/B-forumets krav ändras.

Koppla certifikatautomation till kryptoagilitet och PQC-beredskap

Certifikatautomation är inte bara ett svar på ett kortare giltighetsschema; det är samma operativa kapacitet som post-kvantmigrering är beroende av. En organisation som kan förnya, återutfärda och rotera certifikat automatiskt har redan grunden för kryptoflexibilitet: förmågan att ändra kryptografiska primitiver snabbt och med tillförsikt allt eftersom standarder förändras.

Den kopplingen är direkt viktig för team som redan följer deadlines för post-kvantkryptografi . Encryption Consultings PQC- beredskapsprogram och CBOM Secure- plattform bygger på samma upptäckts- och inventeringsarbete som beskrivs ovan: en komplett, aktuell certifikatinventering är också utgångspunkten för en kryptografisk materiallista (CBOM). Team som redan har automatiserat certifikatlivscykelhantering börjar inte från noll när PQC-migreringsplaneringen börjar.

För en djupare titt på hur man omvandlar det lagret till ett handlingsbart, kontinuerligt underhållet system för register, se hur en kryptografisk materiallista omvandlar lager till information.

Vad göra här näst

• PKI-team: slutför certifikatsökning och inventering och bekräfta att varje certifikat har en namngiven ägare före mars 2026.

• Säkerhetsteam: ange giltighet, nyckelstorlek och återkallningspolicy nu så att det inte ställs in ad hoc under deadlinepress senare.

• Plattformsteam: flytta certifikatförfrågningar i CI/CD-pipelines till API-driven utfärdande före 100-dagarssteget.

• Compliance-team: bekräfta att CLM-rapporteringen överensstämmer med era befintliga revisionsramverk i god tid innan 47-dagarssteget gör manuell bevisinsamling opraktisk.

Slutsats

Certifikatbranschen går inte över till 90 dagars giltighetstid eftersom Google föreslog det. Den går över till 200, sedan 100, sedan 47 dagar eftersom CA/Browser Forum röstade fram ett bindande schema som trädde i kraft. Den skillnaden är viktig eftersom tidslinjen, deadlines och efterlevnadsskyldigheterna skiljer sig från vad innehållet "90-dagars certifikat" fortfarande beskriver.

Organisationer som behandlar detta som en engångsförändring av förnyelsefrekvensen kommer att kämpa i varje steg. Organisationer som behandlar det som en utlösande faktor för att slutligen automatisera hanteringen av certifikatlivscykeln och bygga den kryptoagilitet som automatisering möjliggör, kommer att möta mars 2026, mars 2027 och mars 2029 på samma plattform, utan att omstrukturera sin strategi tre gånger.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen från Googles 90-dagarscertifikat: Snabb och effektiv övergång till 90-dagars TLS/SSL-certifikat?

Googles ursprungliga förslag på 90 dagar ersattes av CA/Browser Forum Ballot SC-081v3, som istället anger ett fasschema: maximal giltighetstid för offentliga TLS/SSL-certifikat sjunker till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. Planerna bör inriktas på detta schema, inte en fast 90-dagarssiffra.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel?

Kortare giltighetsperioder multiplicerar hur ofta varje offentligt certifikat måste förnyas. Företag som hanterar certifikat manuellt kommer att se att förnyelsefrekvensen ungefär fördubblas vid 200-dagarssteget och ökar igen vid varje senare steg, vilket förvandlar en tillfällig uppgift till en konstant driftsbelastning utan automatisering.

Vilka team ansvarar för att agera utifrån denna vägledning?

PKI- och certifikatteam äger inventering, identifiering och policy. Säkerhetsteam fastställer regler för giltighet, nyckelstorlek och återkallelse. Plattforms- och DevOps-team integrerar utfärdande i CI/CD-pipelines. Compliance-team bekräftar att förnyelse- och inventeringsrapportering uppfyller befintliga revisionsramverk under hela övergången.

Vilka risker ökar om detta ämne hanteras manuellt?

DigiCerts Trust Pulse-undersökning från juli 2025 visade att 45 % av organisationerna rapporterade certifikatrelaterade driftstopp, och 37.5 % spårade avbrott direkt till utgångna certifikat under dagens längre giltighetsperioder. Manuell spårning med 47-dagarscykler ökar frekvensen av samma fellägen: avbrott, dataexponering, sökstraff och ryktesskador.

Hur minskar automatisering risken för certifikatavbrott?

Automatiserad förnyelse eliminerar de två främsta orsakerna till certifikatavbrott: en person som glömmer ett förnyelsedatum och en manuell process som är för långsam för att slutföras innan utgången. En CLM-plattform utlöser förnyelse enligt ett fast schema med tillräckligt med ledtid för att återhämta sig från ett misslyckat första försök, oavsett antal certifikat.

Vilka mätvärden bör teamen följa efter implementeringen?

Spåra certifikatinventeringens fullständighet (inklusive självsignerade och skuggcertifikat), andel certifikat som förnyas automatiskt, andel misslyckade förnyelser, genomsnittlig tid för återutfärdande efter ett misslyckande och antalet certifikat som fortfarande kräver manuell åtgärd i varje fas av schemat.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

47-dagarskravet, som träder i kraft i mars 2029, är det sista steget i samma CA/B Forum-schema som diskuteras i den här artikeln. Det upptäckts-, inventerings- och automatiseringsarbete som behövs för 200-dagars- och 100-dagarsstegen är samma grund som 47-dagars certifikatberedskap kräver; det finns inget separat projekt att bygga senare.

Hur ska detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Multimoln- och hybridmiljöer behöver en enda certifikatinventering och CLM-plattform som omfattar alla molnleverantörer och lokala certifikatutfärdare, snarare än separat spårning per miljö. Certifikatidentifiering måste täcka alla miljöer, eftersom skuggcertifikat är mer benägna att visas där infrastrukturen är uppdelad mellan leverantörer.