Introduktion till OCSP-häftning

Beskrivning

SSL/TLS-certifikat fungerar som digitala ID:n som låter en webbläsare bekräfta en webbplats identitet innan någon data utbyts. En del av detta förtroende beror på återkallelse: en mekanism som talar om för en webbläsare när ett certifikat inte längre är säkert att använda, oavsett om det beror på att en server har komprometterats, en nyckel har exponerats av misstag eller att en certifikatutfärdare (CA) helt enkelt har utfärdat certifikatet av misstag. OCSP Stapling byggdes för att leverera den återkallningsstatusen snabbt och privat, men CA-landskapet som stöder det har förändrats avsevärt sedan denna mekanism blev bästa praxis, och den här guiden täcker exakt vad som har förändrats.

50-ordsversionen

OCSP-häftning låter en webbserver hämta ett signerat certifikatstatussvar från sin certifikatutfärdare i förväg och bifoga det direkt till TLS-handskakningen, så att en besökande webbläsare får återkallningsstatus utan att kontakta certifikatutfärdaren själv. Det förbättrar hastighet och integritet jämfört med standard OCSP, men fungerar bara om den utfärdande certifikatutfärdaren fortfarande använder en OCSP-responder.

Kortfattat

• OCSP-häftning eliminerar behovet av att en webbläsare kontaktar CA direkt, vilket förbättrar både anslutningshastigheten och besökarnas integritet jämfört med standard OCSP.
• Let's Encrypt, CA:n bakom ungefär hälften av webbens TLS-certifikat, inaktiverade utfärdandet av OCSP Must-Staple-certifikat den 30 januari 2025 och stängde ner sina OCSP-svarare helt den 6 augusti 2025.
• Det betyder att OCSP Stapling inte har något att häfta för något aktuellt Let's Encrypt-certifikat; servrar som förlitar sig på det för dessa certifikat måste istället flytta till certifikatåterkallningslistor (CRL:er).
• Google Chrome, den mest använda webbläsaren, har aldrig tillämpat OCSP Must-Staple-beteendet för hårda fel, utan förlitat sig istället på sin egen CRLSet-mekanism, vilket begränsar hur mycket skydd Must-Staple faktiskt lägger till även där en CA fortfarande stöder det.
• Huruvida OCSP-häftning fortfarande är meningsfullt för ett givet certifikat beror nu helt på om dess utfärdande CA fortfarande kör en OCSP-responder, vilket måste verifieras per CA snarare än antas.

Varför detta behöver en uppdatering

I december 2024 meddelade Let's Encrypt att de skulle fasa ut OCSP helt under 2025, och de följde detta inom en strikt tidsram. Den 30 januari 2025 inaktiverade de utfärdandet av nya certifikat med OCSP Must-Staple-tillägget. Senast den 7 maj 2025 tog de bort OCSP-URL:er helt och hållet från nyutfärdade certifikat. Den 6 augusti 2025 stängde de ner sina OCSP-svarare helt och övergick helt till certifikatåterkallningslistor. För alla servrar som presenterar ett Let's Encrypt-certifikat som utfärdats efter den tidpunkten är OCSP-häftning inte ett långsammare eller mindre privat alternativ, det är helt enkelt inte tillgängligt, eftersom det inte finns någon svarare kvar att häfta ett svar från.

DigiCerts Trust Pulse Survey, 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 incidenterna var kopplade till utgångna certifikat och 18.5 % av de drabbade organisationerna rapporterade förluster som översteg 250 000 dollar. En server som fortfarande är konfigurerad för att hämta och häfta OCSP-svar för en certifikatutfärdare som inte längre tillhandahåller dem är en tyst och lättförståelig bidragsgivare till just denna typ av avbrottsrisk, eftersom en felkonfigurerad eller trasig häftning kan försämra eller bryta anslutningar beroende på klientinställningar.

Certifikatens livslängd krymper samtidigt. Enligt CA/Browser Forum Ballot SC-081v3 , godkänd den 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. Certifikat med kortare livslängd minskar det totala fönstret där eventuella återkallningsmekanismer, oavsett om de är grundläggande eller andra, faktiskt spelar roll, vilket är en del av det bredare branschresonemanget bakom att helt och hållet gå ifrån OCSP.

Vad är OCSP-häftning?

Online Certificate Status Protocol (OCSP) Stapling är en internetstandard som används för att verifiera återkallningsstatusen för ett X.509-certifikat utan att den besökande klienten behöver kontakta certifikatutfärdaren direkt. Istället begär webbservern själv regelbundet ett signerat statussvar från certifikatutfärdarens OCSP-responder och bifogar, eller häftar, det svaret till certifikatet under TLS-handskakningen. Om webbläsaren får en återkallningsstatus varnar den användaren och kan blockera anslutningen innan någon konfidentiell information utbyts.

Valideringsflödet för OCSP-häftning

Tabellen nedan går igenom varje steg i processen tillsammans med vad som händer när något går fel.

Steg	Vad händer	Feltillstånd	Övervakningssignal
1. Utfärdande av certifikat	CA utfärdar ett certifikat som innehåller en OCSP-svars-URL, vilket signalerar att OCSP stöds för detta certifikat.	Certifikatet utfärdas utan OCSP-URL, vilket Let's Encrypt nu gör för alla nya certifikat.	Certifikatinspektion visar inget OCSP-fält för åtkomst till auktoritetsinformation
2. Tillgänglighet för OCSP-svarare	CA:s OCSP-responder svarar på statusfrågor och publicerar regelbundet uppdaterad status	CA har helt avbrutit sin OCSP-responder, precis som Let's Encrypt gjorde den 6 augusti 2025.	Direktfråga till svars-URL:en får tidsgräns eller returnerar ett felmeddelande
3. Servern hämtar och cachar ett svar	Webbservern begär ett signerat OCSP-svar och cachar det för återanvändning över klientanslutningar.	Servern kan inte nå svararen och har inget cachat svar till häftning	Serverloggar visar upprepade OCSP-hämtningsfel
4. TLS-handskakning och häftning	Servern bifogar det cachade OCSP-svaret till certifikatet under handskakningen.	Servern presenterar ett certifikat utan häftklammer, vilket tvingar klienter tillbaka till standard OCSP eller ingen återkallningskontroll alls.	SSL Labs eller motsvarande skanning rapporterar OCSP-häftning som "Nej" eller "Stöds inte"
5. Kundverifiering	Webbläsaren kontrollerar det häftade svarets signatur och status (bra, återkallat eller okänt)	En inaktuell eller utgången häftklammer leder till att vissa klienter återgår till en direkt OCSP-fråga eller accepterar anslutningen ändå.	Klientsides TLS-felloggar eller webbläsarutvecklingsverktyg flaggar häftningsproblem

Typer av certifikatsvar

Svar	Betydelse	Webbläsarens beteende
bra	OCSP-svararen känner igen certifikatets serienummer och bekräftar att det inte har återkallats.	Anslutningen fortskrider normalt
återkallats	Certifikatet har uttryckligen återkallats av den utfärdande certifikatutfärdaren	Hårdstopp; webbläsaren blockerar anslutningen och varnar användaren
Okänd	Svararen känner inte igen certifikatet, ofta för att det behöver kontrolleras mot en annan certifikatutfärdare än den det är konfigurerat för.	Mjukt stopp; beteendet varierar beroende på webbläsare och kan tillåta att anslutningen fortsätter

Fördelar och nackdelar med OCSP-häftning

Fördelar

• Förbättrad prestanda. Servern cachar och återanvänder OCSP-svaret, vilket undviker den extra tur och retur som en klient annars skulle göra till CA:n för varje anslutning.
• Förbättrad integritet. Eftersom CA svarar på serverns periodiska uppdateringsförfrågan snarare än en fråga för varje enskild besökare, kan den inte se vilka specifika användare som besöker vilka webbplatser.
• Resurseffektivitet. Häftning förbrukar färre nätverksresurser än antingen vanliga OCSP-frågor per besökare eller att ladda ner en fullständig lista över återkallade certifikat.

Nackdelar

• Totalt beroende av den utfärdande CA:ns OCSP-responder. Om den där svararen tas bort, som Let's Encrypt gör nu, har häftning helt enkelt ingenting att hämta, oavsett hur väl servern är konfigurerad.
• Begränsad kedjetäckning. Grundläggande OCSP-häftning verifierar vanligtvis inte mellanliggande certifikat i kedjan, även om multihäftning och TLS 1.3-stöd åtgärdar detta på servrar som implementerar dem.
• Uppdateringsfördröjning. Det finns ett realtidsgap mellan uppdateringscyklerna, så ett certifikat som återkallats strax efter den senaste uppdateringen kan fortfarande visa en inaktuell status som "bra" fram till nästa hämtning.

Varför Must-Staple bleknar för mycket

OCSP Must-Staple-tillägget utformades för att täppa till ett specifikt gap: utan det kan en server helt enkelt utelämna häftklammern och en webbläsare har inget sätt att veta att en borde ha funnits. Must-Staple utlöser en hård fel-häftning av anslutningen om ingen giltig häftklammer är ansluten, vilket i teorin tvingar servrar att fortsätta häfta korrekt. I praktiken har dess användbarhet alltid begränsats av ojämnt webbläsarstöd, och den håller nu på att försvinna från ekosystemet helt av en mer direkt anledning. Google Chrome, webbläsaren med den största andelen webbtrafik, har aldrig inbyggt tillämpat Must-Staples hårda fel-beteende, utan förlitat sig istället på sin egen CRLSet-mekanism för att distribuera återkallningsinformation i stor skala. Dessutom inaktiverade Let's Encrypt utfärdandet av nya Must-Staple-certifikat den 30 januari 2025 som det första steget i sin bredare OCSP-nedstängning. Med begränsad webbläsartillämpning och den största certifikatutfärdaren som inte längre utfärdar det, är Must-Staple inte en kontroll värd att bygga ett nytt förtroende för framöver.

Övervakningschecklista för OCSP-häftningshälsa

1. Bekräfta vilken certifikatutfärdare som utfärdat varje certifikat i din miljö och kontrollera om den certifikatutfärdaren fortfarande använder en OCSP-responder.
2. För certifikat från en certifikatutfärdare som har upphört med OCSP, inaktivera häftkonfigurationen för dessa certifikat och bekräfta att CRL-kontroll är korrekt konfigurerad istället.
3. Kör en återkallningskontroll av alla offentliga värdnamn regelbundet, inte bara vid den första distributionen.
4. Övervaka serverloggar för upprepade OCSP-hämtningsfel, vilket indikerar antingen ett svarsavbrott eller ett certifikat från en certifikatutfärdare som inte längre stöder OCSP.
5. Ta bort all återstående OCSP Must-Staple-konfiguration på certifikat från certifikatutfärdare som har föråldrat tillägget, eftersom en inställning för hård fel utan något att häfta kan bryta anslutningar direkt.
6. Gå igenom den här checklistan igen när en certifikatutfärdare i din miljö tillkännager en infrastrukturförändring, inte bara enligt ett fast kalenderschema.

Så här kontrollerar du om OCSP-häftning är aktiverad

Stöd för OCSP-häftning är idag en funktion av den webbserverprogramvara som används, till exempel en för närvarande stödd version av IIS, Nginx, Apache eller Caddy, snarare än en specifik äldre operativsystemversion. Alla moderna, aktivt underhållna serverplattformar stöder häftning; den praktiska frågan är om den är korrekt konfigurerad och om certifikatets utfärdande certifikatutfärdare fortfarande har en svarare att hämta från.

Steg 1: Gå till SSL Labs av Qualys.

Steg 2: Markera rutan för att undvika att publicera resultaten på den offentliga resultattavlan om domänen ska förbli privat.

Steg 3: Ange domännamnet för att kontrollera och skicka in skanningen.

Steg 4: När skanningen är klar granskar du avsnittet Återkallningsinformation, som listar CRL- och OCSP-information.

Steg 5: Kontrollera raden OCSP-häftning. Ett "Ja" betyder att häftning är aktiv. Ett "Nej" betyder att den är inaktiverad men certifikatet stöder fortfarande OCSP. Resultatet "Stöds inte" kan betyda att den utfärdande certifikatutfärdaren inte längre tillhandahåller OCSP alls, vilket nu är fallet för certifikat från Let's Encrypt, så bekräfta den utfärdande certifikatutfärdaren innan du antar att servern är felkonfigurerad.

Vem borde bry sig om detta

Övergången från OCSP förändrar konkreta konfigurationsbeslut över flera roller.

PKI-administratörer

Underhåll konfigurationen för återkallelse på servernivå. Åtgärd: granska alla certifikat för dess utfärdande certifikatutfärdare och ta bort konfigurationen för OCSP-häftning eller måste-häfta för alla certifikatutfärdare som har upphört med OCSP-stöd.

Säkerhetsarkitekter

Ställ in organisationens standard för kontroll av återkallelser. Åtgärd: definiera en CRL-baserad reservpolicy för alla certifikatutfärdare som inte längre stöder OCSP, snarare än att låta varje serverteam identifiera det separat.

Plattformsteam

Äg den faktiska server- och lastbalanseringskonfigurationen. Åtgärd: kör en återkallningskontroll av alla offentliga värdnamn och åtgärda alla värdar som fortfarande är konfigurerade för OCSP-häftning mot en CA som inte längre stöder det.

Compliance-team

Bekräfta att revisionsdokumentationen återspeglar CA:s nuvarande beteende. Åtgärd: uppdatera eventuella efterlevnadsbevis som fortfarande anger OCSP-häftning som standardmekanism för återkallelse om relevant CA har flyttat till CRL:er.

CISO: er

Väg driftskostnaden för att upprätthålla konfigurationen för återkallning per certifikatutfärdare mot risken för tyst felkonfiguration. Åtgärd: behandla avstängningen av Let's Encrypt OCSP som en uppmaning att bekräfta att återkallningskontrollen är aktuell i hela certifikatinventariet, inte bara i nyligen utfärdade certifikat.

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

OCSP-häftning var en betydande förbättring jämfört med standard-OCSP så länge CA:er fortsatte att köra svarare bakom den. Med den största CA:n på webben nu helt utanför OCSP är den praktiska frågan för de flesta organisationer inte längre hur man konfigurerar häftning korrekt, utan vilka certifikat som fortfarande behöver det överhuvudtaget.

Vår CertSecure Manager- plattform ger team fullständig inventering av maskinidentiteter och certifikatidentifiering, så en infrastrukturförändring på CA-nivå som denna framträder som en känd inventeringsuppdatering snarare än ett överraskande avbrott. För organisationer som överväger om de ska hantera återkallningsinfrastrukturen internt alls, 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 närmare titt på hur OCSP och CRL:er jämförs mer generellt, se vår guide om OCSP vs. CRL , och för en relaterad Windows-specifik egenhet täcker vårt inlägg om OCSP Magic Number en tröskel som tyst växlar klienter från OCSP- till CRL-kontroll. På kryptoagilitetssidan hjälper vårt PQC Center of Excellence och PQC Readiness Assessment team att planera för en framtid där återkallningsinfrastrukturen 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-konfiguration.

Slutsats

OCSP Stapling förbättrade standard OCSP genom att leverera återkallningsstatus snabbare och mer privat, utan att varje besökande klient krävde att fråga CA direkt. Den fördelen var dock alltid villkorad av att den utfärdande CA fortsatte att använda en OCSP-responder, och den största CA:n på webben gör det inte längre. Let's Encrypts etappvisa avstängning, från att inaktivera Must-Staple-utfärdande i januari 2025 till att helt pensionera sina OCSP-responder i augusti 2025, innebär att rätt drag för många organisationer inte längre är att finjustera häftkonfigurationen utan att bekräfta, certifikat för certifikat, om OCSP ens fortfarande är i bruk.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen från denna introduktion till OCSP-häftning?

OCSP-häftning förbättrar hastigheten och sekretessen för kontroll av certifikatåterkallelser, men det fungerar bara om den utfärdande certifikatutfärdaren fortfarande kör en OCSP-responder. Let's Encrypt, den största certifikatutfärdaren på webben, pensionerade sina OCSP-responder helt den 6 augusti 2025, vilket gör häftning otillgänglig för deras nuvarande certifikat.

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

Serverkonfigurationer som bygger på antagandet att OCSP-häftning är universellt tillgänglig kan nu i tysthet vara icke-funktionella för certifikat utfärdade av certifikatutfärdare som har upphört med OCSP, vilket skapar ett oövervakat gap i återkallningskontrollen.

Vilka risker ökar om detta ämne hanteras manuellt?

Att manuellt spåra vilken CA som utfärdat vilket certifikat, och om den CA fortfarande stöder OCSP, skalar inte, och en inaktuell OCSP Must-Staple-konfiguration kan orsaka hårda anslutningsfel när en CA slutar ge svar helt och hållet.

Vilka lag borde ta över den här förändringen?

PKI-administratörer äger konfigurationen för återkallelse på servernivå, säkerhetsarkitekter sätter CRL-reservstandarden, plattformsteamen äger skanning och åtgärd, efterlevnad verifierar dokumentationens noggrannhet och CISO:n väger den övergripande riskavvägningen.

Hur kopplas detta till hantering av certifikatlivscykeln?

Verktyg för hantering av certifikatlivscykeln som spårar vilken certifikatutfärdare som utfärdat varje certifikat gör det möjligt att snabbt identifiera berörda certifikat när en certifikatutfärdare ändrar sin återkallningsinfrastruktur, snarare än att upptäcka luckan genom ett anslutningsfel.

Hur bör organisationer mäta framgång?

Spåra andelen offentligt riktade värdar med korrekt konfigurerad återkallningskontroll för deras faktiska utfärdande certifikatutfärdare och bekräfta att inga värdar fortfarande är konfigurerade för OCSP-häftning eller måste-häfta mot en certifikatutfärdare som inte längre stöder det.

Vad bör granskas eller övervakas regelbundet?

Granska regelbundet vilken certifikatutfärdare som utfärdat varje certifikat, om den certifikatutfärdaren fortfarande använder en OCSP-responder, om häftning fungerar där den är konfigurerad och om CRL-reservfunktion är korrekt konfigurerad för certifikat från certifikatutfärdare som har övergått från OCSP.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

En miljö som använder certifikat från flera certifikatutfärdare kan behöva olika återkallningskonfigurationer för varje certifikatutfärdare, eftersom att en certifikatutfärdare avbryter OCSP inte betyder att alla certifikatutfärdare i en miljö med flera certifikatutfärdare eller hybridcertifikatutfärdare har gjort detsamma.

Vilka vanliga misstag bör team undvika?

Vanliga misstag inkluderar att anta att OCSP-häftning fungerar på samma sätt för alla certifikatutfärdare, att låta OCSP Must-Staple vara aktiverat på certifikat från en certifikatutfärdare som inte längre utfärdar OCSP-svar, och att behandla en servers operativsystemversion snarare än den utfärdande certifikatutfärdarens nuvarande OCSP-stöd som den avgörande faktorn.

Vad bör uppdateras kvartalsvis?

Uppdatera certifikatinventeringen och dess mappning till varje utfärdande CA:s nuvarande OCSP-stödstatus, kör återkallningskontroller mot offentliga värdar och kontrollera om det finns nyligen aviserade ändringar i CA-infrastrukturen minst en gång i kvartalet.