Inzicht in en optimalisatie van OCSP voor Enterprise PKI

Een systeem voor het intrekken van certificaten is slechts zo sterk als de infrastructuur die het afdwingt. Wanneer een privésleutel wordt gecompromitteerd of een certificaat onjuist wordt uitgegeven, is intrekking een cruciale verdedigingslinie. Het is het mechanisme dat elke partij in uw omgeving die op dat certificaat vertrouwt , onmiddellijk laat weten dat het niet langer wordt vertrouwd. Maar intrekking werkt alleen als clients de intrekkingsservice daadwerkelijk kunnen bereiken, een nieuw antwoord ontvangen en daar correct op reageren.

Het Online Certificate Status Protocol (OCSP) is het realtime intrekkingscontrolemechanisme dat de kern vormt van moderne PKI. Ondanks zijn cruciale rol blijft OCSP echter een van de meest inconsistent geïmplementeerde en slecht begrepen componenten in de certificaatinfrastructuur van bedrijven. Organisaties installeren de Online Responder-rol, vinken een paar vakjes aan en gaan ervan uit dat de klus geklaard is. Maanden later ontdekken ze dat hun OCSP-responder stilletjes fouten heeft geretourneerd, dat hun ondertekeningscertificaat is verlopen zonder dat iemand het merkte, of dat hun servers nooit daadwerkelijk OCSP-reacties aan TLS-handshakes hebben gekoppeld.

Deze handleiding behandelt de OCSP-configuratie van begin tot eind: wat OCSP is, hoe het werkt op protocolniveau, hoe u het configureert op de platforms die uw organisatie gebruikt en welke geavanceerde instellingen een productieklare implementatie onderscheiden van een standaardinstallatie.

Kort antwoord: Wat is OCSP en waarom is het belangrijk voor Enterprise PKI?

OCSP (Online Certificate Status Protocol) , gedefinieerd in RFC 6960, stelt clients in staat om de realtime intrekkingsstatus van een specifiek certificaat op te vragen zonder een volledige CRL te downloaden. De OCSP-responder retourneert 'Goed', 'Ingetrokken' of 'Onbekend'. Bij een onjuiste configuratie of wanneer OCSP niet beschikbaar is, zullen browsers en TLS-clients de verbinding tijdelijk verbreken, waardoor een ingetrokken certificaat van een gecompromitteerde sleutel vertrouwd kan blijven tot het verloopt.

Key Takeaways

• OCSP soft-fail is het standaardgedrag in de meeste TLS-clients: als de OCSP-responder niet beschikbaar is of een foutmelding geeft, zet de client de verbinding voort. Een ingetrokken certificaat blijft vertrouwd tot het verloopt als de OCSP-infrastructuur stilzwijgend uitvalt. Dit is het fundamentele risico dat een OCSP-configuratie van productieniveau moet aanpakken.
• Zonder de deterministische GOOD-responsconfiguratie (KB 2960124) op Windows ADCS retourneert de Online Responder GOOD voor elk serienummer dat niet in de CRL staat, inclusief gefabriceerde serienummers van vervalste certificaten. Dit is een kritieke beveiligingslek in standaard ADCS-implementaties.
• Het OCSP-ondertekeningscertificaat moet de id-kp-OCSPSigning EKU (OID 1.3.6.1.5.5.7.3.9) en de id-pkix-ocsp-nocheck-extensie bevatten. Volgens RFC 6960 sectie 4.2.2.2 moet het ondertekeningscertificaat zijn uitgegeven door hetzelfde CA-sleutelpaar dat het te valideren certificaat heeft uitgegeven. Een door een root-CA uitgegeven OCSP-ondertekeningscertificaat voor certificaten van uitgevende CA's schendt deze vereiste en veroorzaakt interoperabiliteitsproblemen met niet-Microsoft-clients.
• Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van alle bedrijven het afgelopen jaar te maken gehad met uitval als gevolg van certificaatproblemen. Het verlopen van OCSP-ondertekeningscertificaten behoort tot de meest impactvolle singlepoint-storingen in PKI: wanneer het ondertekeningscertificaat verloopt, mislukken alle intrekkingsreacties voor die CA tegelijkertijd.
• CA/Browser Forum-stemming SC-081v3 (april 2025) verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 47 dagen tegen maart 2029. Naarmate de levensduur van certificaten korter wordt, neemt het aantal OCSP-query's evenredig toe, wordt OCSP-stapling operationeel essentieel voor de prestaties en moet de vernieuwingsfrequentie van OCSP-ondertekeningscertificaten worden beheerd met CLM-automatisering in plaats van handmatige registratie.

Voor wie is de configuratie van Enterprise OCSP relevant?

De OCSP-infrastructuur omvat PKI-, beveiligings-, platform- en compliance-teams. Elke onderstaande rol heeft er direct belang bij dat de intrekkingscontrole daadwerkelijk werkt wanneer een certificaat is gecompromitteerd.

Wat is OCSP en waarom is het belangrijk?

Het Online Certificate Status Protocol (OCSP), gedefinieerd in RFC 6960, biedt clients een mechanisme om in realtime de intrekkingsstatus van een specifiek certificaat op te vragen. In tegenstelling tot Certificate Revocation Lists (CRL's) , waarbij een client een volledige lijst met ondertekende certificaten moet downloaden en lokaal moet verwerken, maakt OCSP een gerichte query mogelijk: is certificaat met serienummer X, uitgegeven door CA Y, ingetrokken?

De OCSP-responder, die door de CA zelf kan worden beheerd of aan een aparte server kan worden uitbesteed, retourneert een van de volgende drie antwoorden:

• Goed: Het certificaat wordt als geldig beschouwd en is momenteel niet ingetrokken. Het serienummer is in ieder geval niet gevonden in de CRL die door de respondent is gebruikt. Dit bevestigt echter niet dat het certificaat ooit is uitgegeven. Zonder deterministische responsconfiguratie (KB 2960124) kan zelfs een verzonnen serienummer de melding 'Goed' retourneren.
• Ingetrokken: Het certificaat is niet langer geldig vanwege intrekking, wat door clients doorgaans als een harde fout wordt beschouwd. Intrekking kan tijdelijk (certificateHold) of permanent zijn. RFC 6960 staat deze status ook toe voor serienummers die nooit door de CA zijn uitgegeven, zodat de client het certificaat afwijst in plaats van een andere bron te raadplegen. Wanneer 'Revoked' wordt gebruikt voor niet-uitgegeven certificaten, vereist RFC 6960 de opname van de uitgebreide definitie van 'revoked' en specifieke gestandaardiseerde antwoordvelden.
• Onbekend: De responder kan de status van het certificaat niet vaststellen, omdat het serienummer niet wordt herkend of omdat het certificaat niet is uitgegeven door de certificeringsinstantie (CA) waarvoor deze responder is geconfigureerd. 'Onbekend' is niet hetzelfde als 'Ingetrokken': veel implementaties beschouwen 'Onbekend' of OCSP-fouten als een soft-fail en zetten de verbinding voort.

Deze variabiliteit in soft-fail-status kan risico's met zich meebrengen in omgevingen die afhankelijk zijn van strikte controle op intrekking van certificaten. Als de OCSP-infrastructuur niet beschikbaar is, verkeerd geconfigureerd is of verouderde antwoorden geeft, kan de intrekking mogelijk niet betrouwbaar worden afgedwongen. In dergelijke gevallen worden de garanties van een PKI verzwakt en bestaat het risico dat certificaten worden vertrouwd die niet langer geldig zouden moeten zijn, inclusief certificaten die gekoppeld zijn aan gecompromitteerde sleutels.

Hoe OCSP werkt: de volledige aanvraag-antwoordcyclus

Inzicht in OCSP op protocolniveau is essentieel voor een effectieve configuratie en zinvolle probleemoplossing. De onderstaande zesstappenlevenscyclus koppelt elke fase aan de bijbehorende RFC-referentie en operationele betekenis.

Stap 1: Certificaatuitreiking

Tijdens een TLS-handshake presenteert de server zijn certificaat aan de client. Het certificaat bevat een Authority Information Access (AIA) -extensie die de URL van de OCSP-responder specificeert, bijvoorbeeld http://ocsp.example.com. Als OCSP-stapling is ingeschakeld, voegt de server een vooraf opgehaalde, in de cache opgeslagen OCSP-respons rechtstreeks toe aan de handshake, waardoor de client helemaal geen contact meer hoeft op te nemen met de responder.

Stap 2: OCSP-aanvraagconstructie

De client construeert een OCSP-verzoek dat de hash van de naam van de uitgever, de hash van de openbare sleutel van de uitgever en het serienummer van het te valideren certificaat bevat. Deze velden zijn gedefinieerd in de CertID-structuur van RFC 6960 en worden gehasht met behulp van een digest-algoritme.

Stap 3: Verzoek om verzending

Het OCSP-verzoek wordt via HTTP verzonden naar de responder-URL die te vinden is in de AIA-extensie van het certificaat. OCSP gebruikt doorgaans HTTP (poort 80) vanwege de prestaties en de mogelijkheid om gegevens in de cache op te slaan. RFC 6960 definieert het verzoekformaat, terwijl RFC 5019 een lichtgewicht profiel biedt dat is geoptimaliseerd voor omgevingen met een hoog volume.

Stap 4: Evaluatie van de respondent

De OCSP-responder ontvangt het verzoek en bepaalt de intrekkingsstatus van het certificaat. Hoe deze gegevens worden opgehaald, verschilt per implementatie. In Microsoft Windows ADCS-omgevingen downloadt de Online Responder CRL's van de certificeringsinstantie (CA) en gebruikt deze om de intrekkingsstatus te bepalen. In andere implementaties, zoals Keyfactor EJBCA, kan de responder de CA-database rechtstreeks raadplegen of vooraf gegenereerde, in de cache opgeslagen antwoorden aanbieden.

Stap 5: Ondertekend antwoord

De responder stuurt een digitaal ondertekend antwoord terug. Volgens RFC 6960 moet de OCSP-ondertekeningssleutel toebehoren aan een van de drie geautoriseerde partijen: een CA die het te controleren certificaat heeft uitgegeven, een Trusted Responder wiens publieke sleutel door de client wordt vertrouwd, of een CA Designated Responder met een speciaal gemarkeerd delegatiecertificaat dat door die CA is uitgegeven. De handtekening zorgt ervoor dat het antwoord tijdens de overdracht niet kan worden gemanipuleerd. Voordat de client een OCSP-antwoord vertrouwt, moet deze de handtekening valideren, de certificaatketen van de ondertekening verifiëren en de autorisatie van de responder bevestigen.

Stap 6: Clientvalidatie

De client verifieert de handtekening op het OCSP-antwoord, controleert de geldigheidsdatums om te bevestigen dat het antwoord actueel is, en gebruikt de geretourneerde status om te beslissen of de verbinding moet worden voortgezet of beëindigd. RFC 6960 Sectie 2.4 definieert vier velden die de geldigheid van het antwoord bepalen:

• deze update — Het meest recente tijdstip waarop de respondent weet dat de aangegeven status correct was.
• volgendeUpdate — Het tijdstip waarop, of vóór welk tijdstip, nieuwere informatie beschikbaar komt over de status van het certificaat.
• geproduceerdBij — Het tijdstip waarop de OCSP-medewerker dit antwoord heeft ondertekend.
• intrekkingTijd — Het tijdstip waarop het certificaat werd ingetrokken of opgeschort. Alleen aanwezig in reacties met de melding 'Ingetrokken'.

Het veld nextUpdate heeft directe operationele gevolgen. Als een responder zijn intrekkingsgegevens niet vernieuwt voordat nextUpdate is verstreken, beschouwen clients het antwoord als verouderd. Afhankelijk van hun configuratie zullen ze terugvallen op CRL-gebaseerde controle of, in implementaties met harde faalregels, de verbinding volledig weigeren. In Windows ADCS stelt de Online Responder het veld nextUpdate automatisch in op de vervaldatum van de CRL die hij heeft gebruikt. Er is geen native configuratieoptie om dit te overschrijven. De enige manier om de cachevensters voor OCSP-antwoorden aan de clientzijde in ADCS te verkorten, is door de geldigheidsperiode van de CRL bij de uitgevende CA te verkorten.

OCSP Stapling: de prestatie- en privacyverbetering

Traditionele OCSP kent twee noemenswaardige operationele problemen. Ten eerste voegt het latentie toe aan elke TLS-handshake, omdat de client een afzonderlijk HTTP-verzoek naar de OCSP-responder moet sturen voordat de verbinding tot stand kan komen. Ten tweede creëert het een privacyrisico, omdat de OCSP-responder IP-adressen van clients kan koppelen aan certificaatopzoekingen. Dit leidt in sommige gereguleerde omgevingen tot nalevingsproblemen onder kaders zoals HIPAA en GDPR.

OCSP-stapling pakt beide problemen aan door de verantwoordelijkheid voor het controleren op intrekking van certificaten van de client naar de server te verplaatsen. Dit wordt geïmplementeerd via de TLS Certificate Status Request (status_request) extensie, gedefinieerd in sectie 8 van RFC 6066. Met OCSP-stapling:

1. De server vraagt ​​periodiek de OCSP-responder van de certificeringsinstantie om de intrekkingsstatus van zijn eigen certificaat.
2. Het ondertekende, van een tijdstempel voorziene OCSP-antwoord wordt door de server in de cache opgeslagen.
3. Tijdens elke TLS-handshake voegt de server dit in de cache opgeslagen antwoord samen met zijn certificaat toe.
4. De klant ontvangt zowel het certificaat als de intrekkingsstatus ervan in één retourtransactie, zonder dat een aparte verbinding met de certificeringsinstantie nodig is.

Omdat het OCSP-antwoord digitaal is ondertekend door de OCSP-responder van de certificeringsinstantie, kan een kwaadwillende server het niet vervalsen of wijzigen. De client valideert de handtekening op het samengevoegde antwoord nog steeds voordat deze het vertrouwt, waardoor de beveiliging gewaarborgd blijft en de extra communicatie en het risico op privacyschending worden geëlimineerd.

Voor een dieper inzicht in de OCSP Stapling-configuratie, de gevolgen voor de prestaties en de manier waarop kortere certificaatlevensduren het OCSP-queryvolume beïnvloeden, kunt u onze artikelen ' Inleiding tot OCSP Stapling' en 'OCSP Stapling en certificaatlevensduren' lezen.

De Windows Online Responder configureren: Geavanceerde instellingen

Het implementeren van de Windows Online Responder-rol is relatief eenvoudig, maar de juiste configuratie voor een PKI-productieomgeving vereist een dieper inzicht in hoe ADCS omgaat met intrekkingsgegevens, responderautorisatie, ondertekeningscertificaten en responsvalidatie. Veel van de standaardinstellingen zijn ontworpen voor basisfunctionaliteit in plaats van strikte beveiligingsgaranties of grootschalige bedrijfsactiviteiten. De volgende secties behandelen verschillende geavanceerde OCSP-configuratiegebieden die aanzienlijke operationele en beveiligingsimplicaties hebben in praktijksituaties.

Deterministische GOOD-reacties en hotfix 2960124

Een aspect dat in ADCS-omgevingen vaak over het hoofd wordt gezien, is de manier waarop de Windows Online Responder standaard de certificaatstatus beoordeelt. De responder gebruikt voornamelijk CRL-gegevens om de intrekkingsstatus te bepalen. Als gevolg hiervan kan de responder, als een certificaatserienummer niet in de CRL voorkomt, aannemen dat het certificaat geldig is en de status 'GOED' retourneren, zelfs als dat certificaat nooit daadwerkelijk door de CA is uitgegeven.

In de praktijk betekent dit dat een vervalst certificaat met een gefabriceerd serienummer de OCSP-validatie zou kunnen doorstaan. De CRL registreert alleen wat is ingetrokken; het heeft geen kennis van wat rechtmatig is uitgegeven. De respondent kan dus, uitsluitend op basis van de CRL, geen onderscheid maken tussen een echt uitgegeven certificaat en een vervalst certificaat met een verzonnen serienummer.

Microsoft heeft dit opgelost met hotfix KB 2960124. Wanneer deze functie is ingeschakeld, kan de online responder worden geconfigureerd om een ​​referentielijst bij te houden van alle serienummers die door de CA zijn uitgegeven. Met die lijst retourneert de responder ' ONBEKEND' in plaats van 'GOED' voor elk serienummer dat niet wordt herkend. Dit is een belangrijke beveiligingsverbetering die het gedrag in lijn brengt met de bedoeling van RFC 6960.

Het inschakelen van deze functie omvat de volgende stappen, die in de juiste volgorde moeten worden uitgevoerd. Op Windows Server 2016 en later zijn alleen stap 1 en 2 vereist, aangezien de hotfix al is geïntegreerd. Op Server 2008 R2 en 2012 R2 zijn alle drie de stappen vereist.

Als u meerdere online responders gebruikt, moeten deze worden georganiseerd in een OCSP-array. Een array is een logische groepering van online responders die dezelfde intrekkingsconfiguratie delen. Eén responder wordt aangewezen als de arraycontroller, waarvan de configuratie de gezaghebbende bron is. Alle andere leden synchroniseren hun instellingen hiermee. In deze configuratie moet de directory met serienummers op een netwerkshare worden geplaatst die toegankelijk is voor elk lid, in plaats van lokaal op één server te worden opgeslagen.

Stap 1: Maak de map voor serienummers aan.

Maak op de CA-server een map aan waarin lege bestanden worden opgeslagen, genoemd naar het serienummer van elk uitgegeven certificaat. Als u een OCSP-array met meerdere online responders gebruikt, plaatst u deze map op een netwerkshare zodat alle leden van de array er leesrechten op hebben. Als de map lokaal wordt gehost, moet u ervoor zorgen dat het OCSP-serviceaccount leesrechten heeft voor de map.

Sla het volgende script op als Certs.ps1 op de CA-server:

param( [ValidateScript({Test-Path $_})] [String] $Path ) pushd $Path dir | foreach { remove-item $_ -force } certutil.exe -out serialnumber -restrict "Disposition = 20" -view | foreach { if($_ -match 'Serienummer: "([^"]+)"') { New-Item -type File $matches[1] | out-null } } Popd

Voer het script uit met het mappad als parameter:

.\Certs.ps1 -Pad "C:\OCSPSerials"

Plan dit script zo in dat het regelmatig wordt uitgevoerd. Elke vier uur is een redelijk uitgangspunt; stem dit af op de frequentie waarmee u CRL's publiceert. Als het script te weinig wordt uitgevoerd, krijgt een certificaat dat na de laatste uitvoering is uitgegeven de status 'ONBEKEND' van de OCSP-responder tot de volgende uitvoering. Dit leidt tot validatiefouten voor recent geregistreerde certificaten.

Stap 2: Configureer het register op de OCSP-server.

Open de Register-editor en navigeer naar:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OcspSvc\Responder

Vouw de sleutel uit, klik op het knooppunt dat overeenkomt met de intrekkingsconfiguratie van uw CA en klik vervolgens met de rechtermuisknop op Provider. Selecteer Nieuw > Waarde met meerdere tekenreeksen, geef deze de naam IssuedSerialNumbersDirectories en stel de waarde in op het pad van de map die u in stap 1 hebt gemaakt. Gebruik voor netwerkshares de UNC-indeling: \\servernaam\sharenaam.

Start de OCSP-service opnieuw op nadat u de registerwijziging hebt opgeslagen.

Stap 3: Installeer de hotfix (alleen voor servers van vóór 2016)

Installeer de hotfix nu op Windows Server 2008 R2 of 2012 R2. De hotfix is ​​al geïntegreerd in Server 2016 en latere versies, maar stap 1 en 2 (het instellen van de serienummerdirectory en de registerconfiguratie) zijn nog steeds vereist voor alle versies.

Na configuratie retourneert elk OCSP-verzoek voor een serienummer dat niet in de referentiedirectory staat, ONBEKEND in plaats van GOED. U kunt dit controleren door OCSP-auditing in te schakelen en gebeurtenis-ID 5125 te bekijken; een onbekend serienummer registreert de status ONBEKEND, terwijl hetzelfde verzoek zonder deze configuratie GOED zou hebben geretourneerd.

Het intrekken van een licentie beheren met de lokale CRL

Er is een minder bekende functie van de Windows Online Responder die in specifieke situaties echt van belang kan zijn: bijvoorbeeld wanneer uw CA-database geen registratie bevat van een certificaat dat rechtmatig is uitgegeven, of wanneer u een serienummer als ingetrokken wilt markeren dat de CA zelf nooit heeft geregistreerd.

De online responder beheert zijn eigen interne lokale CRL, een lijst met serienummers die als ingetrokken worden beschouwd, onafhankelijk van de CRL die door uw certificeringsinstantie (CA) is gepubliceerd. Het is geen ondertekend CRL-bestand en vereist geen toegang tot de privésleutel van de CA, wat het juist zo nuttig maakt in situaties waarin de CA zelf niet kan optreden. Wanneer een client de OCSP-responder raadpleegt voor een serienummer dat in de lokale CRL voorkomt, retourneert de responder 'ingetrokken', ongeacht wat de door de CA uitgegeven CRL aangeeft.

Als uw certificeringsinstantie (CA) een storing heeft ondervonden en is hersteld vanuit een back-up, zullen alle certificaten die tussen de laatste back-up en de storing zijn uitgegeven, niet in de herstelde database aanwezig zijn. U kunt geen certificaten intrekken waarvan de CA niet weet dat ze zijn uitgegeven. Maar als u de serienummers kent uit logboeken, inschrijvingsgegevens of een andere bron, kunt u ze toevoegen aan de lokale CRL (Certificate Revocation List). De OCSP-responder zal dan onmiddellijk reageren met 'ingetrokken'. Dit is ook het mechanisme voor het afhandelen van frauduleuze certificaten waarvan u het serienummer kent, maar die nooit door de CA zijn uitgegeven.

Gebruik de lokale CRL bewust en verwijder de vermeldingen zodra de door de CA uitgegeven CRL de juiste intrekkingsstatus weergeeft. Bij array-implementaties moeten wijzigingen in de lokale CRL worden doorgevoerd op de arraycontroller. Wijzigingen die op een lidknooppunt worden aangebracht, worden overschreven tijdens de volgende synchronisatie met de controller.

OCSP-ondertekeningscertificaatvereisten volgens RFC 6960

Het ondertekeningscertificaat is wat OCSP-reacties betrouwbaar maakt. Clients accepteren een intrekkingsstatus niet zomaar. Ze controleren de handtekening op de reactie, valideren de certificaatketen en bevestigen dat de ondertekenaar gemachtigd is om namens de certificeringsinstantie te spreken die het gecontroleerde certificaat heeft uitgegeven. Als een van deze controles mislukt, wordt de reactie afgewezen.

Wie mag de antwoorden ondertekenen?

Volgens RFC 6960 kan een OCSP-antwoord worden ondertekend door een van de volgende drie entiteiten: de CA die het te controleren certificaat heeft uitgegeven, een Trusted Responder waarvan de publieke sleutel direct door de client wordt vertrouwd, of een CA Designated Responder met een speciaal gemarkeerd certificaat dat direct door de CA is uitgegeven. In Microsoft ADCS-omgevingen is het model met gedelegeerde responders de standaardimplementatie. De Online Responder gebruikt een speciaal OCSP Response Signing-certificaat met de id-kp-OCSPSigning EKU, en dit certificaat wordt doorgaans uitgegeven door dezelfde Issuing CA die het te valideren certificaat heeft uitgegeven.

RFC 6960 Sectie 4.2.2.2 heeft de vereisten voor responderautorisatie aangescherpt ten opzichte van RFC 2560: systemen die afhankelijk zijn van OCSP-reacties moeten een delegatiecertificaat alleen herkennen als zijnde uitgegeven door de CA die het betreffende certificaat heeft uitgegeven, indien het delegatiecertificaat en het certificaat dat wordt gecontroleerd op intrekking, met dezelfde sleutel zijn ondertekend. Hoewel RFC 6960 achterwaartse compatibiliteit behoudt, wordt het gebruik van een OCSP-ondertekeningscertificaat uitgegeven door een Root CA om reacties voor Issuing CA-certificaten te ondertekenen sterk afgeraden en wordt dit mogelijk niet geaccepteerd door strikt RFC 6960-compatibele clients. Elk sleutelpaar van een Issuing CA moet daarom een ​​eigen, specifiek OCSP-ondertekeningscertificaat hebben.

CA-vernieuwing en continuïteit van OCSP-ondertekeningscertificaten

Een veelvoorkomende vraag in omgevingen met meerdere certificeringsinstanties (CA's) is wat er gebeurt met het OCSP-vertrouwen wanneer een CA wordt vernieuwd met een nieuw sleutelpaar. Als RFC 6960 vereist dat het delegatiecertificaat is ondertekend met dezelfde sleutel als het certificaat dat wordt gecontroleerd, zorgt een CA-vernieuwing er dan voor dat bestaande OCSP-responderconfiguraties niet meer werken? In de praktijk is het antwoord voor Windows-omgevingen nee. Sectie 4.2.2.2 van RFC 6960 behoudt achterwaartse compatibiliteit met RFC 2560 en verbiedt het gebruik van een respondercertificaat dat is uitgegeven met een ander CA-sleutelpaar niet. Windows implementeert dit correct, waardoor een CA die is vernieuwd met een nieuw sleutelpaar gewoon blijft werken met een bestaande OCSP-responderconfiguratie zonder speciale aanpassingen.

Een instelling genaamd UseDefinedCACertInRequest wordt soms ingeschakeld om de OCSP-responder de mogelijkheid te geven te verzoeken dat het ondertekeningscertificaat wordt uitgegeven onder een specifiek CA-certificaat en sleutelpaar. Dit voegt operationele complexiteit toe zonder significant voordeel in de meeste Windows-omgevingen en is vooral relevant wanneer clients van derden strikt het autorisatiegedrag van de responder volgens RFC 6960 afdwingen. Compatibiliteitsvereisten moeten worden geëvalueerd op basis van de gebruikte clientplatformen voordat deze instelling wordt ingeschakeld.

De id-pkix-ocsp-nocheck-extensie

Er bestaat een logisch probleem met gedelegeerde OCSP-ondertekeningscertificaten: een client die een OCSP-antwoord valideert, zou de intrekkingsstatus van het ondertekeningscertificaat moeten controleren. Dit vereist een aparte OCSP-query, waardoor een circulaire afhankelijkheid ontstaat zonder duidelijke oplossing. RFC 6960 pakt dit aan met de extensie id-pkix-ocsp-nocheck. Wanneer deze extensie aanwezig is in het ondertekeningscertificaat, geeft dit OCSP-clients aan dat ze de responder gedurende de levensduur van het certificaat moeten vertrouwen en geen intrekkingscontrole hoeven uit te voeren. De extensie moet niet-kritiek zijn en de waarde ervan moet NULL zijn.

RFC 6960 merkt ook op dat een compromittering van de privésleutel van de responder net zo ernstig is als een compromittering van een CA-sleutel die wordt gebruikt om CRL's te ondertekenen, in ieder geval gedurende de geldigheidsperiode van dit certificaat. Daarom kiezen CA's er soms voor om deze certificaten met een korte geldigheidsduur uit te geven en ze regelmatig te vernieuwen . De ingebouwde OCSP Response Signing -certificaatsjabloon in Windows ADCS bevat deze extensie standaard. Als u deze sjabloon hebt gedupliceerd en extensies hebt verwijderd of gewijzigd, controleer dan of id-pkix-ocsp-nocheck nog steeds aanwezig is voordat u de implementatie uitvoert.

De vereiste EKU OID

Het ondertekeningscertificaat moet ook de OCSP Signing Extended Key Usage OID (EKU) bevatten: 1.3.6.1.5.5.7.3.9. Zonder deze OID zullen clients het certificaat niet herkennen als geautoriseerd om OCSP-reacties te ondertekenen. In Windows-omgevingen kan de inschrijving voor een OCSP-ondertekeningscertificaat mislukken met fouten zoals CERT_E_INVALID_POLICY als een CA in de certificaatketen expliciete EKU-beperkingen hanteert die OCSP Signing niet toestaan. Als uw PKI-hiërarchie expliciete EKU-beperkingen in CA-certificaten gebruikt, moet u ervoor zorgen dat de OCSP Signing EKU (1.3.6.1.5.5.7.3.9) waar nodig is toegestaan. Dit is een controle die u proactief moet uitvoeren tijdens het PKI-ontwerp, en niet pas na een incident.

OCSP voor offline en standalone CA's

In een standaard PKI-hiërarchie met twee niveaus is de root-CA offline en de uitgevende CA online. In de meeste praktijksituaties heeft de root-CA geen eigen OCSP-responder nodig. Root-CA-certificaten hebben een lange levensduur, worden zelden ingetrokken en worden rechtstreeks vertrouwd door de vertrouwensarchieven van clients in plaats van via OCSP-validatie. Intrekking op basis van CRL's is over het algemeen voldoende voor de root-CA.

Voor zelfstandige CA-omgevingen (CA's die niet zijn geïntegreerd met Active Directory) is automatische inschrijving niet beschikbaar. Certificaten voor het ondertekenen van OCSP-antwoorden moeten handmatig worden aangevraagd en vernieuwd, meestal met behulp van certreq.exe. Voordat u de aanvraag indient, moet u de bijbehorende vlag op de CA inschakelen met de volgende opdracht:

certutil -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

Start de CA-service opnieuw na het uitvoeren van deze opdracht. Zonder deze vlag ingeschakeld, zal de standalone CA de extensie id-pkix-ocsp-nocheck niet opnemen in het uitgegeven ondertekeningscertificaat. Hierdoor proberen clients de intrekking van het ondertekeningscertificaat zelf te controleren, wat mogelijk recursief validatiegedrag veroorzaakt. Omdat verlenging in standalone omgevingen niet geautomatiseerd is, is proactieve monitoring van de geldigheidsperiode van het OCSP-ondertekeningscertificaat essentieel om serviceonderbrekingen te voorkomen.

Checklist voor OCSP-infrastructuurbewaking: vereisten, storingsmodi en signalen

Gebruik deze tabel als operationele referentie voor OCSP-monitoring en driemaandelijkse evaluatie. Elke rij koppelt een kritieke OCSP-vereiste aan de bijbehorende validatiemethode, veelvoorkomende storingsmodus, monitoringsignaal en sturende bron.

Hoe encryptieconsultancy kan helpen

Het implementeren van OCSP in een bedrijfsomgeving omvat veel meer dan alleen het installeren van de Online Responder-rol en het publiceren van een URL. Implementaties in de praktijk vereisen zorgvuldige planning met betrekking tot het ontwerp van de responder, het beheer van ondertekeningscertificaten, de actualiteit van intrekkingen, schaalbaarheid, monitoring en interoperabiliteit tussen diverse clientplatformen. Configuratiefouten blijven vaak onopgemerkt totdat een storing in de certificaatvalidatie of een beveiligingsincident ze aan het licht brengt.

Bij Encryption Consulting werkt ons PKI Services- team samen met organisaties in de financiële sector, de gezondheidszorg, de overheid, de technologiesector, de detailhandel, de energiesector en vele andere sectoren om OCSP-infrastructuur te ontwerpen, implementeren en valideren die onder realistische omstandigheden presteert. We beoordelen de naleving van RFC 6960 binnen uw CA-hiërarchie, identificeren problemen met de OCSP-ondertekeningscertificaatketen voordat ze storingen veroorzaken en configureren alle instellingen volgens de beste praktijken in de branche en de eisen van uw organisatie.

Ons CertSecure Manager- platform vormt een aanvulling op de OCSP-infrastructuur door het beheer van de certificaatlevenscyclus te automatiseren en de zichtbaarheid in PKI-omgevingen binnen de onderneming te verbeteren. CertSecure Manager houdt de vervaldatum van OCSP-ondertekeningscertificaten bij en activeert vernieuwingsworkflows voordat het certificaat vervalt, bewaakt de status van OCSP-certificaten op TLS-servers, beheert de volledige certificaatinventaris waardoor intrekkingsbeslissingen controleerbaar zijn en integreert intrekkingsworkflows zodat gecompromitteerde certificaten direct worden gemarkeerd. Voor volledige cryptografische zichtbaarheid in alle omgevingen waar OCSP actief is, detecteert en inventariseert CBOM Secure de cryptografie waarop uw PKI vertrouwt, zodat verbeteringen aan de OCSP-infrastructuur niet in het blinde worden uitgevoerd.

Of u nu voor het eerst OCSP implementeert, een bestaande implementatie versterkt ter voorbereiding op een audit, of uw intrekkingsinfrastructuur voorbereidt op kortere certificaatlevensduren , ons team beschikt over de praktische ADCS- en multi-platform PKI-ervaring om u te helpen het goed te doen. Nu NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) in augustus 2024 heeft afgerond, moeten organisaties er ook voor zorgen dat hun OCSP-certificaathiërarchie is ontworpen met cryptografische flexibiliteit voor post-quantum algoritme-overgangen. Begin met de PQC-gereedheidsplanning via de PQC-gereedheidsbeoordeling en het PQC Center of Excellence.

Conclusie

OCSP speelt een cruciale rol bij het garanderen dat informatie over intrekking van certificaten in realtime kan worden gevalideerd in moderne PKI-omgevingen. Hoewel het protocol zelf eenvoudig is, vereist het beheren van een betrouwbare OCSP-infrastructuur zorgvuldige aandacht voor de configuratie van de responder, het vertrouwen in het ondertekeningscertificaat, de actualiteit van de intrekking, schaalbaarheid en het gedrag van de client in geval van storingen.

Verschillende geavanceerde configuratiegebieden hebben een directe impact op zowel de beveiliging als de operationele betrouwbaarheid. Deterministische responsverwerking via KB 2960124 zorgt ervoor dat de responder 'ONBEKEND' retourneert in plaats van 'GOED' voor serienummers die nooit door de CA zijn uitgegeven. Een correcte, RFC 6960-conforme configuratie van het ondertekeningscertificaat garandeert interoperabiliteit tussen verschillende platforms en clientimplementaties. Operationele controles zoals het bewaken van de actualiteit van de respons, het beheer van de verlenging van OCSP-ondertekeningscertificaten en het schalen van de responder worden steeds belangrijker naarmate het aantal certificaten toeneemt en de levensduur van certificaten steeds korter wordt.

OCSP-stapling verbetert zowel de privacy als de prestaties door het clientverkeer te verminderen en de TLS-handshakelatentie te minimaliseren, waardoor het een belangrijk onderdeel is van moderne webinfrastructuur. Uiteindelijk gaat een robuuste OCSP-implementatie niet alleen over het mogelijk maken van intrekkingcontroles; het gaat erom te garanderen dat intrekkingsinformatie accuraat, betrouwbaar, beschikbaar en operationeel duurzaam blijft onder realistische omstandigheden. Organisaties die investeren in een goed ontworpen en continu gemonitorde OCSP-infrastructuur verkleinen het risico op stille intrekkingsfouten aanzienlijk en versterken de algehele betrouwbaarheid van hun PKI-omgeving.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het artikel 'OCSP begrijpen en optimaliseren voor Enterprise PKI'?

OCSP is het realtime intrekkingscontrolemechanisme dat de kern vormt van moderne PKI, maar het blijft een van de meest inconsistent geïmplementeerde componenten in de certificaatinfrastructuur van bedrijven. Organisaties die de Online Responder installeren en een paar vakjes aanvinken, ontdekken vaak maanden later dat hun responder stilletjes fouten heeft geretourneerd, hun OCSP-ondertekeningscertificaat ongemerkt is verlopen of dat hun servers nooit reacties op TLS-handshakes hebben gestapeld. Een productieklare OCSP vereist een deterministische responsconfiguratie (KB 2960124), RFC 6960-compatibele ondertekeningscertificaten, proactieve monitoring van de geldigheid van de stapels en integratie met CLM-automatisering.

Waarom is de OCSP-configuratie belangrijk voor PKI-teams binnen een organisatie?

Enterprise PKI-teams zijn verantwoordelijk voor de intrekkingsinfrastructuur die het vertrouwen in certificaten waarborgt voor elke TLS-verbinding, geauthenticeerde workload en ondertekend artefact binnen de organisatie. Wanneer een OCSP-responder verkeerd geconfigureerd is, niet beschikbaar is of verouderde antwoorden geeft, wordt de intrekking niet betrouwbaar afgedwongen. Een ingetrokken certificaat van een gecompromitteerde sleutel kan succesvol blijven authenticeren totdat het verloopt. Volgens DigiCert's Trust Pulse Survey (2 juli 2025) heeft bijna de helft van alle bedrijven het afgelopen jaar te maken gehad met downtime als gevolg van certificaatproblemen; storingen in de OCSP-infrastructuur zijn hier een belangrijke oorzaak van.

Welke risico's nemen toe als OCSP handmatig wordt beheerd in een bedrijfs-PKI?

Handmatig OCSP-beheer verhoogt het risico op: het onopgemerkt verlopen van OCSP-ondertekeningscertificaten, waardoor alle intrekkingsreacties voor die CA tegelijkertijd mislukken; verouderde OCSP-reacties omdat de referentielijst met serienummers niet vaak genoeg wordt bijgewerkt; geen monitoring van de status van OCSP-staples, waardoor een verouderde staple zonder waarschuwing harde verbindingsfouten veroorzaakt; en het onvermogen om certificaten snel in te trekken tijdens een incident met een gecompromitteerde sleutel, omdat de intrekkingsinfrastructuur niet is getest of gedocumenteerd. Naarmate de geldigheidsperioden van certificaten afnemen tot 47 dagen onder CA/Browser Forum Ballot SC-081v3 (april 2025), neemt de operationele frequentie voor OCSP-beheer evenredig toe.

Welke teams moeten verantwoordelijk zijn voor de implementatie en monitoring van OCSP?

PKI-beheerders zijn verantwoordelijk voor de implementatie van de Online Responder, de levenscyclus van OCSP-ondertekeningscertificaten, het vernieuwen van de referentiedirectory voor serienummers (KB 2960124) en het beheer van lokale CRL's. Beveiligingsarchitecten zijn verantwoordelijk voor het autorisatiemodel van de responder, de nalevingsvereisten van RFC 6960 en het OCSP-staplingbeleid. Platform- en webserverteams zijn verantwoordelijk voor de OCSP-staplingconfiguratie op Apache, nginx, IIS en loadbalancers. Complianceteams zijn verantwoordelijk voor het auditbewijs dat de intrekkingcontrole wordt afgedwongen voor gereguleerde services. CISO's zijn verantwoordelijk voor het risicoprofiel voor de beschikbaarheid van de OCSP-infrastructuur als laatste controlepunt voor certificaatvertrouwen.

Hoe is OCSP gekoppeld aan certificaatlevenscyclusbeheer?

OCSP is de realtime-afdwingingslaag van PKI voor intrekking van certificaten; CLM is de operationele laag die ervoor zorgt dat certificaten correct worden uitgegeven, verlengd en ingetrokken voordat OCSP ook maar iets hoeft af te dwingen. CertSecure Manager vult de OCSP-infrastructuur aan door de vervaldatum van OCSP-ondertekeningscertificaten te volgen, de status van OCSP-certificaten op alle TLS-servers te bewaken, de basislijn voor certificaatinventaris te leveren die intrekkingsbeslissingen controleerbaar maakt, en intrekkingsworkflows te integreren zodat gecompromitteerde certificaten onmiddellijk aan de OCSP-laag worden gemeld.

Hoe moeten organisaties het succes van hun OCSP-infrastructuur meten?

Belangrijkste meetwaarden: beschikbaarheid van OCSP-responders als percentage van alle clientnetwerksegmenten (doel: minimaal 99.9%); percentage TLS-servers met Must-Staple-certificaten die op elk gegeven moment een geldige, niet-verlopen OCSP-staple presenteren (doel: 100%); resterende geldigheidsduur van OCSP-ondertekeningscertificaten continu bijgehouden met geautomatiseerde waarschuwingen na 30, 14 en 7 dagen; en gemiddelde tijd tussen intrekking van een certificaat door de CA en het moment dat de OCSP-responder de status 'Ingetrokken' retourneert (doel: binnen het CRL-verversingsinterval, doorgaans minder dan 4 uur bij publicatie van een CRL per uur).

Wat moet er regelmatig gecontroleerd of gemonitord worden voor de OCSP-infrastructuur?

Continue monitoring: HTTP-beschikbaarheid van de OCSP-responder vanuit alle clientnetwerksegmenten; geldigheid van het OCSP-ondertekeningscertificaat met automatische vervalwaarschuwingen; actualiteit van de OCSP-staple op alle TLS-servers waar stapling is ingeschakeld; voltooiing van de vernieuwing van de referentiedirectory voor serienummers (KB 2960124); en gebeurtenis-ID 5125 op de OCSP-server voor verzoeken met onbekende serienummers. Kwartaalcontrole: naleving van de RFC 6960-certificaatketen voor ondertekening; aanwezigheid van de id-pkix-ocsp-nocheck-extensie in alle OCSP-ondertekeningscertificaten; afstemming van de CRL-publicatiefrequentie met de nextUpdate-waarden van de OCSP-respons; en synchronisatiestatus van de OCSP Array Controller.

Welke invloed heeft OCSP op cloud-, hybride- of multi-CA PKI-omgevingen?

In cloud- en hybride omgevingen moeten OCSP-responders bereikbaar zijn vanuit alle netwerksegmenten waar TLS-clients certificaten valideren. Cloudworkloads in privé-VPC's of omgevingen met beperkte uitgaande verbindingen kunnen de OCSP-responder-URL van de CA, die in certificaten is ingebed, mogelijk niet bereiken. OCSP-stapling verhelpt dit door de responderquery naar de serverzijde te verplaatsen, maar vereist wel dat de TLS-server zelf uitgaande toegang heeft tot de responder. In omgevingen met meerdere CA's moet elk uitgevend CA-sleutelpaar een eigen, specifiek OCSP-ondertekeningscertificaat hebben, conform RFC 6960 Sectie 4.2.2.2. CBOM Secure biedt inzicht in de inventaris van alle CA-bronnen, zodat geen enkel OCSP-ondertekeningscertificaat ongemerkt verloopt binnen een gedistribueerde CA-hiërarchie.

Welke veelgemaakte fouten moeten teams vermijden bij de implementatie van OCSP?

De meest voorkomende fouten: het niet inschakelen van de deterministische GOOD-responsconfiguratie (KB 2960124), waardoor vervalste serienummers de OCSP-validatie kunnen doorstaan; het gebruiken van een OCSP-ondertekeningscertificaat uitgegeven door een Root CA om responsen voor Issuing CA-certificaten te ondertekenen, wat in strijd is met RFC 6960 Sectie 4.2.2.2; het niet vaak genoeg inplannen van de vernieuwing van de referentiedirectory voor serienummers, waardoor recent geregistreerde certificaten UNKNOWN retourneren; het inschakelen van OCSP-stapling op de server, maar het niet bewaken van de geldigheid van de staple, wat leidt tot harde verbindingsfouten wanneer de staple verloopt; en het niet opnemen van OCSP-ondertekeningscertificaten in de CLM-vernieuwingsautomatisering, waardoor ze ongecontroleerd verlopen.

Welke voorwaarden zijn vereist voordat de Windows Online Responder kan worden geïmplementeerd?

De vereisten omvatten: een actieve ADCS Issuing CA met geconfigureerde CRL-publicatie; Windows Server 2016 of later voor de Online Responder-rol (aanbevolen); een OCSP Response Signing-certificaatsjabloon met id-kp-OCSPSigning EKU (OID 1.3.6.1.5.5.7.3.9) en id-pkix-ocsp-nocheck-extensie; het OCSP Responder-serviceaccount met toegang tot de CRL en (voor KB 2960124) de referentiedirectory voor serienummers; en een AIA-extensie die is geconfigureerd in de certificaatsjabloon van de Issuing CA en die verwijst naar de OCSP Responder-URL voordat er certificaten worden uitgegeven.

Wat moet er elk kwartaal worden vernieuwd aan de OCSP-infrastructuur van een onderneming?

Driemaandelijks bijwerken: controle van de geldigheid van het OCSP-ondertekeningscertificaat en planning van de verlenging indien de vervaldatum binnen 90 dagen ligt; afstemming van het updateschema van de referentiedirectory voor serienummers (KB 2960124) op de publicatiefrequentie van CRL's; controle van de configuratie van de OCSP Array Controller om te bevestigen dat alle leden gesynchroniseerd zijn; beschikbaarheidstesten van de OCSP-responder vanuit alle relevante clientnetwerksegmenten; en PQC-gereedheidscontrole via het PQC Center of Excellence voor de planning van de migratie van de NIST FIPS 203-, 204- en 205-algoritmen, aangezien OCSP-ondertekeningscertificaten opnieuw moeten worden uitgegeven tijdens de PKI-hiërarchie PQC-migratie.