Online Certificate Status Protocol (OCSP) versus certificaatintrekkingslijsten (CRL's)

Introductie

Elk publiekelijk vertrouwd TLS-certificaat bevat een belofte: als het ooit gecompromitteerd, verloren of per vergissing uitgegeven wordt, kan het worden ingetrokken vóór de geplande vervaldatum. Online Certificate Status Protocol (OCSP) en Certificate Revocation Lists (CRL's) zijn de twee mechanismen die deze belofte afdwingbaar maken, en de keuze tussen beide is de afgelopen twee jaar aanzienlijk veranderd. Deze handleiding legt uit hoe elke methode in de praktijk werkt, waarom de aanbeveling van de branche zelf is gewijzigd sinds deze vergelijking voor het eerst werd geschreven, en hoe u kunt bepalen welke aanpak het beste bij een bepaalde omgeving past.

Kort samengevat: OCSP versus CRL

Zowel OCSP als CRL's worden gebruikt om te controleren of een certificaat is ingetrokken voordat het verloopt. OCSP vraagt ​​de responder van een certificeringsinstantie in realtime naar de status van een specifiek certificaat en retourneert 'goed', 'ingetrokken' of 'onbekend'. Een CRL is een ondertekende, downloadbare lijst van alle certificaten die een certificeringsinstantie heeft ingetrokken. Een client kan deze lijst lokaal raadplegen zonder voor elke zoekopdracht rechtstreeks contact op te nemen met de certificeringsinstantie.

Overzicht: Wat is er veranderd sinds deze vergelijking voor het eerst werd geschreven?

• OCSP controleert de status van een enkel certificaat in realtime; een CRL is een volledige lijst die een client downloadt en lokaal controleert.
• Let's Encrypt, de certificeringsinstantie achter ongeveer de helft van de TLS-certificaten op het web, heeft zijn OCSP-responders op 6 augustus 2025 volledig uitgeschakeld en is volledig overgestapt op CRL's.
• De belangrijkste drijfveer was niet de prestatie, maar de privacy: elk OCSP-verzoek laat de certificeringsinstantie in realtime weten welk IP-adres welke certificaatsite bezoekt.
• De kortere geldigheidsduur van certificaten volgens het nieuwe geldigheidsschema van het CA/Browser Forum verkort, maar elimineert niet volledig, de periode waarin het controleren op intrekking van certificaten van belang is.
• De juiste keuze hangt nog steeds af van wie beide uiteinden van de verbinding beheert: een openbare CA die willekeurige browsers bedient, heeft andere beperkingen dan een interne Active Directory Certificate Services (AD CS)-implementatie die bekende clients bedient.

Waarom deze vergelijking er in 2026 anders uitziet.

Het duidelijkste signaal dat dit onderwerp is veranderd, kwam van Let's Encrypt zelf. In een aankondiging in december 2024 schetste de non-profit CA een gefaseerde uitfasering van OCSP: nieuwe OCSP Must-Staple-verzoeken zouden vanaf 30 januari 2025 niet meer worden gehonoreerd, OCSP-URL's zouden op 7 mei 2025 van nieuw uitgegeven certificaten worden verwijderd en de OCSP-responders zouden op 6 augustus 2025 volledig worden uitgeschakeld. Let's Encrypt gaf een duidelijke reden voor de privacykosten van OCSP: een CA die OCSP-query's beantwoordt, leert in realtime welke IP-adressen welke sites van haar certificaathouders bezoeken, informatie die zij mogelijk verplicht is te bewaren of openbaar te maken. CRL's daarentegen worden in bulk gedownload en lokaal gecontroleerd, waardoor de CA nooit een query per bezoek ziet.

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 certificaatgerelateerde storing. 37.5% van deze incidenten was specifiek gerelateerd aan verlopen certificaten en 18.5% van de getroffen organisaties meldde verliezen van meer dan $ 250,000. Een trage of onbetrouwbare controle op intrekking van certificaten, bijvoorbeeld door een overbelaste OCSP-responder of een verouderde CRL-cache, vergroot dit soort risico's op storingen en heeft niet alleen gevolgen voor de beveiliging.

De geldigheidsduur van certificaten neemt af, terwijl de intrekkingsprocedure verandert. Volgens CA/Browser Forum Ballot SC-081v3 , goedgekeurd op 11 april 2025, daalt de geldigheidsduur van publiekelijk 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. Een certificaat dat 47 dagen geldig is, heeft simpelweg een kortere periode waarin intrekking überhaupt relevant is. Dit is deels de reden waarom sommige CA's CRL's nu als voldoende beschouwen in plaats van OCSP daar bovenop te plaatsen.

Op de langere termijn heeft NIST op 13 augustus 2024 de post-kwantumcryptografiestandaarden FIPS 203, 204 en 205 afgerond. Noch OCSP-reacties, noch CRL's worden tegenwoordig nog vaak ondertekend met post-kwantumalgoritmen, maar naarmate certificeringsinstanties plannen maken voor een flexibele infrastructuur voor cryptografisch ondertekenen, is intrekkingsdata een artefact dat uiteindelijk samen met de certificaten die het beschrijft, gemigreerd zal moeten worden.

Wat is OCSP?

Het Online Certificate Status Protocol (OCSP) is een internetprotocol waarmee een client aan de responder van een certificeringsinstantie kan vragen of een specifiek certificaat nog geldig is, zonder een volledige lijst te hoeven downloaden van alle certificaten die door de certificeringsinstantie zijn ingetrokken.

Hoe een OCSP-verzoek en -antwoord werken

Een OCSP-client stuurt een statusverzoek naar een OCSP-responder en wacht op een ondertekend antwoord voordat hij verdergaat. Het verzoek bevat de protocolversie, het type gevraagde service, een identificatiecode voor het doelcertificaat en eventuele optionele extensies. De responder controleert of het bericht correct is opgemaakt, of deze is geconfigureerd om namens de betreffende CA te antwoorden en of het verzoek de benodigde informatie bevat. Vervolgens retourneert de responder een definitief antwoord of een foutmelding.

Een standaard OCSP-antwoord bevat de versie van de antwoordsyntaxis, een identificatiecode voor de responder, het tijdstip waarop het antwoord is gegenereerd, een status voor elk aangevraagd certificaat, optionele extensies, de Object Identifier (OID) van het ondertekeningsalgoritme en een handtekening berekend over een hash van het antwoord, zodat de client kan controleren of het ongewijzigd van de CA afkomstig is. Er zijn drie mogelijke statuswaarden: 'good', wat betekent dat het certificaat voor zover de responder weet niet is ingetrokken; 'revoked', wat betekent dat het certificaat expliciet is ingetrokken of dat de CA geen gegevens heeft over de uitgifte ervan; en 'unknown', wat betekent dat de responder de uitgever van dat certificaat niet herkent.

OCSP-nieten

OCSP Stapling pakt de grootste zwakte van OCSP direct aan: in plaats van dat de client contact opneemt met de CA, haalt de webserver zelf periodiek een ondertekend, van een tijdstempel voorzien OCSP-antwoord op en voegt dit toe aan de TLS-handshake. Zo krijgen bezoekende browsers de intrekkingsstatus te zien zonder ooit contact op te nemen met de CA. Dit elimineert de extra communicatie en de privacyrisico's van een CA-query per bezoeker, aangezien de CA alleen de periodieke vernieuwingsverzoeken van de webserver ziet in plaats van elke individuele bezoeker. Stapling is echter niet universeel geïmplementeerd en het elimineert niet de andere operationele kosten van OCSP; een CA moet nog steeds een responderinfrastructuur beheren die grootschalig vernieuwingsverkeer aankan.

Wat is een certificaatintrekkingslijst (CRL)?

Een certificaatintrekkingslijst (CRL) is een ondertekende lijst, gepubliceerd door de uitgevende certificeringsinstantie (CA), van alle certificaten die vóór hun geplande vervaldatum zijn ingetrokken en niet langer betrouwbaar zijn. Clients halen de CRL op bij een CRL-distributiepunt, een X.509v3-certificaatextensie die verwijst naar een HTTP- of LDAP-locatie, en controleren lokaal of het certificaat dat ze valideren op de CRL voorkomt.

Ingetrokken versus Behoud Staten

Een CRL-vermelding kan twee statussen weergeven. Een ingetrokken certificaat wordt onherroepelijk verwijderd, meestal vanwege een gecompromitteerde sleutel, een gecompromitteerde certificeringsinstantie (CA), een wijziging van de affiliatie of een andere reden die is gedefinieerd in de X.509-codes voor intrekkingsredenen; het kan niet worden hersteld. Een certificaat dat in de wachtstand is geplaatst, wordt tijdelijk opgeschort in plaats van permanent ingetrokken. Als bijvoorbeeld een privésleutel die verloren werd gewaand, veilig wordt teruggevonden, kan het certificaat weer geldig worden, wat een belangrijk operationeel verschil is met een onherroepelijke intrekking.

Hoe CRL-distributie in de praktijk werkt

Een CRL werkt grotendeels hetzelfde als een zwarte lijst. Een client haalt de actuele CRL op bij het distributiepunt van de certificeringsinstantie (CA) en controleert of het betreffende certificaat er niet in voorkomt. Omdat de volledige lijst moet worden gedownload en verwerkt, kan een grote CRL aanzienlijk meer resources van de client en het netwerk belasten dan een enkele OCSP-query. Bovendien is het publiceren van een nieuwe CRL na een intrekking doorgaans trager dan een OCSP-responder in realtime kan reageren. De meeste TLS-stacks zijn ook geconfigureerd om de verbinding te openen bij een fout: als een client de CRL helemaal niet kan downloaden, vertrouwt deze standaard het certificaat in plaats van de verbinding te blokkeren. Dit is een bekende afweging en geen fout.

OCSP versus CRL: een directe vergelijking.

Factor	OCSP	CRL
Wat het controleert	Status van één specifiek certificaat per aanvraag	Volledige lijst van alle certificaten die de CA heeft ingetrokken
Waar de controle plaatsvindt	De client vraagt ​​de OCSP-responder van de CA rechtstreeks aan, tenzij deze is samengevoegd.	De client downloadt de lijst eenmaal en controleert deze lokaal.
Privacy-inbreuk	De certificeringsinstantie (CA) ziet het IP-adres van elke client en welk certificaat er wordt gecontroleerd, tenzij er een koppeling is gemaakt.	CA ziet geen individuele zoekopdrachten per bezoek.
Netwerk- en clientbelasting	Laag per verzoek, maar de responders moeten een hoog queryvolume verwerken.	Kan veel werk kosten bij het downloaden van grote lijsten met ingetrokken certificaten.
Falend gedrag	Een storing aan de serverzijde kan de validatie blokkeren of stilzwijgend overslaan, afhankelijk van de clientconfiguratie.	Een ontbrekende CRL (Certificate Revocation List) leidt doorgaans tot een fout bij het openen van het systeem, waarbij standaard het certificaat wordt vertrouwd.
richting van de industrie in 2026	Wordt vanaf 6 augustus 2025 uitgefaseerd door grote certificeringsinstanties, waaronder Let's Encrypt.	Steeds vaker wordt het gebruikt als het primaire of enige intrekkingsmechanisme, soms in combinatie met kortstondige certificaten.

Beslissingsmatrix: Een strategie voor het controleren van intrekkingen kiezen

Use Case	Beveiligingsimpact	Operationele inspanning	Automatisering Fit	Aanbevolen eigenaar
TLS-certificaten voor het publiek, afkomstig van een openbare certificeringsinstantie (CA).	Middellange, kortere geldigheidsperioden verkorten de blootstellingsperiode.	Laag, de meeste openbare CA's beheren dit nu centraal.	Hoog, grotendeels beheerd door CA.	Platformteams
Interne AD CS of privé-PKI voor bekende klanten	Een gecompromitteerd intern certificaat kan de authenticatie in brede zin beïnvloeden.	Gemiddelde moeilijkheidsgraad, vereist het beheren en schalen van een online responder-rol.	Gemiddelde moeilijkheidsgraad, vereist configuratie maar is stabiel na afstelling.	PKI-beheerders
Niet-browser- of IoT-apparaatvloten	Gemiddeld tot hoog, afhankelijk van hoe apparaten worden geverifieerd.	Middelgrote CRL-distributie op grote schaal vereist planning.	Het ophalen van een CRL via een gemiddeld schema is over het algemeen eenvoudiger dan OCSP voor apparaten met beperkte resources.	Platformteams
Omgevingen met hoge beveiligingseisen die vrijwel onmiddellijke controle op intrekking vereisen.	Een hoge vertraging in de verspreiding van de intrekking vormt op zichzelf een risico.	Hoog, vereist OCSP Stapling plus een CRL-terugvalpad.	Gemiddeld, vereist dat beide mechanismen correct geconfigureerd zijn.	Beveiligingsarchitecten
Oudere of beperkte clients zonder OCSP Stapling-ondersteuning	Medium	Bij een lage CRL-waarde wordt dit over het algemeen zonder speciale configuratie ondersteund.	Hoog, CRL's fungeren als een universele terugvaloptie.	Compliance, Platformteams

Kiezen tussen OCSP en CRL

Er is geen eenduidig, universeel juist antwoord, maar de beslissing hangt meestal af van wie de controle heeft over beide uiteinden van de verbinding, hoe belangrijk het moment van intrekking is en wat de clientpopulatie daadwerkelijk aankan.

Een snelle beslissingsgids

1. Als zowel alle clients als de CA OCSP Stapling ondersteunen, gebruik dan stapling als primair mechanisme, met een CRL als gedocumenteerd alternatief voor clients die dit niet ondersteunen.
2. Als het minimaliseren van wat de certificeringsinstantie kan waarnemen over het gedrag van bezoekers een prioriteit is, geef dan de voorkeur aan CRL's, of combineer kortstondige certificaten met CRL's, zodat de blootstellingsperiode klein blijft, zelfs zonder realtime controle.
3. Als de clientpopulatie niet-browsersoftware, IoT-apparaten of netwerkapparaten omvat die geen stapling kunnen implementeren, zijn CRL's doorgaans de eenvoudigere en universeel ondersteunde oplossing.
4. Als het gaat om een ​​interne AD CS-implementatie of een private PKI waarbij de organisatie zowel de CA als elke client beheert, blijft OCSP met een correct opgeschaalde Online Responder-rol een praktische optie. De privacyoverwegingen die ten grondslag lagen aan de beslissing van Let's Encrypt gelden immers vooral voor openbare CA's die onbekende clients bedienen.

Voor- en nadelen in één oogopslag

• OCSP-voordelen: controleert alleen het betreffende certificaat in plaats van een hele lijst, en geeft direct antwoord wanneer de responder in orde is.
• Nadelen van OCSP: IP-adressen van bezoekers en websitebezoeken worden blootgesteld aan de CA, tenzij ze gekoppeld zijn, en storingen aan de responder worden in het verleden inconsistent afgehandeld door verschillende clients.
• CRL-voordelen: geen query per bezoek aan de certificeringsinstantie, werkt overal als een betrouwbare terugvaloptie en is nu het primaire of enige mechanisme bij certificeringsinstanties van de omvang van Let's Encrypt.
• Nadelen van CRL's: het downloaden van de volledige lijst kan omvangrijk zijn voor een certificeringsinstantie met veel intrekkingen, en door publicatievertragingen kan een zeer recente intrekking niet direct verschijnen.

Wie zou zich hier druk over moeten maken?

De overstap van OCSP naar andere systemen bij grote openbare certificeringsinstanties heeft gevolgen voor concrete operationele beslissingen in diverse functies.

PKI-beheerders

Configureer en onderhoud de online responder of CRL-distributiepunten waarvan uw certificeringsinstantie (CA) daadwerkelijk afhankelijk is. Actiepunt: controleer welke van uw certificaten nog verwijzen naar OCSP-URL's van een CA die de service inmiddels heeft afgeschaft, en controleer of de CRL-distributiepunten bereikbaar en actueel zijn.

Beveiligingsarchitecten

Bepaal de procedure voor het controleren op intrekking van certificaten voor systemen met een hoge beveiliging. Actiepunt: documenteer een terugvalprocedure voor elk systeem dat nog steeds uitgaat van de beschikbaarheid van OCSP, aangezien de responders bij sommige openbare CA's niet meer bestaan.

Platformteams

Eigen clientconfiguratie op alle servers, loadbalancers en apparaatparken. Actiepunt: controleer of TLS-terminatiepunten die OCSP Stapling-reacties verwachten, een CRL-terugvaloptie hebben geconfigureerd in plaats van stilzwijgend te falen.

Compliance

Bevestig dat het bewijsmateriaal voor de intrekkingscontrole nog steeds overeenkomt met de manier waarop certificaten daadwerkelijk in productie worden gevalideerd. Actiepunt: werk de auditdocumentatie bij die OCSP nog steeds als standaardmechanisme vermeldt als de betreffende CA is overgestapt op CRL's.

CISO's

Weeg de afweging tussen privacy en betrouwbaarheid bij het controleren op intrekking van certificaten af ​​als onderdeel van de bredere strategie voor de levenscyclus van certificaten. Actiepunt: onderzoek of kortere certificatenlevensduren volgens het schema van het CA/Browser Forum van invloed zijn op de mate waarin de organisatie moet investeren in realtime intrekkingsinfrastructuur versus controle op basis van CRL's.

Onze visie: Hoe encryptieconsultancy certificaatintrekking en levenscyclusbeheer ondersteunt.

Of een omgeving nu gebruikmaakt van OCSP, CRL's of een combinatie van beide, de onderliggende vereiste is hetzelfde: weten welke certificaten er bestaan, hoe ze worden gevalideerd en of dat validatieproces nog steeds overeenkomt met de huidige werkwijze van de uitgevende certificeringsinstantie.

Ons CertSecure Manager- platform biedt teams een volledig overzicht van machine-identiteiten en certificaatdetectie in een omgeving, zodat een wijziging op CA-niveau, zoals het stopzetten van OCSP door Let's Encrypt, niet als een onverwachte storing optreedt. Voor teams die overwegen of ze de intrekkingsinfrastructuur intern willen blijven beheren, biedt ons PKI-as-a-Service- platform de mogelijkheid om de CA-hiërarchie, inclusief het publiceren van intrekkingscertificaten, uit te voeren op FIPS 140-3 Level 3 HSM-ondersteunde sleutels, terwijl uw organisatie het eigendom en de controle behoudt. Voor een dieper inzicht in de gerelateerde intrekkingsmechanismen kunt u onze handleidingen raadplegen over het OCSP Magic Number , een Windows-specifieke drempelwaarde die stilzwijgend overschakelt van OCSP naar CRL-controle, en CRL-reden codes , waarin wordt uitgelegd wat elke intrekkingscode in de praktijk betekent. 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 intrekkingsgegevens zelf post-quantumveilige ondertekening vereisen. Ons CBOM Secure cryptografische ontdekkings- en inventarisatieplatform biedt beveiligingsarchitecten inzicht in welke certificaten in een omgeving nog steeds afhankelijk zijn van een verouderde OCSP-responder.

Conclusie

OCSP en CRL's lossen hetzelfde probleem op: ze bevestigen dat een certificaat niet is ingetrokken. Dit gebeurt via verschillende afwegingen tussen realtime nauwkeurigheid, privacy en operationele eenvoud. Wat er werkelijk is veranderd sinds deze vergelijking voor het eerst nuttig was, is dat het standaardantwoord in de branche is omgedraaid: de volledige stopzetting van OCSP door Let's Encrypt op 6 augustus 2025 laat zien dat CRL's, die ooit als de oudere en zwaardere optie werden beschouwd, nu het primaire mechanisme op CA-niveau zijn en meer certificaten uitgeven dan welk ander mechanisme ook. Teams die er nog steeds van uitgaan dat OCSP universeel beschikbaar is, of die niet hebben gecontroleerd of hun CA het voorbeeld van Let's Encrypt heeft gevolgd, zouden dit moeten beschouwen als een achterstallige configuratiecontrole in plaats van een vaststaande aanname.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het Online Certificate Status Protocol (OCSP) versus Certificate Revocation Lists (CRL's)?

OCSP controleert de status van een enkel certificaat in realtime, maar geeft bezoekersactiviteit bloot aan de certificeringsinstantie, tenzij deze is gekoppeld aan een certificaat (stapled). CRL's daarentegen zijn een downloadbare lijst die lokaal wordt gecontroleerd. Grote certificeringsinstanties, waaronder Let's Encrypt sinds 6 augustus 2025, zijn overgestapt van OCSP naar CRL's als primair mechanisme.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

Configuraties en auditdocumentatie die zijn opgesteld toen OCSP de standaard was, komen mogelijk niet meer overeen met de manier waarop een bepaalde CA certificaten tegenwoordig daadwerkelijk valideert. Dit kan leiden tot onzichtbare hiaten in de controle op intrekking van certificaten.

Welke risico's nemen toe als de controle op intrekking handmatig wordt uitgevoerd of niet wordt gecontroleerd?

Systemen kunnen onbewust certificaten vertrouwen die eigenlijk geweigerd hadden moeten worden, bijvoorbeeld omdat een OCSP-responder waarvan ze afhankelijk zijn, is uitgeschakeld of omdat een verouderde CRL-cache nooit wordt vernieuwd. Niemand merkt dit op totdat er een incident plaatsvindt.

Welke teams zouden deze beslissing moeten nemen?

PKI-beheerders zijn verantwoordelijk voor de configuratie van de responder en het distributiepunt, beveiligingsarchitecten bepalen de intrekkingscontrole voor gevoelige systemen, platformteams zijn verantwoordelijk voor de configuratie aan de clientzijde, compliance controleert of de documentatie overeenkomt met de werkelijkheid en de CISO weegt de algehele afweging tussen privacy en betrouwbaarheid af.

Hoe houdt dit verband met certificaatlevenscyclusbeheer?

Het controleren op intrekking is een fase in de levenscyclus van certificaten, naast uitgifte, verlenging en vervaldatum. Tools voor certificaatlevenscyclusbeheer die volledige ontdekking en inventarisatie bieden, maken het mogelijk om te weten welke certificaten afhankelijk zijn van welk intrekkingsmechanisme voordat een certificeringsinstantie (CA) haar infrastructuur wijzigt.

Hoe kunnen organisaties meten of hun strategie voor het controleren van intrekkingen effectief is?

Controleer of er nog certificaten zijn die verwijzen naar OCSP-URL's van een certificeringsinstantie die de service heeft afgeschaft, bevestig dat CRL-distributiepunten correct worden opgelost en actueel zijn, en monitor op storingen die verband houden met mislukte of trage intrekkingcontroles in plaats van alleen de vervaldatum van certificaten te volgen.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Controleer regelmatig welk intrekkingsmechanisme elke uitgevende CA daadwerkelijk ondersteunt, verifieer of OCSP Stapling werkt waar geconfigureerd, controleer of de CRL-ophaalintervallen geschikt zijn voor de certificaatpopulatie en herzie aannames telkens wanneer een CA een infrastructuurwijziging publiceert.

Welke gevolgen heeft dit onderwerp voor cloud-, hybride- of multi-CA PKI-omgevingen?

Een omgeving die een openbare CA zoals Let's Encrypt combineert met een interne AD CS-hiërarchie of een cloud-native CA, vereist mogelijk verschillende intrekkingsstrategieën voor elk van beide, aangezien de overstap van een openbare CA naar CRL's niet dezelfde verandering vereist of impliceert voor een interne PKI die een bekende klantengroep bedient.

Welke veelgemaakte fouten moeten teams vermijden?

Veelgemaakte fouten zijn onder andere de aanname dat OCSP universeel beschikbaar is zonder te controleren of de uitgevende CA nog steeds een responder gebruikt, het beschouwen van het fail-open-gedrag van een ontbrekende CRL als een bug in plaats van een bewuste ontwerpkeuze, en het nooit opnieuw bekijken van de intrekkingsconfiguratie na de eerste implementatie.

Wat moet er elk kwartaal worden bijgewerkt in het kader van een strategie voor het controleren van intrekkingen?

Controleer of een uitgevende certificeringsinstantie wijzigingen heeft aangekondigd in haar OCSP- of CRL-infrastructuur, bevestig dat de certificaatinventarissen zijn bijgewerkt, raadpleeg het gepubliceerde geldigheidsschema van het CA/Browser Forum opnieuw op wijzigingen en controleer of kortere certificaatlevensduren de praktische behoefte aan realtime controle op intrekking in een bepaalde omgeving hebben verminderd.