Inleiding tot OCSP-nieten

Introductie

SSL/TLS-certificaten fungeren als digitale identiteiten waarmee een browser de identiteit van een website kan bevestigen voordat er gegevens worden uitgewisseld. Een deel van dat vertrouwen is afhankelijk van intrekking: een mechanisme dat een browser laat weten wanneer een certificaat niet langer veilig is om te gebruiken, bijvoorbeeld omdat een server is gecompromitteerd, een sleutel per ongeluk is blootgesteld of een certificeringsinstantie (CA) het certificaat ten onrechte heeft uitgegeven. OCSP Stapling is ontwikkeld om die intrekkingsstatus snel en privé te leveren, maar het landschap van certificeringsinstanties dat dit ondersteunt, is aanzienlijk veranderd sinds dit mechanisme een best practice is geworden. Deze handleiding beschrijft precies wat er is veranderd.

De versie van 50 woorden

OCSP Stapling stelt een webserver in staat om vooraf een ondertekend certificaatstatusantwoord van de certificeringsinstantie (CA) op te halen en dit direct aan de TLS-handshake toe te voegen. Hierdoor krijgt een bezoekende browser de intrekkingsstatus te zien zonder contact op te nemen met de CA zelf. Dit verbetert de snelheid en privacy ten opzichte van standaard OCSP, maar werkt alleen als de uitgevende CA nog steeds een OCSP-responder beheert.

In een oogopslag

• OCSP Stapling maakt het overbodig dat een browser rechtstreeks contact opneemt met de certificeringsinstantie, waardoor zowel de verbindingssnelheid als de privacy van de bezoeker verbeteren ten opzichte van standaard OCSP.
• Let's Encrypt, de certificeringsinstantie achter ongeveer de helft van de TLS-certificaten op het web, heeft de uitgifte van OCSP Must-Staple-certificaten op 30 januari 2025 stopgezet en zijn OCSP-responders op 6 augustus 2025 volledig buiten werking gesteld.
• Dat betekent dat OCSP Stapling geen nietjes meer kan toevoegen aan bestaande Let's Encrypt-certificaten; servers die daarop vertrouwen voor die certificaten moeten overstappen op certificaatintrekkingslijsten (CRL's).
• Google Chrome, de meest gebruikte browser, heeft de OCSP Must-Staple-hardfail-regel nooit standaard afgedwongen. In plaats daarvan vertrouwt de browser op zijn eigen CRLSet-mechanisme, dat de mate van extra bescherming die Must-Staple biedt beperkt, zelfs wanneer een certificeringsinstantie het nog steeds ondersteunt.
• Of OCSP Stapling nog steeds zinvol is voor een bepaald certificaat, hangt volledig af van de vraag of de uitgevende certificeringsinstantie nog steeds een OCSP-responder gebruikt. Dit moet per certificeringsinstantie worden geverifieerd en niet zomaar worden aangenomen.

Waarom dit een update nodig heeft

Let's Encrypt kondigde in december 2024 aan dat het OCSP in de loop van 2025 volledig zou uitfaseren, en hield zich strikt aan het tijdschema. Op 30 januari 2025 werd de uitgifte van nieuwe certificaten met de OCSP Must-Staple-extensie stopgezet. Op 7 mei 2025 werden OCSP-URL's volledig verwijderd van nieuw uitgegeven certificaten. Op 6 augustus 2025 werden de OCSP-responders volledig uitgeschakeld en werd er volledig overgeschakeld op Certificate Revocation Lists (CRL's). Voor elke server die een Let's Encrypt-certificaat presenteert dat na die datum is uitgegeven, is OCSP Stapling geen tragere of minder veilige optie, maar simpelweg niet beschikbaar, omdat er geen responder meer is om een ​​antwoord van te stapelen.

Uit het Trust Pulse-onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat bijna de helft van de bedrijven het afgelopen jaar te maken heeft gehad met een storing die verband hield met certificaten. 37.5% van de incidenten was gerelateerd aan verlopen certificaten en 18.5% van de getroffen organisaties meldde verliezen van meer dan $ 250,000. Een server die nog steeds geconfigureerd is om OCSP-reacties op te halen en te koppelen voor een certificeringsinstantie die deze niet langer levert, is een stille, gemakkelijk over het hoofd te zien factor die bijdraagt ​​aan dit soort storingsrisico's. Een verkeerd geconfigureerde of falende koppeling kan immers verbindingen verslechteren of verbreken, afhankelijk van de clientinstellingen.

Tegelijkertijd neemt de geldigheidsduur van certificaten af. Volgens CA/Browser Forum Ballot SC-081v3 , goedgekeurd op 11 april 2025, daalt de geldigheidsduur van publiek vertrouwde TLS-certificaten van 398 dagen naar 200 dagen vanaf 15 maart 2026, vervolgens naar 100 dagen vanaf 15 maart 2027 en naar 47 dagen vanaf 15 maart 2029. Kortere geldigheidsduur van certificaten verkleint de totale periode waarin een intrekkingsmechanisme, staple of anderszins, daadwerkelijk van belang is. Dit is een van de bredere redenen binnen de sector om volledig af te stappen van OCSP.

Wat is OCSP-nieten?

OCSP-stapling (Online Certificate Status Protocol) is een internetstandaard die wordt gebruikt om de intrekkingsstatus van een X.509-certificaat te controleren zonder dat de bezoekende client rechtstreeks contact hoeft op te nemen met de certificeringsinstantie. In plaats daarvan vraagt ​​de webserver zelf periodiek een ondertekend statusantwoord op bij de OCSP-responder van de certificeringsinstantie en voegt dit antwoord toe aan het certificaat tijdens de TLS-handshake. Als de browser een ingetrokken status ontvangt, waarschuwt deze de gebruiker en kan de verbinding worden geblokkeerd voordat er vertrouwelijke informatie wordt uitgewisseld.

De OCSP-validatieprocedure voor nieten

De onderstaande tabel beschrijft elke stap van het proces en wat er gebeurt als er iets misgaat.

Stap voor	Wat gebeurt er	Faal modus	Monitoringsignaal
1. Certificaatverlening	De certificeringsinstantie (CA) geeft een certificaat uit met een OCSP-responder-URL, waarmee wordt aangegeven dat OCSP voor dit certificaat wordt ondersteund.	Het certificaat wordt uitgegeven zonder OCSP-URL, zoals Let's Encrypt dat nu doet voor alle nieuwe certificaten.	Certificaatcontrole toont geen OCSP-veld voor toegang tot autoriteitsinformatie.
2. Beschikbaarheid van OCSP-medewerkers	De OCSP-responder van de CA beantwoordt statusvragen en publiceert regelmatig bijgewerkte statusinformatie.	De CA heeft zijn OCSP-responder volledig stopgezet, net zoals Let's Encrypt op 6 augustus 2025 heeft gedaan.	Een directe query naar de URL van de responder resulteert in een time-out of geeft een foutmelding.
3. De server haalt een reactie op en slaat deze in de cache op.	De webserver vraagt ​​een ondertekend OCSP-antwoord op en slaat dit in de cache op voor hergebruik bij verschillende clientverbindingen.	De server kan de responder niet bereiken en heeft geen antwoord in de cache voor Staple.	Serverlogboeken tonen herhaalde OCSP-fetchfouten.
4. TLS-handdruk en nieten	De server voegt het in de cache opgeslagen OCSP-antwoord toe aan het certificaat tijdens de handshake.	De server presenteert een certificaat zonder nietje, waardoor clients terugvallen op de standaard OCSP-methode of helemaal geen intrekkingscontrole meer uitvoeren.	SSL Labs of een vergelijkbare scan rapporteert OCSP Stapling als "Nee" of "Niet ondersteund".
5. Klantverificatie	De browser controleert de handtekening en status (goed, ingetrokken of onbekend) van het samengevoegde antwoord.	Een verouderde of verlopen nietje zorgt ervoor dat sommige clients terugvallen op een directe OCSP-query of de verbinding toch accepteren.	Foutmeldingen van client-side TLS of ontwikkelaarstools van de browser signaleren problemen met stapling.

Certificaatreactietypen

antwoord	Betekenis	Browsergedrag
Goed	De OCSP-responder herkent het serienummer van het certificaat en bevestigt dat het niet is ingetrokken.	De verbinding verloopt normaal.
Ingetrokken	Het certificaat is uitdrukkelijk ingetrokken door de uitgevende certificeringsinstantie.	Een harde stop; de browser blokkeert de verbinding en waarschuwt de gebruiker.
Onbekend	De ontvanger herkent het certificaat niet, vaak omdat het gecontroleerd moet worden aan de hand van een andere certificeringsinstantie (CA) dan degene waarvoor het is geconfigureerd.	Soft stop; het gedrag verschilt per browser en kan ervoor zorgen dat de verbinding toch doorgaat.

Voor- en nadelen van OCSP-nieten

Voordelen

• Verbeterde prestatie. De server cachet en hergebruikt het OCSP-antwoord, waardoor de extra communicatie die een client anders voor elke verbinding met de certificeringsinstantie zou moeten maken, wordt vermeden.
• Verbeterde privacy. Omdat de CA de periodieke vernieuwingsaanvraag van de server beantwoordt in plaats van een query voor elke individuele bezoeker, kan deze niet zien welke specifieke gebruikers welke sites bezoeken.
• Efficiënt gebruik van hulpbronnen. Stapling verbruikt minder netwerkbronnen dan standaard OCSP-query's per bezoeker of het downloaden van een volledige certificaatintrekkingslijst.

Nadelen

• Volledige afhankelijkheid van de OCSP-responder van de uitgevende CA. Als die responder niet meer beschikbaar is, zoals nu het geval is bij Let's Encrypt, heeft stapling simpelweg niets meer op te halen, ongeacht hoe goed de server geconfigureerd is.
• Beperkte dekking van de keten. Bij standaard OCSP-stapling worden doorgaans geen tussenliggende certificaten in de keten geverifieerd, hoewel multi-stapling en TLS 1.3-ondersteuning dit wel verhelpen op servers die deze technologieën implementeren.
• Updatevertraging. Er zit een daadwerkelijk tijdsverschil tussen de vernieuwingscycli, waardoor een certificaat dat vlak na de laatste vernieuwing is ingetrokken, tot de volgende ophaalactie nog steeds de status "goed" kan hebben.

Waarom niet-nieten ook uit de mode raakt

De OCSP Must-Staple-extensie was ontworpen om een ​​specifiek probleem op te lossen: zonder deze extensie kan een server de staple weglaten en heeft een browser geen manier om te weten dat er een staple aanwezig had moeten zijn. Must-Staple verbreekt de verbinding als er geen geldige staple is bijgevoegd, waardoor servers in theorie gedwongen worden om de staple correct te blijven gebruiken. In de praktijk werd de bruikbaarheid ervan echter altijd beperkt door de ongelijke browserondersteuning, en de extensie verdwijnt nu volledig uit het ecosysteem om een ​​meer directe reden. Google Chrome, de browser met het grootste aandeel in het webverkeer, heeft het harde faalgedrag van Must-Staple nooit native afgedwongen, maar vertrouwt in plaats daarvan op zijn eigen CRLSet-mechanisme om intrekkingsinformatie op grote schaal te verspreiden. Bovendien heeft Let's Encrypt op 30 januari 2025 de uitgifte van nieuwe Must-Staple-certificaten stopgezet als eerste stap in de bredere OCSP-afbouw. ​​Gezien de beperkte browserondersteuning en het feit dat de grootste certificeringsinstantie de extensie niet langer uitgeeft, is Must-Staple geen beveiligingsmaatregel waar we in de toekomst nog op moeten vertrouwen.

Controlelijst voor de gezondheid van OCSP-nietjes

1. Controleer welke certificeringsinstantie (CA) elk certificaat in uw omgeving heeft uitgegeven en of die CA nog steeds een OCSP-responder beheert.
2. Voor certificaten van een certificeringsinstantie die OCSP niet meer ondersteunt, moet u de stapling-configuratie voor die certificaten uitschakelen en controleren of de CRL-controle correct is geconfigureerd.
3. Voer periodiek een scan uit om de intrekking van licenties te controleren voor elke publiek toegankelijke hostnaam, niet alleen bij de eerste implementatie.
4. Controleer de serverlogboeken op herhaalde OCSP-ophaalfouten. Deze duiden op een storing bij de responder of op een certificaat van een certificeringsinstantie die OCSP niet langer ondersteunt.
5. Verwijder alle resterende OCSP Must-Staple-configuraties op certificaten van CA's die de extensie hebben afgeschaft, aangezien een harde foutinstelling zonder iets om te stapelen verbindingen volledig kan verbreken.
6. Raadpleeg deze checklist opnieuw wanneer een CA in uw omgeving een infrastructuurwijziging aankondigt, niet alleen volgens een vast schema.

Hoe controleer ik of OCSP Stapling is ingeschakeld?

De ondersteuning voor OCSP Stapling is tegenwoordig afhankelijk van de gebruikte webserversoftware, zoals een actuele versie van IIS, Nginx, Apache of Caddy, en niet van een specifieke, verouderde versie van het besturingssysteem. Elk modern, actief onderhouden serverplatform ondersteunt stapling; de praktische vraag is of het correct is geconfigureerd en of de certificeringsinstantie die het certificaat heeft uitgegeven nog steeds een responder heeft om gegevens van op te halen.

Stap 1: Ga naar SSL Labs van Qualys.

Stap 2: Vink het vakje aan om te voorkomen dat de resultaten op het openbare resultatenbord worden gepubliceerd als het domein privé moet blijven.

Stap 3: Voer de domeinnaam in om de scan te controleren en te verzenden.

Stap 4: Zodra de scan is voltooid, controleert u het gedeelte 'Intrekkingsinformatie', waarin de CRL- en OCSP-gegevens worden vermeld.

Stap 5: Controleer de rij OCSP Stapling. Een "Ja" betekent dat stapling actief is. Een "Nee" betekent dat het is uitgeschakeld, maar dat het certificaat nog steeds OCSP ondersteunt. Een resultaat "Niet ondersteund" kan betekenen dat de uitgevende CA zelf helemaal geen OCSP meer aanbiedt, wat nu het geval is voor certificaten van Let's Encrypt. Controleer daarom de uitgevende CA voordat u een serverconfiguratiefout veronderstelt.

Wie zou zich hier druk over moeten maken?

De overstap van OCSP brengt concrete configuratiebeslissingen met zich mee voor diverse functies.

PKI-beheerders

Behoud de intrekkingsconfiguratie op serverniveau. Actiepunt: controleer elk certificaat op de uitgevende CA en verwijder de OCSP Stapling- of Must-Staple-configuratie voor elke CA die de OCSP-ondersteuning heeft stopgezet.

Beveiligingsarchitecten

Stel de standaard voor het controleren van intrekkingen van certificaten binnen de organisatie vast. Actiepunt: definieer een op CRL gebaseerd terugvalbeleid voor elke certificeringsinstantie die OCSP niet langer ondersteunt, in plaats van het aan elk serverteam over te laten om dit zelfstandig te ontdekken.

Platformteams

Beheer de daadwerkelijke server- en load balancer-configuratie. Actiepunt: voer een scan uit om intrekking van certificaten te controleren voor alle publiekelijk toegankelijke hostnamen en corrigeer alle hosts die nog steeds geconfigureerd zijn voor OCSP Stapling met een CA die dit niet langer ondersteunt.

Compliance

Controleer of de auditdocumentatie het huidige gedrag van de certificeringsinstantie (CA) weerspiegelt. Actiepunt: werk alle bewijzen van naleving bij die nog steeds OCSP Stapling als standaard intrekkingsmechanisme vermelden, indien de betreffende CA is overgestapt op CRL's.

CISO's

Weeg de operationele kosten van het onderhouden van de intrekkingsconfiguratie per CA af tegen het risico van een onopgemerkte configuratiefout. Actiepunt: beschouw de uitschakeling van Let's Encrypt OCSP als een signaal om te bevestigen dat de intrekkingscontrole actueel is voor de volledige certificaatinventaris, niet alleen voor nieuw uitgegeven certificaten.

Onze visie: Hoe encryptieconsultancy het beheer van certificaatintrekking ondersteunt.

OCSP Stapling was een aanzienlijke verbetering ten opzichte van standaard OCSP zolang certificeringsinstanties er nog responders achter draaiden. Nu de grootste certificeringsinstantie op het web volledig van OCSP is afgestapt, is de praktische vraag voor de meeste organisaties niet langer hoe stapling correct geconfigureerd moet worden, maar welke certificaten het überhaupt nog nodig hebben.

Ons CertSecure Manager- platform biedt teams een volledig overzicht van machine-identiteiten en certificaatdetectie, waardoor een infrastructuurwijziging op CA-niveau zoals deze wordt weergegeven als een bekende inventarisupdate in plaats van een onverwachte storing. Voor organisaties die overwegen of ze de intrekkingsinfrastructuur al dan niet intern willen beheren, biedt ons PKI-as-a-Service- platform de mogelijkheid om de CA-hiërarchie, inclusief het publiceren van intrekkingen, uit te voeren op FIPS 140-3 Level 3 HSM-ondersteunde sleutels, terwijl uw organisatie het eigendom en de controle behoudt. Voor een nadere beschouwing van de verschillen tussen OCSP en CRL's kunt u onze handleiding over OCSP versus CRL raadplegen . Voor een gerelateerde, Windows-specifieke eigenaardigheid, kunt u ons artikel over het OCSP Magic Number bekijken, waarin een drempelwaarde wordt beschreven die clients stilzwijgend overschakelt van OCSP- naar CRL-controle. Op het gebied van cryptografische flexibiliteit helpen ons PQC Center of Excellence en de PQC Readiness Assessment teams bij het plannen voor een toekomst waarin de intrekkingsinfrastructuur zelf post-quantumveilige ondertekening vereist. Ons CBOM Secure cryptografische ontdekkings- en inventarisatieplatform biedt beveiligingsarchitecten inzicht in welke certificaten in een omgeving nog steeds afhankelijk zijn van een verouderde OCSP-configuratie.

Conclusie

OCSP Stapling was een verbetering ten opzichte van standaard OCSP, omdat het de intrekkingsstatus sneller en op een meer privacyvriendelijke manier leverde, zonder dat elke bezoekende client de CA rechtstreeks hoefde te raadplegen. Dit voordeel was echter altijd afhankelijk van het feit of de uitgevende CA nog steeds een OCSP-responder beheerde, en de grootste CA op het web doet dat niet meer. De gefaseerde uitfasering van Let's Encrypt, van het uitschakelen van Must-Staple-uitgifte in januari 2025 tot het volledig uitfaseren van de OCSP-responders in augustus 2025, betekent dat de juiste stap voor veel organisaties niet langer het optimaliseren van de stapling-configuratie is, maar het per certificaat controleren of OCSP überhaupt nog wordt gebruikt.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit deze inleiding tot OCSP-nieten?

OCSP Stapling verbetert de snelheid en privacy van het controleren op intrekking van certificaten, maar werkt alleen als de uitgevende certificeringsinstantie (CA) nog steeds een OCSP-responder gebruikt. Let's Encrypt, de grootste CA op het web, heeft zijn OCSP-responders op 6 augustus 2025 volledig buiten gebruik gesteld, waardoor stapling niet meer beschikbaar is voor de huidige certificaten.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

Serverconfiguraties die ervan uitgaan dat OCSP Stapling universeel beschikbaar is, kunnen nu ongemerkt niet functioneren voor certificaten uitgegeven door certificeringsinstanties die OCSP niet meer ondersteunen. Dit creëert een ongecontroleerde lacune in de controle op intrekking van certificaten.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Het handmatig bijhouden welke CA welk certificaat heeft uitgegeven en of die CA nog steeds OCSP ondersteunt, is niet schaalbaar. Bovendien kan een verouderde OCSP Must-Staple-configuratie leiden tot ernstige verbindingsproblemen zodra een CA helemaal geen antwoorden meer geeft.

Welke teams zouden verantwoordelijk moeten zijn voor deze verandering?

PKI-beheerders zijn verantwoordelijk voor de configuratie van intrekking op serverniveau, beveiligingsarchitecten stellen de CRL-fallbackstandaard vast, platformteams zijn verantwoordelijk voor het scannen en herstellen van problemen, compliance controleert de nauwkeurigheid van de documentatie en de CISO weegt de algehele risicoafweging af.

Hoe houdt dit verband met certificaatlevenscyclusbeheer?

Met behulp van tools voor certificaatlevenscyclusbeheer, die bijhouden welke certificeringsinstantie (CA) elk certificaat heeft uitgegeven, kunnen getroffen certificaten snel worden geïdentificeerd wanneer een CA haar intrekkingsinfrastructuur wijzigt, in plaats van de lacune te ontdekken via een verbindingsfout.

Hoe moeten organisaties succes meten?

Houd bij welk percentage van de publiekelijk toegankelijke hosts een correct geconfigureerde intrekkingscontrole heeft voor hun daadwerkelijke uitgevende CA, en bevestig dat er geen hosts meer geconfigureerd zijn voor OCSP Stapling of Must-Staple tegen een CA die dit niet langer ondersteunt.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Controleer regelmatig welke certificeringsinstantie (CA) elk certificaat heeft uitgegeven, of die CA nog steeds een OCSP-responder beheert, of stapling werkt waar geconfigureerd, en of CRL-terugval correct is ingesteld voor certificaten van CA's die niet langer gebruikmaken van OCSP.

Welke invloed heeft dit onderwerp op cloud-, hybride- of multi-CA PKI-oplossingen?

Een omgeving die certificaten van meerdere certificeringsinstanties (CA's) gebruikt, vereist mogelijk verschillende intrekkingsconfiguraties voor elk certificaat, aangezien het stopzetten van OCSP door één CA niet betekent dat elke CA in een omgeving met meerdere CA's of een hybride omgeving hetzelfde heeft gedaan.

Welke veelgemaakte fouten moeten teams vermijden?

Veelgemaakte fouten zijn onder andere de aanname dat OCSP Stapling op dezelfde manier werkt bij alle CA's, het ingeschakeld laten van OCSP Must-Staple op certificaten van een CA die geen OCSP-reacties meer verstuurt, en het beschouwen van de OS-versie van een server in plaats van de huidige OCSP-ondersteuning van de uitgevende CA als de doorslaggevende factor.

Wat moet er elk kwartaal vernieuwd worden?

Vernieuw de certificaatinventaris en de koppeling ervan aan de huidige OCSP-ondersteuningsstatus van elke uitgevende CA, voer opnieuw scans uit om intrekking van certificaten te controleren op publiekelijk toegankelijke hosts en controleer minstens elk kwartaal op nieuw aangekondigde wijzigingen in de CA-infrastructuur.