Inzicht in en optimalisatie van OCSP voor Enterprise PKI

Introductie

A certificaatintrekking Een systeem 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 het certificaat vertrouwt, laat weten dat ze het niet langer hoeven te vertrouwen. certificaat Onmiddellijk. Maar intrekking werkt alleen als klanten de intrekkingsservice daadwerkelijk kunnen bereiken, een nieuw antwoord ontvangen en daar correct op kunnen 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.

Wat is OCSP en waarom is het belangrijk?

Het Online Certificate Status Protocol, gedefinieerd in RFC 6960, biedt clients een mechanisme om in realtime de intrekkingsstatus van een specifiek certificaat op te vragen. In tegenstelling tot Lijsten met ingetrokken certificaten (CRL's)Waar OCSP vereist dat een client een volledige lijst met ondertekende certificaten downloadt en lokaal analyseert, staat het een gerichte query toe: "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:

• GoedDeze status geeft aan dat het certificaat als geldig wordt beschouwd en momenteel niet is ingetrokken. Het betekent in ieder geval dat het serienummer niet is gevonden in de CRL die door de responder is gebruikt. Het bevestigt echter niet dat het certificaat ooit is uitgegeven. Bovendien kan, zonder deterministische responsconfiguratie (KB 2960124), zelfs een niet-bestaand of verzonnen serienummer een "Goed"-status opleveren.
• IngetrokkenDeze status geeft aan dat het certificaat niet langer geldig is vanwege intrekking en wordt door clients doorgaans beschouwd als een harde fout. Intrekking kan tijdelijk zijn (bijvoorbeeld wanneer de reden voor intrekking 'certificateHold' is) of permanent. In sommige gevallen staat RFC 6960 ook toe dat deze status wordt geretourneerd voor een certificaatserienummer dat nooit daadwerkelijk door de CA is uitgegeven. In dergelijke gevallen is het de bedoeling dat de client het certificaat afwijst in plaats van te proberen een andere bron van statusinformatie, zoals een CRL, op te vragen. Dit gedrag is optioneel en wordt gebruikt in specifieke implementaties. Voor achterwaartse compatibiliteit met RFC 2560 kunnen responders als alternatief 'onbekend' retourneren voor niet-uitgegeven serienummers. Wanneer 'ingetrokken' wordt gebruikt voor niet-uitgegeven certificaten, vereist RFC 6960 de opname van de uitgebreide definitie van 'ingetrokken' en specifieke gestandaardiseerde antwoordvelden.
• OnbekendDe 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 waarvoor deze responder is geconfigureerd.

De reactie 'Onbekend' is een van de meest verkeerd begrepen statussen in OCSP. Het is niet gelijk aan IngetrokkenHet geeft eerder aan dat de respondent de status van het certificaat niet kan vaststellen. Het gedrag van de client varieert: veel implementaties behandelen dit op verschillende manieren. Onbekend Ofwel worden OCSP-fouten als een soft-fail beschouwd en wordt de verbinding voortgezet, terwijl andere configuraties hard-fail-beleid afdwingen.

Deze variabiliteit 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 die een PKI biedt 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.

Stap 1: Certificaatuitreiking

Tijdens een TLS-handshake presenteert de server zijn certificaat aan de client. Het certificaat bevat een Autoriteit Informatie Toegang (AIA) Een 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-controle of, in implementaties met een harde fout, de verbinding volledig weigeren. In Windows ADCS stelt de online responder het veld nextUpdate in zijn antwoorden 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-nieten op hun plaats:

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 speciale artikelen hierover lezen. Inleiding tot OCSP-nieten en Levensduur van OCSP-nietjes en certificaten.

De Windows Online Responder configureren: Geavanceerde instellingen

Het implementeren van de Windows Online Responder-rol is relatief eenvoudig, maar om deze correct te configureren voor een PKI-productieomgeving is een dieper inzicht nodig 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. Daardoor ontdekken organisaties vaak pas tekortkomingen nadat ze interoperabiliteitsproblemen, verouderde reacties, vertrouwensproblemen met responders of onverwacht validatiegedrag tegenkomen. De volgende paragrafen behandelen verschillende geavanceerde OCSP-configuratiegebieden in Windows ADCS die aanzienlijke operationele en beveiligingsimplicaties hebben in de praktijk.

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. CRL Het registreert alleen wat is ingetrokken; het heeft geen kennis van wat rechtmatig is uitgegeven. De respondent kan, uitsluitend op basis van de CRL, dus 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 kan de responder een antwoord retourneren. ONBEKEND dan GOED voor elk serienummer dat het niet herkent. 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.

Het exportproces voor serienummers aan de CA-zijde, zoals beschreven in KB 2960124, is nog steeds vereist aan de kant van de uitgevende CA. Dit proces haalt de serienummers van uitgegeven certificaten uit de CA-database en publiceert deze naar de OCSP-omgeving. Zonder deze continu bijgewerkte dataset beschikt de responder niet over een referentielijst en kan hij geen onderscheid maken tussen een legitiem en een vervalst serienummer. Deterministisch gedrag, waarbij UNKNOWN in plaats van GOOD wordt geretourneerd voor onbekende serienummers, werkt zonder deze referentielijst niet.

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 het af op uw... CRL Publicatiefrequentie. 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

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 belangrijk kan zijn: wanneer uw CA-database Het systeem heeft geen registratie van een certificaat dat rechtmatig is uitgegeven, of van een situatie waarin je een serienummer als ingetrokken moet markeren, terwijl de certificeringsinstantie dit zelf nooit heeft bijgehouden.

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 Recognition List), waarna de OCSP-responder onmiddellijk zal reageren met 'REVOKED'. Dit is tevens het mechanisme voor het afhandelen van ingetrokken certificaten. schurk Of frauduleuze certificaten waarvan je het serienummer kent, maar die nooit door de certificeringsinstantie 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 certificeringsinstantie (CA) die het gecontroleerde certificaat heeft uitgegeven, een vertrouwde responder wiens publieke sleutel rechtstreeks door de client wordt vertrouwd, of een door de CA aangewezen responder – een gedelegeerde responder die een speciaal gemarkeerd certificaat bezit dat rechtstreeks door de CA is uitgegeven. Clients vertrouwen OCSP-antwoorden niet blindelings; ze valideren de handtekening van het antwoord, bouwen de certificaatketen van de ondertekenaar op en verifiëren deze, en bevestigen dat de ondertekenaar gemachtigd is om informatie over de intrekkingsstatus van het opgevraagde certificaat te verstrekken.

In Microsoft ADCS-omgevingen is het model met gedelegeerde responders de standaardimplementatie. De online responder gebruikt een speciaal OCSP-antwoordondertekeningscertificaat met de uitgebreide sleutelgebruikssleutel (EKU) id-kp-OCSPSigning. Dit certificaat wordt doorgaans uitgegeven door dezelfde certificeringsinstantie (CA) die het te valideren certificaat heeft uitgegeven. Certificaten uitgegeven door CA1 moeten bijvoorbeeld worden gevalideerd met OCSP-antwoorden die zijn ondertekend met een OCSP-ondertekeningscertificaat dat ook is uitgegeven door CA1, in plaats van door de root-CA of een andere CA.

RFC 6960 Sectie 4.2.2.2 heeft de vereisten voor responderautorisatie aangescherpt ten opzichte van RFC 2560. Zoals de RFC stelt: "Systemen die afhankelijk zijn van OCSP-reacties MOETEN een delegatiecertificaat herkennen als zijnde uitgegeven door de CA die het betreffende certificaat heeft uitgegeven, maar alleen als het delegatiecertificaat en het certificaat dat wordt gecontroleerd op intrekking, zijn ondertekend met dezelfde sleutel." Wanneer aan deze voorwaarde niet wordt voldaan, zijn clients niet verplicht de responder als geautoriseerd te herkennen.

Hoewel RFC 6960 achterwaartse compatibiliteit waarborgt en alternatieve uitgiftesleutels voor een OCSP-ondertekeningscertificaat niet verbiedt, worden dergelijke configuraties sterk afgeraden en mogelijk niet geaccepteerd door strikt RFC 6960-compatibele clients. In de praktijk betekent dit dat het gebruik van een OCSP-ondertekeningscertificaat uitgegeven door een Root CA om reacties te ondertekenen voor certificaten uitgegeven door een Issuing CA kan leiden tot interoperabiliteits- of validatieproblemen, met name bij clients van derden of clients die niet van Microsoft zijn. Elk sleutelpaar van een Issuing CA moet daarom een ​​eigen, specifiek OCSP-ondertekeningscertificaat hebben.

CA-vernieuwing en continuïteit van OCSP-ondertekeningscertificaten

Een verwante vraag die vaak opduikt in omgevingen met meerdere CA's is wat er gebeurt met het OCSP-vertrouwen wanneer een CA wordt vernieuwd met een nieuw sleutelpaar. Deze bezorgdheid is begrijpelijk. Als RFC 6960 vereist dat het delegatiecertificaat is ondertekend met dezelfde sleutel als het certificaat dat wordt gecontroleerd, wat gebeurt er dan met het OCSP-vertrouwen wanneer een CA wordt vernieuwd met een nieuw sleutelpaar? CA-verlenging Bestaande OCSP-responderconfiguraties verbreken?

In de praktijk is het antwoord voor Windows-omgevingen nee. RFC 6960 Sectie 4.2.2.2 behoudt achterwaartse compatibiliteit met RFC 2560 en verbiedt het gebruik van een respondercertificaat dat is uitgegeven met een ander CA-sleutelpaar niet. De RFC merkt echter op dat een dergelijke praktijk sterk wordt afgeraden, aangezien clients niet verplicht zijn een responder met een dergelijk certificaat als een geautoriseerde responder te herkennen. Windows implementeert dit correct, waardoor een CA die is vernieuwd met een nieuw sleutelpaar blijft werken met een bestaande OCSP-responderconfiguratie zonder speciale tussenkomst.

Het is belangrijk om dit te weten, omdat in ADCS-omgevingen soms een instelling genaamd UseDefinedCACertInRequest is ingeschakeld. Hiermee kan de OCSP-responder een verzoek indienen om het ondertekeningscertificaat te laten uitgeven onder een specifiek CA-certificaat en sleutelpaar, in plaats van automatisch het nieuwste vernieuwingssleutelpaar van de CA te gebruiken. Dit voegt operationele complexiteit toe zonder significant voordeel in de meeste Windows-omgevingen en is vooral relevant wanneer clients van derden of validatiebibliotheken het autorisatiegedrag van de responder volgens RFC 6960 strikt afdwingen. Compatibiliteitsvereisten moeten worden geëvalueerd op basis van de gebruikte clientplatformen voordat deze instelling wordt ingeschakeld.

De id-pkix-ocsp-nocheck-extensie

Er is een logisch probleem met gedelegeerde OCSP-ondertekeningscertificaten: een client die een OCSP-antwoord valideert, zou de intrekkingsstatus van het ondertekeningscertificaat moeten controleren, wat een aparte OCSP-query vereist, die op zijn beurt weer de intrekkingsstatus van het ondertekeningscertificaat van die respondent zou moeten controleren, waardoor een circulaire afhankelijkheid ontstaat zonder duidelijke oplossing.

RFC 6960 behandelt dit met de id-pkix-ocsp-nocheck-extensie. Wanneer deze extensie aanwezig is in het ondertekeningscertificaat, geeft dit OCSP-clients aan dat ze de responder gedurende de geldigheidsduur van het certificaat moeten vertrouwen en geen intrekkingscontrole op het certificaat mogen uitvoeren. De extensie moet niet-kritiek zijn en de waarde ervan moet NULL zijn.

RFC 6960 merkt ook op dat certificeringsinstanties (CA's) die een dergelijk certificaat uitgeven, zich ervan bewust moeten zijn dat een compromittering van de privésleutel van de respondent net zo ernstig is als een compromittering van een CA-sleutel die gebruikt wordt om CRL's te ondertekenen, in ieder geval gedurende de geldigheidsperiode van dit certificaat. Daarom kunnen CA's ervoor kiezen om deze certificaten met een korte geldigheidsduur uit te geven. vernieuwen ze vaak.

De ingebouwde OCSP-reactieondertekening De 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 sjabloon implementeert.

De vereiste EKU OID

Het ondertekeningscertificaat moet ook de OCSP Signing extended key usage OID bevatten: 1.3.6.1.5.5.7.3.9. Zonder deze OID zullen clients het certificaat niet herkennen als bevoegd 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 afdwingt die OCSP-ondertekening niet toestaan. Dit probleem doet zich niet voor wanneer CA-certificaten de standaardconfiguratie "Alle toepassingsbeleidsregels" gebruiken, die geen EKU-beperkingen oplegt.

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 tijdens het PKI-ontwerp moet uitvoeren, en niet pas na een incident.

OCSP voor offline en standalone CA's

In een standaard tweelaagse PKI In deze hiërarchie is de root-CA offline en de uitgevende CA online. Een vraag die vaak terugkomt bij ADCS-ontwerpbeoordelingen is of de root-CA een eigen OCSP-responder nodig heeft.

In de meeste praktijksituaties is dat niet het geval. 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 van de root-CA op basis van CRL is over het algemeen voldoende.

Voor de uitgevende CA hoeft de OCSP-responder niet op dezelfde server als de CA te worden gehost. Een dedicated Windows Server met de rol 'Online Responder' kan als OCSP-responder fungeren door de CRL van de uitgevende CA te importeren en antwoorden te ondertekenen met een gedelegeerd OCSP-ondertekeningscertificaat.

Voor standalone CA-omgevingen (d.w.z. CA's die niet zijn geïntegreerd met Active Directory) is automatische inschrijving niet beschikbaar. Hierdoor moeten OCSP Response Signing-certificaten handmatig worden aangevraagd en vernieuwd, doorgaans met behulp van tools zoals certreq.exe. De certificaataanvraag moet worden samengesteld met een INF-configuratiebestand dat expliciet zowel de OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) als de id-pkix-ocsp-nocheck-extensie bevat. Op een standalone CA is de id-pkix-ocsp-nocheck-extensie standaard niet opgenomen in uitgegeven certificaten. Voordat u de aanvraag indient, moet u de bijbehorende vlag op de CA inschakelen met behulp van 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 zullen clients proberen 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 OCSP-ondertekening noodzakelijk. geldigheidsperiode van het certificaat is essentieel om verstoring van de dienstverlening te voorkomen.

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 zijn onze PKI-diensten Ons team werkt samen met organisaties in de financiële dienstverlening, gezondheidszorg, overheid, technologie, detailhandel, energie 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.

Bovendien helpt ons CertSecure Manager-platform bij het automatiseren van processen. Beheer van de levenscyclus van certificaten en de zichtbaarheid in PKI-omgevingen binnen de onderneming te verbeteren, waardoor de operationele kosten worden verlaagd en tegelijkertijd het certificaatbeheer en de paraatheid voor intrekking worden versterkt.

Of u nu voor het eerst OCSP implementeert, een bestaande implementatie versterkt ter voorbereiding op een audit, of uw intrekkingsinfrastructuur voorbereidt op kortere certificaatlevensduurOns team beschikt over de praktische ADCS- en multi-platform PKI-ervaring om u te helpen het goed te doen.

Neem contact op met ons team via [e-mail beveiligd] om aan de slag te gaan.

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.

Zoals deze handleiding heeft aangetoond, hebben verschillende geavanceerde configuratiegebieden een directe impact op zowel de beveiliging als de operationele betrouwbaarheid. Deterministische responsverwerking 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 verder door het clientverkeer te verminderen en de TLS-handshakelatentie te minimaliseren, waardoor het een belangrijk onderdeel is van de moderne webinfrastructuur.

Uiteindelijk draait een robuuste OCSP-implementatie niet alleen om het mogelijk maken van intrekkingscontroles; 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.