Online Certificate Status Protocol (OCSP) kontra certifikatåterkallningslistor (CRL:er)

Beskrivning

Varje offentligt betrott TLS-certifikat har ett löfte: om det någonsin komprometteras, förloras eller utfärdas felaktigt kan det återkallas före det planerade utgångsdatumet. Online Certificate Status Protocol (OCSP) och Certificate Revocation Lists (CRL) är de två mekanismer som gör det löftet verkställbart, och valet mellan dem har förändrats avsevärt under de senaste två åren. Den här guiden förklarar hur varje metod faktiskt fungerar, varför branschens egen rekommendation har ändrats sedan denna jämförelse först skrevs och hur man bestämmer vilken metod som passar en given miljö.

Kort sagt: OCSP vs. CRL

OCSP och CRL:er används båda för att kontrollera om ett certifikat har återkallats innan det löper ut. OCSP frågar en certifikatutfärdares svarare i realtid om statusen för ett specifikt certifikat, om det returnerar giltigt, återkallat eller okänt. En CRL är en signerad, nedladdningsbar lista över alla certifikat som en certifikatutfärdare har återkallat, som en klient kontrollerar lokalt utan att kontakta certifikatutfärdaren direkt för varje sökning.

Ögonblicksbild: Vad som har förändrats sedan denna jämförelse först skrevs

• OCSP kontrollerar statusen för ett enskilt certifikat i realtid; en CRL är en fullständig lista som en klient laddar ner och kontrollerar lokalt.
• Let's Encrypt, certifikatutfärdaren bakom ungefär hälften av webbens TLS-certifikat, stängde ner sina OCSP-svarare helt den 6 augusti 2025 och övergick helt till CRL:er.
• Den huvudsakliga drivkraften var inte prestanda utan integritet: varje OCSP-förfrågan berättar i realtid för certifikatutfärdaren vilken IP-adress som besöker vilket certifikats webbplats.
• Kortare certifikatlivslängder enligt CA/Browser Forums nya giltighetsschema minskar, men eliminerar inte, det fönster där återkallningskontroll är viktig.
• Rätt val beror fortfarande på vem som kontrollerar båda ändar av anslutningen: en offentlig certifikatutfärdare som hanterar godtyckliga webbläsare har andra begränsningar än en intern Active Directory Certificate Services (AD CS)-distribution som hanterar kända klienter.

Varför denna jämförelse läses annorlunda år 2026

Den tydligaste signalen att detta ämne har förändrats kom från Let's Encrypt själva. I ett tillkännagivande i december 2024 lade den ideella CA fram en gradvis nedläggning av OCSP: nya OCSP Must-Staple-förfrågningar slutade att hanteras den 30 januari 2025, OCSP-URL:er togs bort från nyligen utfärdade certifikat senast den 7 maj 2025 och dess OCSP-svarare stängdes ner helt den 6 augusti 2025. Let's Encrypts uttalade resonemang var rakt på sak om integritetskostnaden för OCSP: en CA som svarar på OCSP-frågor lär sig i realtid vilka IP-adresser som besöker vilka av dess certifikatinnehavares webbplatser, information som den kan vara tvungen att behålla eller avslöja. CRL:er, däremot, laddas ner i bulk och kontrolleras lokalt, så CA ser aldrig en fråga per besök.

DigiCerts Trust Pulse-undersökning, publicerad den 2 juli 2025, visade att nästan hälften av företagen upplevde ett certifikatrelaterat avbrott under det senaste året, där 37.5 % av dessa incidenter var specifikt kopplade till utgångna certifikat och 18.5 % av de drabbade organisationerna rapporterade förluster som översteg 250 000 dollar. En långsam eller opålitlig återkallningskontroll, oavsett om det är genom en överbelastad OCSP-responder eller en inaktuell CRL-cache, förvärrar just denna typ av avbrottsrisk snarare än att bara påverka säkerhetsställningen.

Certifikatlivslängden krymper samtidigt som återkallningspraxis förändras. Enligt CA/Browser Forum Ballot SC-081v3 , godkänd 11 april 2025, sjunker giltighetstiden för offentligt betrodda TLS-certifikat från 398 dagar till 200 dagar från och med den 15 mars 2026, sedan till 100 dagar från och med den 15 mars 2027 och till 47 dagar från och med den 15 mars 2029. Ett certifikat som är giltigt i 47 dagar har helt enkelt ett mindre fönster där återkallelse alls spelar roll, vilket är en del av anledningen till att vissa CA:er nu behandlar CRL:er som tillräckliga i sig själva snarare än att lägga OCSP ovanpå.

På längre sikt slutförde NIST sina postkvantumkryptografistandarder, FIPS 203, 204 och 205, den 13 augusti 2024. Varken OCSP-svar eller CRL:er signeras vanligtvis med postkvantumalgoritmer idag, men i takt med att CA:er planerar kryptoagil signeringsinfrastruktur är återkallningsdata ytterligare en artefakt som så småningom kommer att behöva en migreringsväg vid sidan av de certifikat den beskriver.

Vad är OCSP?

Online Certificate Status Protocol (OCSP) är ett internetprotokoll som låter en klient fråga en certifikatutfärdares svarare om ett specifikt certifikat fortfarande är giltigt, utan att ladda ner en fullständig lista över alla certifikat som certifikatutfärdaren har återkallat.

Hur en OCSP-förfrågan och ett svar fungerar

En OCSP-klient skickar en statusförfrågan till en OCSP-responder och väntar på ett signerat svar innan den fortsätter. Begäran inkluderar protokollversionen, typen av tjänst som begärs, en identifierare för målcertifikatet och eventuella valfria tillägg. Respondern kontrollerar att meddelandet är korrekt utformat, att det är konfigurerat för att svara för den aktuella certifikatutfärdaren och att begäran innehåller den information den behöver, och returnerar sedan antingen ett definitivt svar eller ett fel.

Ett grundläggande OCSP-svar inkluderar versionen av svarssyntaxen, en identifierare för svararen, tidpunkten då svaret genererades, en status för varje begärt certifikat, valfria tillägg, signaturalgoritmens objektidentifierare (OID) och en signatur som beräknas över en hash av svaret så att klienten kan verifiera att det kom från CA:n oförändrat. Tre statusvärden är möjliga: bra, vilket betyder att certifikatet inte har återkallats såvitt svararen vet; återkallat, vilket betyder att certifikatet uttryckligen har återkallats eller att CA:n inte har någon registrering av att någonsin ha utfärdat det; och okänt, vilket betyder att svararen inte känner igen utfärdaren av det certifikatet.

OCSP häftning

OCSP-häftning åtgärdar OCSP:s största svaghet direkt: istället för att klienten kontaktar CA:n hämtar webbservern själv regelbundet ett signerat, tidsstämplat OCSP-svar och häftar det till TLS-handskakningen, så besökande webbläsare får återkallningsstatusen utan att någonsin kontakta CA:n. Detta eliminerar den extra tur- och returresan och sekretessrisken för en CA-fråga per besökare, eftersom CA:n bara ser webbserverns periodiska uppdateringsförfrågningar snarare än varje enskild besökare. Häftning är dock inte universellt implementerat och eliminerar inte OCSP:s andra driftskostnader; en CA måste fortfarande köra en responderinfrastruktur som kan hantera uppdateringstrafik i stor skala.

Vad är en certifikatåterkallningslista (CRL)?

En certifikatåterkallningslista (CRL) är en signerad lista, publicerad av den utfärdande certifikatutfärdaren, över alla certifikat som har återkallats före sitt schemalagda utgångsdatum och inte längre bör vara betrodda. Klienter hämtar CRL:n från en CRL-distributionspunkt, ett X.509v3-certifikattillägg som pekar på en HTTP- eller LDAP-plats, och kontrollerar lokalt om certifikatet de validerar visas på den.

Återkallade kontra kvarhållande tillstånd

En CRL-post kan återspegla ett av två tillstånd. Ett återkallat certifikat tas bort oåterkalleligt, vanligtvis på grund av en nyckelkomprometterad, en CA-komprometterad, en anknytningsändring eller annan orsak som definieras i X.509-orsakskoderna för återkallelse; det kan inte återställas. Ett certifikat som har satts i spärr pausas tillfälligt snarare än återkallas permanent. Om till exempel en privat nyckel som tros vara förlorad dyker upp i säkerhet, kan certifikatet tas ur spärren och bli giltigt igen, vilket är en betydande operativ skillnad från en oåterkallelig återkallelse.

Hur CRL-distribution fungerar i praktiken

En CRL fungerar ungefär som en svartlista. En klient hämtar den aktuella CRL:en från certifikatutfärdarens publicerade distributionspunkt och kontrollerar att certifikatet i fråga inte finns med i den. Eftersom hela listan måste laddas ner och analyseras kan en stor CRL vara betydligt mer belasta klient- och nätverksresurser än en enda OCSP-fråga, och att publicera en ny CRL efter en ny återkallelse är vanligtvis långsammare än vad en OCSP-responder kan svara på i realtid. De flesta TLS-stackar är också konfigurerade för att öppnas vid fel: om en klient inte kan ladda ner CRL:en alls, litar den som standard på certifikatet snarare än att blockera anslutningen, vilket är en känd avvägning snarare än en defekt.

OCSP vs. CRL: Direkt mot direkt

Faktor	OCSP	CRL
Vad den kontrollerar	Status för ett specifikt certifikat per begäran	Fullständig lista över alla certifikat som CA har återkallat
Var kontrollen sker	Klienten frågar CA:ns OCSP-responder direkt, om den inte är häftad	Klienten laddar ner listan en gång och kontrollerar lokalt
Integritetsexponering	CA ser varje klients IP-adress och vilket certifikat den kontrollerar, såvida det inte är häftat	CA ser inte enskilda frågor per besök
Nätverks- och klientbelastning	Lågt per förfrågan, men svararna måste hantera hög frågevolym	Kan vara tung att ladda ner för stora listor över återkallade certifikat
Felbeteende	Avbrott i svarssystemet kan blockera eller i tysthet hoppa över validering beroende på klientkonfiguration	Saknad CRL misslyckas vanligtvis med att öppnas och certifikatet litas som standard på
Branschriktning 2026	Utfasas av stora CA:er inklusive Let's Encrypt från och med den 6 augusti 2025	Alltmer positionerad som den primära eller enda återkallningsmekanismen, ibland i kombination med kortlivade certifikat

Beslutsmatris: Att välja en strategi för återkallelsekontroll

Användningsfall	Säkerhetspåverkan	Operativ insats	Automatiseringsanpassning	Rekommenderad ägare
Offentliga TLS-certifikat från en offentlig certifikatutfärdare	Medellånga, kortare giltighetsperioder minskar exponeringsfönstret	Låg, de flesta offentliga certifikatutfärdare hanterar nu detta centralt	Hög, till stor del CA-hanterad	Plattformsteam
Intern AD CS eller privat PKI som betjänar kända klienter	Hög, ett komprometterat internt certifikat kan påverka autentiseringen i stor utsträckning	Medel, kräver att en Online Responder-roll körs och skalas	Medel, behöver konfiguration men är stabil när den är inställd	PKI-administratörer
Enhetsflottor utan webbläsare eller IoT	Medel till hög, beror på hur enheter autentiseras	Medium, CRL-distribution i stor skala behöver planering	Medelstor, schemalagd CRL-hämtning är generellt enklare än OCSP för begränsade enheter	Plattformsteam
Högsäkerhetsmiljöer som kräver nästan omedelbara återkallningskontroller	Hög fördröjning i spridningen av återkallelse är i sig en risk	Hög, behöver OCSP-häftning plus en CRL-alternativsökväg	Medium, kräver att båda mekanismerna är korrekt konfigurerade	Säkerhetsarkitekter
Äldre eller begränsade klienter utan stöd för OCSP-häftning	Medium	Låg, CRL-kontroll stöds i stort utan särskild konfiguration	Hög, CRL:er fungerar som en universell reservlösning	Regelefterlevnad, plattformsteam

Att välja mellan OCSP och CRL

Det finns inget enskilt, universellt korrekt svar, men beslutet handlar vanligtvis om vem som kontrollerar båda ändar av anslutningen, hur känslig återkallelsetidpunkten är och vad klientpopulationen faktiskt kan stödja.

En snabb beslutsguide

1. Om både varje klient och CA stöder OCSP-häftning, använd häftning som primär mekanism, med en CRL som dokumenterad reservfunktion för klienter som inte stöder det.
2. Om det är en prioritet att minimera vad certifikatutfärdaren kan observera om besökarnas beteende, föredra CRL:er eller para ihop kortlivade certifikat med CRL:er så att exponeringsfönstret förblir litet även utan realtidskontroll.
3. Om klientpopulationen inkluderar programvara som inte är webbläsare, IoT-enheter eller nätverksapparater som inte kan implementera häftning, är CRL:er vanligtvis den enklare och mer universellt stödda vägen.
4. Om miljön är en intern AD CS-distribution eller privat PKI där organisationen kontrollerar både CA och varje klient, förblir OCSP med en korrekt skalad Online Responder-roll ett praktiskt alternativ, eftersom integritetsproblemet som drev Let's Encrypts beslut huvudsakligen gäller offentliga CA:er som betjänar okända klienter.

För- och nackdelar i korthet

• OCSP-fördelar: kontrollerar endast certifikatet i fråga snarare än en hel lista och returnerar ett svar i realtid när svararen är felfri.
• OCSP-nackdelar: exponerar besökares IP-adresser och webbplatsbesök för CA om de inte är häftade, och avbrott i svarstjänster har historiskt sett hanterats inkonsekvent mellan klienter.
• CRL-fördelar: ingen fråga per besök till CA, fungerar som en pålitlig reserv överallt och är nu den primära eller enda mekanismen hos CA:er av Let's Encrypts storlek.
• CRL-nackdelar: en fullständig lista över nedladdningar kan vara omfattande för en CA med många återkallelser, och publiceringsförseningar innebär att en mycket nyligen återkallelse kanske inte visas omedelbart.

Vem borde bry sig om detta

Övergången från OCSP hos stora offentliga CA:er förändrar konkreta operativa beslut för flera roller.

PKI-administratörer

Konfigurera och underhåll distributionspunkterna för onlinesvarare eller CRL-certifikat som din certifikatutfärdare faktiskt är beroende av. Åtgärd: bekräfta vilka av dina certifikat som fortfarande refererar till OCSP-URL:er från en certifikatutfärdare som sedan dess har föråldrat tjänsten och verifiera att CRL-distributionspunkterna är nåbara och aktuella.

Säkerhetsarkitekter

Bestäm återkallningskontrollens ställning för högsäkerhetssystem. Åtgärd: dokumentera en reservväg för alla system som fortfarande antar OCSP-tillgänglighet, eftersom svarare hos vissa publika certifikatutfärdare inte längre finns.

Plattformsteam

Egen klientkonfiguration över servrar, lastbalanserare och enhetsflottor. Åtgärd: verifiera att TLS-termineringspunkter som förväntar sig OCSP-häftningssvar har en CRL-reserv konfigurerad snarare än att misslyckas tyst.

Compliance-team

Bekräfta att bevisen för återkallningskontroll fortfarande överensstämmer med hur certifikat faktiskt valideras i produktion. Åtgärd: uppdatera revisionsdokumentationen som fortfarande anger OCSP som standardmekanism om relevant certifikatutfärdare har gått över till CRL:er.

CISO: er

Väg avvägningarna mellan integritet och tillförlitlighet vid återkallningskontroll som en del av den bredare strategin för certifikatlivscykeln. Åtgärd: fråga om kortare certifikatlivslängder enligt CA/Browser Forums schema förändrar hur mycket organisationen behöver investera i realtidsinfrastruktur för återkallelse kontra CRL-baserad kontroll.

Vår syn: Hur krypteringskonsulttjänster stöder återkallelse av certifikat och livscykelhantering

Oavsett om en miljö förlitar sig på OCSP, CRL:er eller en blandning av båda, är det underliggande kravet detsamma: veta vilka certifikat som finns, hur de valideras och om valideringsvägen fortfarande matchar hur den utfärdande certifikatutfärdaren faktiskt fungerar idag.

Vår CertSecure Manager- plattform ger team fullständig inventering av maskinidentiteter och certifikatidentifiering i en miljö, så en förändring av CA-nivå, som Let's Encrypts OCSP-nedgång, uppstår inte som ett överraskande avbrott. För team som överväger om de ska fortsätta hantera återkallningsinfrastrukturen internt, kör vår PKI-as-a-Service- plattform CA-hierarkin, inklusive publicering av återkallelser, på FIPS 140-3 Level 3 HSM-baserade nycklar medan din organisation behåller äganderätt och kontroll. För en djupare titt på relaterade återkallningsmekanismer, se våra guider om OCSP Magic Number , ett Windows-specifikt tröskelvärde som tyst växlar från OCSP till CRL-kontroll, och CRL-orsakskoder , som täcker vad varje återkallningskod faktiskt betyder i praktiken. På kryptoagilitetssidan hjälper vårt PQC Center of Excellence och PQC Readiness Assessment team att planera för en framtid där återkallningsdata i sig behöver post-quantum-safe-signering, och vår CBOM Secure kryptografiska identifierings- och inventeringsplattform ger säkerhetsarkitekter insikt i exakt vilka certifikat i en miljö som fortfarande är beroende av en föråldrad OCSP-responder.

Slutsats

OCSP och CRL:er löser samma problem, att bekräfta att ett certifikat inte har återkallats, genom olika avvägningar mellan realtidsnoggrannhet, integritet och enkelhet i drift. Det som verkligen har förändrats sedan denna jämförelse först var användbar är att branschens standardsvar blev omvänt: Let's Encrypts fullständiga OCSP-nedstängning den 6 augusti 2025 visar att CRL:er, som en gång behandlades som det äldre och tyngre alternativet, nu är den primära mekanismen på CA-nivå som utfärdar fler certifikat än någon annan. Team som fortfarande antar att OCSP är universellt tillgängligt, eller som inte har kontrollerat om deras CA har följt Let's Encrypts exempel, bör behandla det som en försenad konfigurationsgranskning snarare än ett fastställt antagande.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Online Certificate Status Protocol (OCSP) jämfört med certifikatåterkallningslistor (CRL:er)?

OCSP kontrollerar statusen för ett enskilt certifikat i realtid men exponerar besökaraktivitet för CA om den inte är häftad, medan CRL:er är en nedladdningsbar lista som kontrolleras lokalt. Stora CA:er, inklusive Let's Encrypt från och med den 6 augusti 2025, har övergått från OCSP till CRL:er som den primära mekanismen.

Varför är detta viktigt för PKI-team på stora företag?

Konfigurationer och granskningsdokumentation som skrevs när OCSP var standardantagandet kanske inte längre matchar hur en given certifikatutfärdare faktiskt validerar certifikat idag, vilket kan skapa tysta luckor i återkallningskontrollen.

Vilka risker ökar om återkallelsekontrollen hanteras manuellt eller lämnas ogranskad?

System kan i tysthet lita på certifikat som borde ha avvisats, antingen för att en OCSP-responder som de är beroende av har stängts av eller för att en inaktuell CRL-cache aldrig uppdateras, och ingen märker det förrän en incident inträffar.

Vilka lag borde ta ansvar för det här beslutet?

PKI-administratörer äger konfigurationen av svarare och distributionspunkt, säkerhetsarkitekter anger kontrollpositionen för återkallelser för känsliga system, plattformsteam äger klientkonfigurationen, efterlevnad verifierar att dokumentationen överensstämmer med verkligheten och CISO:n väger den övergripande avvägningen mellan integritet och tillförlitlighet.

Hur kopplas detta till hantering av certifikatlivscykeln?

Återkallningskontroll är ett steg i certifikatlivscykeln vid sidan av utfärdande, förnyelse och utgång. Verktyg för hantering av certifikatlivscykeln som ger fullständig identifiering och inventering gör det möjligt att veta vilka certifikat som är beroende av vilken återkallningsmekanism innan en certifikatutfärdare ändrar sin infrastruktur.

Hur bör organisationer mäta om deras strategi för att kontrollera återkallelser fungerar?

Spåra om några certifikat fortfarande refererar till OCSP-URL:er från en certifikatutfärdare som har föråldrat tjänsten, bekräfta att CRL-distributionspunkterna är aktuella och att de är aktuella, och övervaka avbrott kopplade till misslyckade eller långsamma återkallningskontroller snarare än att bara spåra certifikatets utgångsdatum.

Vad bör granskas eller övervakas regelbundet?

Bekräfta regelbundet vilken återkallningsmekanism varje utfärdande certifikatutfärdare faktiskt stöder, verifiera att OCSP-häftning fungerar där den är konfigurerad, kontrollera att CRL-hämtningsintervallen är lämpliga för certifikatpopulationen och ompröva antaganden varje gång en certifikatutfärdare publicerar en infrastrukturändring.

Hur påverkar det här ämnet moln-, hybrid- eller multi-CA PKI-miljöer?

En miljö som blandar en offentlig CA som Let's Encrypt med en intern AD CS-hierarki eller en molnbaserad CA kan behöva olika återkallningsstrategier för varje, eftersom en offentlig CA:s flytt till CRL:er inte kräver eller innebär samma ändring för en intern PKI som betjänar en känd klientpopulation.

Vilka vanliga misstag bör team undvika?

Vanliga misstag inkluderar att anta att OCSP är universellt tillgängligt utan att kontrollera om den utfärdande CA fortfarande kör en responder, att behandla en saknad CRL:s felöppningsbeteende som en bugg snarare än en känd designkompromiss, och att aldrig återgå till återkallningskonfigurationen efter den första distributionen.

Vad bör uppdateras kvartalsvis för en strategi för att kontrollera återkallelser?

Granska om någon utfärdande CA har meddelat ändringar i sin OCSP- eller CRL-infrastruktur, bekräfta att certifikatinventarier är uppdaterade, gå igenom CA/Browser Forums publicerade giltighetsschema för ändringar och kontrollera om kortare certifikatlivslängder har minskat det praktiska behovet av återkallningskontroll i realtid i en given miljö.