Certifikatets utgångsdatum kontra certifikatåterkallelse: Viktiga skillnader och varför båda är viktiga för PKI

En avaktiverad server kör fortfarande ett gammalt TLS -certifikat . En anställd som slutade för tre månader sedan har fortfarande ett giltigt klientcertifikat eftersom det aldrig återkallades. En privat nyckel kan ha exponerats under en molnmigrering, men det tillhörande certifikatet visar fortfarande statusen "ännu inte utgånget". Detta är rutinmässiga fel i hur organisationer tänker på certifikatgiltighet, och de har en gemensam grund: att behandla utgång och återkallelse som utbytbara när de inte är det.

Certifikatutgång och certifikatåterkallelse är separata mekanismer, definierade separat i RFC 5280, som tjänar olika syften i X.509-förtroendemodellen. Certifikatutgång är en schemalagd händelse som skrivs in i certifikatet vid utfärdandetillfället. Certifikatåterkallelse är en avsiktlig handling av den utfärdande certifikatutfärdaren, utlöst av ett specifikt villkor som gör certifikatet opålitligt före dess schemalagda slutdatum.

Att blanda ihop de två leder till verkliga luckor: organisationer som hanterar förnyelsekalendrar noggrant men inte har någon sammanhängande återkallningspolicy, eller team som återkallar certifikat efter en viktig kompromiss men inte har någon insyn i vilka endpoints som fortfarande presenterar dem.

Konsekvenserna är inte abstrakta. Den 3 februari 2020 gick Microsoft Teams offline i nästan tre timmar efter att ett autentiseringscertifikat hade löpt ut utan förnyelse. Microsofts eget statusinlägg bekräftade orsaken: ett autentiseringscertifikat hade löpt ut, vilket orsakade problem för användare att använda tjänsten. Den 19 augusti 2020 stördes Spotify-användare i ungefär en timme när ett TLS-wildcard-certifikat löpte ut, vilket tog streamingtjänster offline. Båda incidenterna kunde förebyggas. Ingen av dem krävde en sofistikerad attack. De krävde bara att ingen bevakade utgångsdatumet. DigiCert Trust Pulse Survey (juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp under föregående år, vilket bekräftar att dessa två incidenter inte är avvikelser utan representativa för ett utbrett driftsgap.

Den här guiden beskriver vad varje mekanism betyder, vad som skiljer dem åt och vad en funktionell certifikatlivscykel kräver av båda.

Snabbt svar: Vad är skillnaden mellan certifikatutgång och certifikatåterkallelse?

Certifikatets utgångsdatum är en passiv, schemalagd gräns som är kodad i X.509 notAfter-fältet vid utfärdande. Varje förlitande part avvisar ett utgånget certifikat automatiskt med hjälp av systemklockan, utan att någon infrastruktur krävs. Återkallelse av certifikat är en aktiv CA-deklaration om att ett certifikat inte är tillförlitligt före dess notAfter-datum, vilket kommuniceras via CRL:er (RFC 5280) eller OCSP (RFC 6960). Båda krävs. Ingendera är tillräckligt ensamt.

Key Takeaways

• Certifikatets utgångsdatum är passivt och infrastrukturfritt: förlitande parter avvisar utgångna certifikat med endast systemklockan och notAfter-fältet från RFC 5280. Inget nätverksanrop, inget CA-beroende, ingen aktualitetsproblem. Det kan inte misslyckas på grund av infrastrukturavbrott eftersom det inte har någon.
• Återkallelse av certifikat är aktiv och infrastrukturberoende: det kräver att CA registrerar återkallelsen, publicerar en CRL eller svarar på OCSP-frågor, och att förlitande parter faktiskt kontrollerar. Om CRL-distributionspunkten inte kan nås eller om OCSP-svararen får timeout, kanske återkallelsen inte når de system som behöver agera på den.
• De två mekanismerna hanterar olika fellägen. Utgångsdatum svarar på om ett certifikat har nått sitt planerade slut på sin livslängd. Återkallelse svarar på om något har ändrats under certifikatets giltighetsperiod som gör det opålitligt. En nyckel som komprometteras på dag 10 av ett ettårigt certifikats livslängd lämnar 355 dagar av giltigt utseende förtroende som endast återkallelse kan avsluta.
• RFC 5280 definierar tio orsakskoder för återkallelse (värden 0-10, med värde 7 oanvänt). keyCompromise-koden (1) utlöser CA/Browser Forum Baseline Requirements 24-timmars återkallningsfönstret för offentligt betrodda TLS-certifikat. certificateHold-koden (6) missbrukas ofta som en ersättning för permanent återkallelse när nyckeln komprometteras; detta är helt fel och lämnar ett potentiellt komprometterat certifikat i ett återställningsbart tillstånd.
• CA/Browser Forum-omröstningen SC-081v3 (godkänd 11 april 2025, 29 röster för, noll emot, fem nedlagda röster) inriktar maximal giltighetstid för offentliga TLS-certifikat till 200 dagar (mars 2026), 100 dagar (mars 2027) och 47 dagar (mars 2029). Kortare livslängder minskar risken för oupptäckta komprometter. Den motiveringen gäller inte privata PKI-, kodsignerings- eller IoT-enhetscertifikat, vilka har fleråriga giltighetsperioder och kräver en fungerande återkallningsinfrastruktur.

Vem borde bry sig om certifikatets utgång och återkallelse

Certifikatutgång och återkallelse är operativa PKI-frågor, men konsekvenserna av att göra fel räcker för hela organisationen. Varje team som listas nedan har en anledning att förstå både mekanismerna och en specifik åtgärd att vidta.

Roll	Varför det gäller	Åtgärdsobjekt
PKI-administratörer	Ansvarar för den tekniska driften av båda mekanismerna: köra certifikatidentifiering för att hitta alla certifikat inom omfattningen, övervaka utgångstidslinjer med automatiserade förnyelsearbetsflöden, utföra återkallelse hos CA när det utlöses, underhålla CRL-publiceringsscheman och validera CRL-distributionspunkter och OCSP-svarares tillgänglighet från alla relevanta nätverkssegment.	Granska alla aktiva CRL-distributionspunkter och OCSP-svarare för nåbarhet från varje nätverkssegment där utfärdade certifikat valideras; bekräfta att CRL-publiceringsscheman producerar giltiga CRL:er med tillräcklig överlappning innan den föregående CRL:en löper ut; ansluta alla certifikatpopulationer till CertSecure-hanterare för kontinuerlig övervakning av utgångsdatum och automatisk förnyelse
Säkerhetsarkitekter	Ansvarar för utformningen av återkallningspolicyn: definiera vilka specifika händelser som utlöser återkallelse (nyckelkomprometterad, anställds avgång, systemavstängning, felaktig utfärdande), vilket återkallelsetillstånd som är lämpligt för varje händelsetyp (permanent återkallt kontra certificateHold), den maximala tiden som tillåts mellan en utlösande händelse och slutförd återkallelse, och de erforderliga giltighetsperioderna för varje certifikattyp i förhållande till den förtroendelivscykel de representerar.	Skriv en formell återkallningspolicy som mappar varje utlösande händelse till en orsakskod för återkallelse, en ägare och ett svarstidskrav; inkludera privata PKI-, kodsignerings- och IoT-enhetscertifikat i återkallningspolicyns omfattning, inte bara offentligt betrodda TLS-certifikat; inkludera kryptografisk inventering över alla CA-källor i återkallningsstyrningsomfattningen med hjälp av CBOM-säkerhet
Plattforms- och molnteam	Ansvara för att CRL-distributionspunkter och OCSP-svarare är nåbara från molnarbetsbelastningar, containrar och hybridmiljöer; en CRL som är åtkomlig från lokala miljöer men blockerad av en molnnätverkssäkerhetsgrupp producerar tysta återkallningsfel för molnbaserade tjänster; certifikatintensiva miljöer (Kubernetes, service mesh, API-gateways) måste ha återkallningskontroll konfigurerad och testad.	Testa CRL- och OCSP-nåbarhet från alla moln- och containermiljöer som en del av validering av infrastruktur som kod; inkludera övervakning av certifikatutgång i plattformens observerbarhetsstackar; bekräfta att service mesh- och API-gatewaykonfigurationer tillämpar certifikatvalidering inklusive återkallningskontroll, inte bara utgångskontroller.
Compliance-team	Måste visa att det finns en återkallningspolicy, att den följs, och att infrastrukturen som stöder återkallelse (CRL-distribution, OCSP) är testad och operativ; NIST SP 800-53 Rev. 5 kontrollerar SC-12 och SC-17 täcker hantering av kryptografisk nyckel och styrning av PKI-certifikats livscykel; revisorer efterfrågar i allt högre grad bevis på att återkallningsinfrastrukturen är åtkomlig och att återkallningshändelser slutförs inom det dokumenterade policyfönstret.	Inkludera kvartalsvisa CRL- och OCSP-nåbarhetstestresultat i efterlevnadsdokument; dokumentera återkallningspolicyn och bekräfta att alla utlösande händelsetyper har en namngiven ägare och ett svarstidskrav; bekräfta att CA-granskningsloggar som registrerar återkallningshändelser sparas under den erforderliga perioden och vidarebefordras till SIEM för övervakning.
CISO: er	Certifikatets utgång rankades bland de tre största CISO-problemen (DigiCert Trust Pulse Survey, juli 2025, 56.6 procent); återkallningsfel är den mindre synliga halvan av samma problem; en viktig kompromisshändelse som återkallas hos CA men vars återkallelse inte kan valideras av förlitande parter eftersom CRL-distributionspunkten inte är nåbar ger falsk försäkran om att exponeringen har begränsats när den inte har gjort det.	Kräv ett formellt program för hantering av certifikatlivscykeln som täcker både övervakning av utgångsdatum och återkallningspolicy som finansierade, kontinuerliga aktiviteter; kräv årlig testning av återkallningsinfrastruktur som en PKI-hälsokontroll; utvärdera PKI som en tjänst för organisationer vars interna PKI-infrastruktur gör det svårt att upprätthålla underhållet av återkallningsinfrastrukturen

Utgångsdatum kontra återkallelse: Beslutsmatris per scenario

Använd den här matrisen för att avgöra vilken mekanism som gäller för varje scenario, dess säkerhetspåverkan, den operativa insats som krävs, hur väl den passar in i automatiserade arbetsflöden och vem som äger responsen.

Scenario	Mekanism	Säkerhetspåverkan	Operativ insats	Automatiseringsanpassning	Rekommenderad ägare
Certifikatet når normalt sitt notAfter-datum	Utgångsdatum (passivt)	Avbrott i tjänsten om förnyelsen inte har slutförts före utgångsdatumet; ingen säkerhetsincident om certifikatet var i gott skick	Låg med automatisering; hög utan	Utmärkt: CLM-plattformar automatiserar förnyelsearbetsflöden med utgångsdatumbaserade utlösare	PKI-administratör
Privat nyckel bekräftad eller misstänkt komprometterad	Återkallelse (permanent, orsakskod 1 för nyckelkompromettering)	Kritiskt: alla certifikat som är bundna till den komprometterade nyckeln måste återkallas omedelbart; CA/Browser Forum Baseline Requirements kräver återkallelse inom 24 timmar för offentligt betrodda TLS-certifikat.	Hög: kräver snabb identifiering av alla certifikat som är bundna till nyckeln, återkallelse hos CA och bekräftelse av CRL/OCSP-spridning	Måttlig: CLM kan identifiera alla certifikat som är bundna till en nyckel och utlösa massåterkallelse; CRL-spridningstimingen ligger utanför CLM:s kontroll	PKI-administration + säkerhetsteam (gemensam respons)
Avgång medarbetare med aktiva klientcertifikat	Återkallelse (permanent, affiliationChanged orsakskod 3 eller cessationOfOperation orsakskod 5)	Hög: ett aktivt klientcertifikat för en avgången anställd kan användas för autentisering tills det löper ut eller återkallas; fönstret beror på certifikatets återstående giltighetstid.	Medium: kräver identifiering av alla aktiva certifikat som är kopplade till identiteten, samordning med HR-offboarding och återkallelse hos CA	Bra: CLM-plattformar med integration med identitetssystem kan utlösa återkallelse som en del av HR-offboarding-arbetsflöden	PKI-administratör + HR/identitetsteam
System eller tjänst avställd	Återkallelse (permanent, orsakskod 5 för driftsavbrott)	Medium: ett oåtkomligt systemcertifikat som fortfarande är tekniskt giltigt kan användas för att imitera den avaktiverade tjänsten om den privata nyckeln är tillgänglig från ett annat system.	Låg till medel: avvecklingsarbetsflöden bör inkludera ett återkallningssteg; om systemet är oåtkomligt kan CA återkalla utan slutpunktens inblandning	Bra: CLM-automatisering kan inkludera återkallelse som ett steg i systemavvecklingsrunbooks	PKI-administratör + plattformsteam
Certifikatet är felaktigt utfärdat eller innehåller felaktig information	Återkallelse (permanent, ospecificerad orsakskod 0 eller ersatt orsakskod 4)	Hög: ett certifikat med felaktig information i ämnet eller SAN:erna ger falsk identitetsgaranti till förlitande parter	Medium: kräver att det felaktigt utfärdade certifikatet identifieras, återkallas och ett korrekt ersättningscertifikat utfärdas på nytt.	Bra: CLM-upptäckt avslöjar felaktigt utfärdade certifikat; återkallelse och återutgivning kan utlösas från CLM-gränssnittet	PKI-administratör
Enhet rapporterad stulen, senare återfunnen intakt med nyckel bekräftad oåtkomlig	CertificateHold (orsakskod 6), reversibel om säkert bekräftat	Medium under spärrning: förlitande parter som kontrollerar CRL/OCSP ser spärrningsstatus; om återkallningskontrollen är ofullständig kan certifikatet fortfarande accepteras under spärrperioden.	Medel: kräver att spärrning görs, enhetsundersökning slutförs och att spärren hävs eller eskaleras till permanent återkallelse baserat på resultaten	Måttlig: CLM kan placera och häva spärr; men risken för missbruk av spärr kräver mänsklig bedömning vid eskalering	PKI-administration + säkerhetsteam (gemensamt beslut)
Certifikat för IoT eller enhet med flerårig giltighet och ingen förnyelseprocess	Endast utgångsdatum (återkallelse måste också finnas men förnyelse kan kräva fysisk åtkomst)	Hög om kompromettering inträffar: hela den återstående giltighetsperioden exponeras; återkallelse är den enda kontrollen; utan nåbar CRL/OCSP från enhetens nätverk kan återkallelse inte valideras	Hög: enhetens firmware och nätverksarkitektur måste stödja CRL-hämtning eller OCSP-kontroll från enhetens driftsmiljö.	Dålig förnyelse; CLM kan övervaka och varna men förnyelse kan kräva en process utanför bandet	PKI-administration + drift-/OT-team

Vad certifikatets utgång innebär

Varje X.509-certifikat innehåller ett giltighetsfält med två underfält: notBefore och notAfter. Dessa ställs in vid utfärdande och är inbäddade i själva certifikatet. Fältet notBefore markerar när certifikatet blir aktivt. Fältet notAfter markerar när det slutar accepteras. När systemklockan passerar certifikatets notAfter-tidsstämpel avvisar en kompatibel förlitande part certifikatet automatiskt, utan någon signal från CA, utan att kontrollera någon extern tjänst och utan någon mänsklig intervention.

Det automatiska avslaget är kärnvärdet för utgångsdata. Det är en hård, lokal, passiv gräns för förtroende. En TLS-klient kontrollerar systemklockan mot notAfter-fältet och fattar sitt beslut helt själv. Det finns inget nätverksanrop, inget beroende av en server som körs och ingen aktualitetsproblem. Mekanismen kan inte misslyckas på grund av driftstopp i infrastrukturen eftersom den inte har någon infrastruktur.

Enligt RFC 5280 kodas dessa datum som UTCTime för datum fram till 2049 och som GeneralizedTime för datum under 2050 eller senare. För certifikat som är avsedda att inte ha något definierat slutdatum, såsom vissa enhetsidentitetscertifikat, specificerar RFC 5280 GeneralizedTime-värdet 99991231235959Z. Dessa certifikat är i praktiken giltiga för operativa ändamål. Om inte något aktivt avslutar deras förtroende förblir de giltiga mycket längre än någon realistisk system- eller distributionslivscykel.

Begränsningen av utgångsdatumet är just dess passivitet. Den reagerar inte på händelser. Om en privat nyckel stjäls på dag tio av ett ettårigt certifikats livslängd, förblir certifikatet giltigt ur den förlitande partens perspektiv under de återstående 355 dagarna. Ingenting i notAfter-fältet återspeglar att det underliggande förtroendet redan har brutits. Expiry hanterar schemalagt slut på livslängden. Den har ingen mekanism för att hantera oplanerad förlust av förtroende.

Vad återkallelse av certifikat innebär

Återkallelse är CA:s deklaration att ett certifikat inte längre är tillförlitligt före dess not-After-datum. Det är en aktiv, avsiktlig handling. Certifikatutfärdaren (CA) markerar certifikatet som ogiltigt, och den informationen kommuniceras sedan till förlitande parter genom en av två mekanismer: en certifikatåterkallningslista (CRL) eller Online Certificate Status Protocol (OCSP).

RFC 5280 definierar två återkallelsetillstånd. Det första är "återkallat", vilket är permanent och oåterkalleligt. När ett certifikat har återkallats förblir det återkallat. Det andra är "certificateHold", en tillfällig avstängning som kan hävas. Hold används sällan i praktiken och har begränsad säkerhetsnytta eftersom en förlitande part inte kan veta när eller om det kommer att hävas.

RFC 5280 definierar tio orsakskoder som en CA kan koppla till en återkallningspost: unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9) och aACompromise (10). Observera att värde 7 inte används. Dessa orsakskoder är inte bara administrativa etiketter. De har en operativ betydelse.

keyCompromise-koden signalerar att den privata nyckeln har exponerats. Enligt CA/Browser Forum Baseline Requirements måste ett offentligt betrott TLS-certifikat återkallas inom 24 timmar efter bekräftad nyckelkompromettering. affiliationChanged- eller ersatta koder gäller när en certifikatinnehavares identitet eller roll har ändrats, inte för att nyckeln har komprometterats, utan för att bindningen inte längre är korrekt.

Återkallelse är den mekanism som reagerar på händelser. Att förstå när man ska använda varje återkallelsetillstånd är viktigt i praktiken. Permanent återkallelse, det "återkallade" tillståndet, gäller när den underliggande orsaken är definitiv och oåterkallelig. En privat nyckel som bekräftats som komprometterad måste återkallas permanent: det finns inget scenario där nyckeln blir tillförlitlig igen. Detsamma gäller när en anställd lämnar organisationen, när ett system tas ur drift eller när ett certifikat utfärdas felaktigt. I alla dessa fall existerar inte längre identiteten som binder certifikatet, och återställning av certifikatet skulle inte tjäna något legitimt syfte.

Tillståndet ”certificateHold” täcker en snävare och genuint tillfällig uppsättning omständigheter. Tänk dig en enhet som har rapporterats stulen men senare återfunnits intakt, med den privata nyckeln bekräftad som oåtkomlig. Eller ett certifikat som är bundet till ett tjänstkonto som migreras till ett nytt system, där åtgärder pausas under ett definierat fönster, och samma certifikat återupptas när migreringen är klar. Hold är rätt val när det oroväckande tillståndet är reversibelt och organisationen förväntar sig att återställa certifikatet.

Det är fel val när villkoret är säkerhetsdrivet och permanent, till exempel att använda spärr istället för återkallt tillstånd, eftersom återkallelse känns drastiskt, eller eftersom återutgivning är obekväm. Missbruk av spärr lämnar ett potentiellt komprometterat certifikat i ett återställbart tillstånd, vilket är just den exponering som återkallelsen är utformad för att avsluta.

Där utgångsläget hanterar schemalagt slut på livscykeln, hanterar återkallelse alla scenarier där förtroendet upphör innan schemat gör det.

Hur återkallelsestatus kommuniceras

Att återkalla ett certifikat hos CA gör ingenting för förlitande parter om inte den statusen kommuniceras och kontrolleras. Det finns två mekanismer för detta.

Certifikatåterkallningslistor (CRL), definierade i RFC 5280 avsnitt 5, är CA-signerade filer som innehåller serienumren för certifikat som återkallats av den utfärdande CA:n. En förlitande part laddar ner CRL:n, kontrollerar om certifikatets serienummer visas i den och agerar därefter. CRL-poster tas inte bort när ett certifikat löper ut. Enligt RFC 5280 avsnitt 3.3 måste en post finnas kvar på CRL:n tills den visas på minst en regelbundet schemalagd CRL som publiceras efter certifikatets utgångsdatum. Detta säkerställer att ett certifikat som återkallats strax före utgångsdatum inte i det tysta tas bort från listan innan klienter har haft möjlighet att ta emot den uppdaterade CRL:n.

CRL:er har en spridningsfördröjning. En certifikatutfärdare publicerar en ny CRL enligt ett schema, vanligtvis var 24:e till 72:e timme, för många företagscertifikatutfärdare. Ett certifikat som återkallas omedelbart efter en CRL-publicering kommer inte att visas för förlitande parter förrän nästa har publicerats och hämtats. Under den perioden kan ett återkallat certifikat fortfarande klara CRL-kontroller. CRL:er växer också över tid i takt med att fler certifikat återkallas, vilket ökar nedladdningskostnaden för klienter.

OCSP (Online Certificate Status Protocol), definierat i RFC 6960, åtgärdar skalningsproblemet genom att göra återkallningskontroll per certifikat och på begäran. En klient skickar en begäran som innehåller certifikatets serienummer till en OCSP-responder. Respondern returnerar en av tre statusar: bra, återkallad eller okänd.

Bra betyder att det inte finns någon återkallningspost för det serienumret inom dess giltighetstid. Det bekräftar inte att certifikatet utfärdades på ett giltigt sätt. Återkallat betyder att certifikatet har återkallats, vanligtvis med en orsakskod och en tidsstämpel. Okänt betyder att svararen inte kan fastställa certifikatets status, vilket kan indikera att certifikatet inte utfärdades av den certifikatutfärdaren.

I moderna TLS-distributioner tillåter OCSP Stapling en server att hämta och cachelagra ett OCSP-svar och bifoga det direkt till TLS-handskakningen , vilket minskar eller eliminerar behovet för klienter att själva fråga OCSP-respondern. Detta förbättrar prestandan och mildrar integritetsproblemet för klienter som avslöjar sin certifikatvalideringsaktivitet för CA. OCSP Stapling definieras i RFC 6066 genom TLS status_request-tillägget och stöds i både TLS 1.2- och TLS 1.3-distributioner.

Kärnskillnaden i praktiken

Utgångsdatum och återkallelse är inte överflödiga. De åtgärdar olika fellägen.

• Utgångsdatumet svarar: ”Har det här certifikatet nått sitt schemalagda slut?” Det tillämpar den gränsen automatiskt, utan infrastruktur, baserat endast på systemklockan och notAfter-fältet. Det är tillförlitligt och passivt. Det reagerar inte på något som händer under certifikatets giltighetsperiod.
• Återkallelse svarar: ”Har något ändrats sedan detta certifikat utfärdades som gör det opålitligt?” Det kräver aktiv CA-åtgärd, kommunikationsinfrastruktur (CRL eller OCSP) och förlitande parter som kontrollerar. Det är inte passivt. Det kan sluta fungera om infrastrukturen är nere, inaktuell eller oåtkomlig.

Ett certifikat som har gått ut i en vecka är helt enkelt utgånget. Varje klient avvisar det omedelbart, utan att ifrågasätta, utan att kontrollera någonting. Ett certifikat som återkallats för två dagar sedan men ännu inte har gått ut kräver att den förlitande parten kontrollerar CRL :n eller OCSP:n, får ett återkallat svar och agerar utifrån det. Om den kontrollen misslyckas eller hoppas över kan certifikatet fortfarande accepteras. Den asymmetrin är anledningen till att kvaliteten på återkallningsinfrastrukturen är viktig. Mekanismen fungerar bara när infrastrukturen som stöder den fungerar.

Där var och en bryts ner

Utgångsdatum misslyckas när giltighetsperioden är för lång i förhållande till det förtroende det representerar. Ett treårigt certifikat som utfärdats till en anställd som lämnar organisationen inom 90 dagar har mer än 1 000 dagars återstående giltighetstid, vilket inte längre återspeglar någon legitim identitetsbindning. Certifikatet återkallades aldrig. Det kommer att fortsätta att genomgå utgångskontroller. Om den anställde behöll åtkomst till den privata nyckeln och organisationen inte har någon återkallningskontroll, förblir certifikatet användbart i nästan tre år till.

Utgångsdatumet misslyckas också helt för certifikat med obestämd giltighet. Ett enhetscertifikat som utfärdats med värdet 99991231235959Z GeneralizedTime har inget utgångsskydd alls. Om enheten tas ur drift, nyckeln komprometteras eller certifikatet felaktigt utfärdas är återkallelse den enda tillgängliga kontrollen. Det finns inget schemalagt slutdatum att förlita sig på.

Återkallelse förlorar sin effektivitet när den stödjande infrastrukturen inte underhålls. En certifikatutfärdare som tekniskt sett har återkallat ett certifikat men vars CRL-distributionspunkts-URL inte kan nås från det relevanta nätverkssegmentet, eller vars OCSP-responder får timeout under belastning, har utfärdat en återkallelse som ingen förlitande part kan agera på. Återkallelsen finns i certifikatutfärdarens databas. Den når inte de system som behöver se den.

Återkallelse blir också mindre kritisk som en kompenserande kontroll för kortlivade offentliga certifikat när kontrollen är otillförlitlig i stor skala. Detta är en av motiven bakom CA/Browser Forum-omröstningen SC-081v3, godkänd den 11 april 2025, med 29 röster för, noll emot och fem nedlagda röster. Omröstningen minskar den maximala giltighetstiden för offentliga TLS-certifikat från 398 dagar till 200 dagar i mars 2026, sedan till 100 dagar i mars 2027 och slutligen till 47 dagar i mars 2029.

Med en maximal giltighetsperiod på 47 dagar har en oupptäckt nyckelkomprometterad ett begränsat fönster oavsett om återkallningskontrollen lyckas eller misslyckas. Den motiveringen gäller inte privata PKI- , kodsignerings- eller IoT-enhetscertifikat, som ofta har fleråriga giltighetsperioder och inte kan använda kort giltighet som ersättning för fungerande återkallningsinfrastruktur.

Varför båda måste arbeta tillsammans

Ingen av mekanismerna är tillräcklig ensam. Utgångsdatum utan återkallelse lämnar ett fönster på potentiellt år där ett komprometterat eller felaktigt utfärdat certifikat förblir giltigt. Återkallelse utan disciplinerad hantering av giltighetstiden placerar hela förtroendegränsen på infrastruktur som kan bli inaktuell, oåtkomlig eller försummad.

De två mekanismerna är utformade för att komplettera varandra. Utgångsdatum sätter en hård yttre gräns för förtroendefönstret. Återkallelse ger möjlighet att stänga det fönstret i förtid när händelser kräver det. En organisation som hanterar båda effektivt vet när varje certifikat den har utfärdat kommer att löpa ut, upprätthåller en återkallningsinfrastruktur som faktiskt är tillgänglig för de system som behöver kontrollera den, och har en policy som mappar specifika händelser, såsom nyckelkompromettering, anställds avgång eller systemavveckling, till en återkallningsåtgärd med en definierad tidslinje.

Speciellt för privata PKI innebär avsaknaden av extern tillämpning från webbläsarens rotprogram eller CA/B-forumskrav att kvaliteten på både utgångshantering och återkallningsinfrastruktur helt och hållet är en funktion av interna designval. En privat CA-hierarki som utfärdar certifikat utan nåbara CDP- och AIA-tillägg, eller utan någon OCSP-responder, har ingen effektiv återkallningsmekanism oavsett vad dess konfiguration påstår. Certifikaten ser återkallbara ut på pappret. Det är de inte. För organisationer som bygger en komplett kryptografisk inventering som inkluderar privata PKI-certifikatpopulationer, tillhandahåller CBOM Secure den miljöövergripande maskinidentitetsidentifieringen som möjliggör återkallningsstyrning i stor skala över hybrid- och multi-CA-miljöer.

Att förstå skillnaden mellan utgångsdatum och återkallelse är inte en teoretisk övning. Det är grunden för att veta vad en organisations PKI kan och inte kan göra när något går fel mitt i livscykeln. I takt med att införandet av postkvantkryptografi accelererar efter publiceringen av NIST FIPS 203, 204 och 205 (13 augusti 2024), måste ramverket för återkallelse- och utgångsdatumsstyrning även omfatta de privata CA-hierarkier som kommer att utfärda ML-DSA-baserade certifikat. PQC Readiness- bedömningstjänster och PQC Center of Excellence hjälper organisationer att planera hur algoritmövergångar påverkar certifikatgiltighetsperioder och design av återkallningsinfrastruktur.

Hur krypteringskonsulting kan hjälpa

Encryption Consultings PKI-bedömning är ett strukturerat uppdrag som utvärderar hela er PKI-miljö utifrån tekniska, operativa och styrande dimensioner. Det börjar med identifiering: kartläggning av er nuvarande PKI-arkitektur i lokala, moln- och hybridmiljöer för att skapa en komplett bild av vad som finns, hur det är konfigurerat och var det ansluter.

Detta inkluderar validering av certifikatutfärdarhierarki, granskning av certifikatmallar, nyckelhanteringsmetoder och ett heltäckande test av din återkallningsinfrastruktur, vilket verifierar att CDP- och AIA-tillägg i utfärdade certifikat pekar på svarare och distributionspunkter som faktiskt är nåbara från de nätverkssegment där certifikat valideras.

Därifrån fångar strukturerade intressentworkshops och arkitekturkartläggningssessioner den operativa verkligheten bakom konfigurationen. Dessa sessioner belyser de luckor som dokumentationen ensam inte visar: PKI-infrastrukturpolicyer som finns på papper men inte tillämpas, OCSP-svarare som är tekniskt distribuerade men otestade under belastning och certifikatpopulationer som utfärdats enligt mallar som inte längre återspeglar aktuella säkerhetsstandarder.

Resultatet är en prioriterad risk- och gapanalysrapport. Resultaten rangordnas efter allvarlighetsgrad och mappas till specifika åtgärdsåtgärder, vilket ger ditt team en tydlig färdplan snarare än en generisk checklista.

CertSecure-hanterare

CertSecure Manager tillhandahåller det operativa lagret som kontinuerligt kopplar samman spårning av utgångsdatum och återkallelse. Det upprätthåller en aktiv certifikatinventering över publika CA:er, privata CA-hierarkier, HashiCorp Vault och Microsoft PKI-miljöer. Några av de viktigaste funktionerna i CertSecure Manager inkluderar:

• Centraliserad certifikatinventering: Upptäcker och inventerar automatiskt certifikat i moln-, lokala och hybridmiljöer.
• Automatiserad livscykelhantering: Hanterar utfärdande, förnyelse och återkallelse av certifikat med minimal mänsklig inblandning.
• Policy Enforcement Engine: Säkerställer efterlevnad av företagets säkerhetspolicyer och branschstandarder.
• Rollbaserad åtkomstkontroll (RBAC): Tillhandahåller detaljerad åtkomsthantering för att säkerställa att endast behöriga användare kan hantera certifikat.
• Integration med ledande certifikatutfärdare och DevOps-verktyg: Integreras sömlöst med offentliga och privata certifikatutfärdare, samt CI/CD-pipelines.
• Realtidsövervakning och aviseringar: Erbjuder instrumentpaneler och aviseringar för certifikat som löper ut eller är felkonfigurerade.
• Revision och rapportering: Upprätthåller detaljerade loggar och rapporter för efterlevnad och forensisk analys.

Tillsammans ger dessa funktioner ditt team insyn och kontroll för att hantera certifikatutgångar och återkallelser, inte som reaktiva uppgifter, utan som en kontinuerlig, granskningsbar process.

Slutsats

Certifikatets utgång och återkallelse åtgärdar olika fellägen vid olika tidpunkter i certifikatets livscykel. Utgångstiden begränsar den totala förtroendetiden och upprätthåller den gränsen automatiskt. Återkallelse hanterar de fall där förtroendet förloras innan tiden löper ut. Båda är nödvändiga, och ingen av dem fungerar tillförlitligt utan att infrastrukturen bakom dem beaktas.

I takt med att giltighetstiden för offentliga TLS förkortas enligt SC-081v3, kommer effekten av misslyckade återkallelser att minska i takt med att certifikatens livslängd förkortas. För privata PKI- , kodsignerings- och enhetscertifikat förändras inte den verkligheten.

För organisationer som vill utvärdera sin nuvarande PKI-situation, identifiera luckor i infrastrukturen för återkallelse eller stärka hanteringen av certifikatlivscykeln, kan en omfattande PKI-bedömning och automatiserad plattform för hantering av certifikatlivscykeln ge den insyn och kontroll som behövs för att hantera certifikat under hela deras livscykel.

Organisationer som behandlar återkallelse som en sekundär fråga i miljöer med lång livslängd antar att ingenting i deras PKI- tillgångar kommer att ändras före notAfter-datumet. Det är inte en säkerhetsarkitektur. Det är en kalender.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från certifikatutgång kontra certifikatåterkallelse?

Certifikatutgång och certifikatåterkallelse är separata mekanismer som definieras separat i RFC 5280 och som adresserar olika fellägen. Utgångsdatum är passivt: det tillämpar automatiskt en hård, schemalagd gräns med hjälp av notAfter-fältet och systemklockan, utan att någon infrastruktur krävs. Återkallelse är aktivt: det kräver att CA:n förklarar ett certifikat som opålitligt före dess notAfter-datum och är beroende av CRL- eller OCSP-infrastruktur för att kommunicera den statusen. Organisationer som hanterar förnyelsekalendrar noggrant men inte har någon sammanhängande återkallningspolicy har bara åtgärdat hälften av problemet med certifikatlivscykeln.

Varför är certifikatutgång och återkallelse viktiga för PKI-team på stora företag?

Den 3 februari 2020 gick Microsoft Teams offline i nästan tre timmar efter att ett autentiseringscertifikat hade löpt ut utan förnyelse. Den 19 augusti 2020 stördes Spotify-användare i ungefär en timme när ett TLS-wildcard-certifikat löpte ut. DigiCert Trust Pulse Survey (juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp under föregående år. Dessa incidenter är det förutsägbara resultatet av att behandla utgångsdatum som den enda förtroendegränsen och ignorera återkallelse som en kompletterande kontroll.

Vilka risker ökar om certifikatutgång och återkallelse hanteras manuellt?

Manuell hantering introducerar fyra riskkategorier: missade förnyelser (manuella förnyelsekalendrar missar certifikat i otäckta miljöer); förseningar av återkallelser (en viktig kompromiss som kräver åtgärder inom 24 timmar enligt CA/Browser Forum Baseline Requirements kan inte tillförlitligt utföras manuellt i stor skala); osynliga återkallelser (ett certifikat som återkallats hos CA men vars CRL-distributionspunkt inte kan nås från det relevanta nätverkssegmentet når aldrig de system som behöver agera på det); och föräldralösa autentiseringsuppgifter (en anställds avgång eller systemavstängning som inte följs av återkallelse lämnar ett giltigt certifikat i omlopp på obestämd tid).

Vilka team bör äga styrningen av certifikatutgångs- och återkallelse?

PKI-administratörer äger den tekniska verksamheten: identifiering, övervakning av utgångsdatum, körning av återkallelser, publicering av CRL och underhåll av OCSP-svarare. Säkerhetsarkitekter äger policyutformningen: vilka händelser som utlöser återkallelse, vilket återkallelsetillstånd som gäller och den maximala svarstiden. Compliance-team äger revisionsbevis för att återkallningspolicyn följs och att CRL- och OCSP-infrastrukturen testas regelbundet. CISO:er äger styrningsbeslutet att certifikatlivscykelhantering är ett finansierat, kontinuerligt program.

Hur kopplas hantering av certifikats utgångs- och återkallelse till hantering av certifikatslivscykel?

CLM-plattformar är det operativa lagret som gör båda mekanismerna tillförlitliga i stor skala. En CLM-plattform upptäcker alla certifikat i alla miljöer, spårar utgångstider med automatiserade förnyelseaviseringar och arbetsflöden och tillhandahåller en mekanism för att utlösa återkallelse över flera CA:er från ett enda gränssnitt. CertSecure Manager upprätthåller ett live-certifikatlager över publika CA:er, privata CA-hierarkier, HashiCorp Vault och Microsoft PKI-miljöer, med automatiserad livscykelhantering och realtidsvarningar för både utgångs- och återkallelsehändelser.

Hur bör organisationer mäta framgång i hanteringen av certifikatutgångar och återkallelser?

Nyckeltal: andelen oplanerade certifikat som förfaller (mål: noll per kvartal, för hela certifikattillgången); svarstid för återkallelser av viktiga komprometteringshändelser (mål: slutfört inom 24 timmar för offentligt betrodda TLS-certifikat enligt CA/Browser Forum Baseline Requirements); CRL- och OCSP-nåbarhet (mål: 100 procent av distributionspunkterna är nåbara från alla nätverkssegment där certifikat valideras och verifieras kvartalsvis); och fullständighet i certifikatinventeringen (mål: alla certifikat från offentliga och privata CA-källor representerade i CLM-plattformen).

Vad bör granskas eller övervakas regelbundet för att säkerställa att certifikat löper ut eller återkallas?

Övervaka kontinuerligt: ​​tidslinjer för certifikatutgång i alla miljöer med automatiska förnyelseaviseringar; tillgänglighet för CRL-distributionspunkter och OCSP-svarare för alla aktiva CA-hierarkier; och CA-händelseloggar för återkallningshändelser. Granska kvartalsvis: testa CRL-hämtning och OCSP-svar från representativa nätverkssegment; granska återkallningspolicyn mot den aktuella händelsetaxonomin och bekräfta att varje händelsetyp har en definierad ägare och svarstidslinje; och bekräfta att certificateHold-poster aktivt granskas och antingen återställs eller eskaleras till permanent återkallelse.

Hur skiljer sig hanteringen av certifikatutgång och återkallelse i moln-, hybrid- eller multi-CA-miljöer?

I moln- och hybridmiljöer utfärdas certifikat från flera CA-källor med separata CRL-distributionspunkter och OCSP-svarare, som var och en måste vara nåbar från de nätverkssegment där de utfärdade certifikaten valideras. En CRL som är åtkomlig från lokala miljöer men blockerad av en molnnätverkssäkerhetsgrupp producerar tysta återkallningsfel i molnlagret. CBOM Secure tillhandahåller kryptografisk identifiering på CBOM-nivå som omfattar alla CA-källor, vilket möjliggör enhetlig hantering av utgångs- och återkallelser i hybridmiljöer.

Vilka vanliga misstag bör team undvika vid utgång och återkallelse av certifikat?

De vanligaste misstagen: att använda certificateHold istället för permanent återkallelse för viktiga komprometteringshändelser eftersom återkallelsen känns drastisk (detta lämnar ett komprometterat certifikat i ett återställbart tillstånd); att distribuera CRL-distributionspunkter och OCSP-svarare utan att testa nåbarheten från alla nätverkssegment där certifikat valideras; att behandla certifikatutgången som den enda förtroendegränsen utan en återkallningspolicy för händelser mitt i livscykeln; och att anta att den 47 dagar långa publika TLS-livslängden under CA/Browser Forum SC-081v3 eliminerar behovet av återkallelse i privata PKI-, kodsignerings- eller IoT-enhetscertifikat, som behåller fleråriga giltighetsperioder.

Vad bör uppdateras kvartalsvis för styrning av certifikatutgång och återkallelse?

Kvartalsvis: testa CRL-distributionspunktens och OCSP-svararens nåbarhet från alla nätverkssegment och dokumentera resultaten; granska certificateHold-poster som är äldre än 30 dagar och eskalera till permanent återkallelse eller dokumentera formellt motiveringen; granska certifikatinventeringen för alla certifikat som utfärdats utanför den hanterade livscykeln och som inte omfattas av utgångsövervakning eller återkallelsespolicy; och granska taxonomin för orsakskoder för återkallelse mot organisatoriska förändringar under föregående kvartal. För planering efter kvantum, kontrollera vägledningen för algoritmövergång via PQC Center of Excellence.