Förstå och optimera OCSP för Enterprise PKI

Beskrivning

A återkallelse av certifikat ett system är bara så starkt som den infrastruktur som upprätthåller det. När en privat nyckel komprometteras eller ett certifikat utfärdas felaktigt är återkallelse en viktig försvarslinje. Det är den mekanism som säger till varje förlitande part i din miljö att sluta lita på den. certifikat omedelbart. Men återkallelse fungerar bara när klienter faktiskt kan nå återkallningstjänsten, få ett nytt svar och agera korrekt utifrån det.

Online Certificate Status Protocol (OCSP) är realtidskontrollmekanismen för återkallelse som ligger i hjärtat av modern PKI. Trots sin kritiska roll är OCSP fortfarande en av de mest inkonsekvent distribuerade och dåligt förstådda komponenterna i företagscertifikatinfrastruktur. Organisationer installerar Online Responder-rollen, kryssar i några rutor och antar att jobbet är klart. Månader senare upptäcker de att deras OCSP-responder i tysthet har returnerat fel, att deras signeringscertifikat har löpt ut utan att någon märkt det, eller att deras servrar aldrig häftade OCSP-svar till TLS-handskakningar.

Den här guiden täcker hela OCSP-konfigurationen: vad OCSP är, hur det fungerar på protokollnivå, hur man konfigurerar det på de plattformar som din organisation kör och vilka avancerade inställningar som skiljer en distribution i produktionsklass från en installation med kryssrutor.

Vad är OCSP och varför är det viktigt

Online Certificate Status Protocol, definierat i RFC 6960, tillhandahåller en mekanism för klienter att fråga om återkallningsstatusen för ett specifikt certifikat i realtid. Listor över återkallade certifikat (CRL:er)), som kräver att en klient laddar ner en hel signerad lista och analyserar den lokalt, tillåter OCSP en riktad fråga: "Har certifikatet med serienummer X, utfärdat av CA Y, återkallats?"

OCSP-respondern, som kan hanteras av CA själv eller delegeras till en separat server, returnerar ett av tre svar:

• braDenna status indikerar att certifikatet anses giltigt och för närvarande inte återkallat. Som ett minimum betyder det att serienumret inte hittades i den CRL som användes av svararen. Det bekräftar dock inte att certifikatet någonsin utfärdades. Dessutom, utan deterministisk svarskonfiguration (KB 2960124), kan även ett icke-existerande eller fabricerat serienummer returnera statusen "Bra".
• återkallatsDenna status indikerar att certifikatet inte längre är giltigt på grund av återkallelse och behandlas vanligtvis av klienter som ett "hard fail"-tillstånd. Återkallelse kan vara tillfällig (till exempel när återkallningsorsaken är certificateHold) eller permanent. I vissa fall tillåter RFC 6960 även att denna status returneras för ett certifikatserienummer som aldrig faktiskt utfärdats av CA. I sådana fall är avsikten att säkerställa att klienten avvisar certifikatet snarare än att försöka fråga en annan källa till statusinformation, till exempel en CRL. Detta beteende är valfritt och används i specifika implementeringar. För bakåtkompatibilitet med RFC 2560 kan svarare alternativt returnera "okänt" för icke-utfärdade serienummer. När "återkallat" används för icke-utfärdade certifikat kräver RFC 6960 att den utökade definitionstillägget för återkallade och specifika standardiserade svarsfält inkluderas.
• OkändSvararen kan inte fastställa certifikatets status, antingen för att serienumret är okänt eller för att certifikatet inte utfärdades av den certifikatutfärdare som denna svarare är konfigurerad för.

Det okända svaret är ett av de mest missförstådda tillstånden i OCSP. Det är inte likvärdigt med återkallats; snarare indikerar det att svararen inte kan avgöra certifikatets status. Klientbeteendet varierar: många implementeringar behandlar Okänd eller OCSP-fel som ett mjukt fel och fortsätta med anslutningen, medan andra kan konfigureras för att tillämpa principer för hårda fel.

Denna variation kan medföra risker i miljöer som är beroende av strikta återkallningskontroller. Om OCSP-infrastrukturen inte är tillgänglig, felkonfigurerad eller levererar inaktuella svar, kan återkallelsen eventuellt inte verkställas på ett tillförlitligt sätt. I sådana fall försvagas de garantier som en PKI ger, och det finns en risk att certifikat som inte längre borde vara giltiga, inklusive de som är associerade med komprometterade nycklar, litas på.

Så fungerar OCSP: Den fullständiga livscykeln för begäran och svar

Att förstå OCSP på protokollnivå är avgörande för effektiv konfiguration och meningsfull felsökning.

Steg 1: Certifikatpresentation

Under en TLS-handskakning presenterar servern sitt certifikat för klienten. Certifikatet innehåller en Åtkomst till myndighetsinformation (AIA) tillägg som anger URL:en för OCSP-svararen, till exempel http://ocsp.example.com. Om OCSP-häftning är aktiverat inkluderar servern ett förhämtat, cachat OCSP-svar direkt i handskakningen, vilket eliminerar behovet för klienten att kontakta svararen överhuvudtaget.

Steg 2: Konstruktion av OCSP-förfrågan

Klienten konstruerar en OCSP-begäran som innehåller utfärdarens namn-hash, utfärdarens publika nyckel-hash och serienumret på certifikatet som valideras. Dessa fält definieras i CertID-strukturen i RFC 6960 och hashas med hjälp av en digest-algoritm.

Steg 3: Begär överföring

OCSP-begäran skickas via HTTP till svars-URL:en som finns i certifikatets AIA-tillägg. OCSP använder vanligtvis HTTP (port 80) för prestanda och cachelagring. RFC 6960 definierar formatet för begäran, medan RFC 5019 tillhandahåller en lättviktsprofil optimerad för miljöer med hög volym.

Steg 4: Utvärdering av svarare

OCSP-svararen tar emot begäran och avgör certifikatets återkallningsstatus. Hur den hämtar dessa data beror på implementeringen. I Microsoft Windows ADCS-miljöer laddar onlinesvararen ner CRL:er från certifikatutfärdaren och använder dem för att avgöra återkallningsstatusen. I andra implementeringar, till exempel Keyfactor EJBCA, kan svararen fråga certifikatutfärdarens databas direkt eller visa förgenererade, cachade svar.

Steg 5: Signerat svar

Svarsgivaren returnerar ett digitalt signerat svar. Enligt RFC 6960 måste OCSP-signeringsnyckeln tillhöra en av tre auktoriserade parter: en CA som utfärdade det certifikat som kontrolleras, en betrodd svarsgivare vars publika nyckel är betrodd av klienten, eller en CA-utsedd svarsgivare som innehar ett särskilt markerat delegeringscertifikat utfärdat av den CA:n. Signaturen säkerställer att svaret inte kan manipuleras under överföring. Innan klienten litar på ett OCSP-svar måste den validera signaturen, verifiera signeringscertifikatets kedja och bekräfta svarsgivarens auktorisering.

Steg 6: Klientvalidering

Klienten verifierar signaturen på OCSP-svaret, kontrollerar giltighetstidsstämplarna för att bekräfta att svaret är aktuellt och använder den returnerade statusen för att avgöra om anslutningen ska fortsätta eller avslutas. RFC 6960 avsnitt 2.4 definierar fyra fält som styr svarets giltighet:

• denna uppdatering – Den senaste tidpunkten då svararen vet att den angivna statusen var korrekt.
• nästa uppdatering – Tidpunkten då eller före vilken nyare information kommer att finnas tillgänglig om certifikatets status.
• produceradAt – Tidpunkten då OCSP-svararen signerade detta svar.
• återkallelsetid – Tidpunkten då certifikatet återkallades eller spärrades. Finns endast i återkallade svar.

Fältet nextUpdate har direkta operativa konsekvenser. Om en svarare misslyckas med att uppdatera sina återkallningsdata innan nextUpdate har passerat, kommer klienterna att behandla svaret som inaktuellt. Beroende på deras konfiguration kommer de antingen att återgå till CRL-baserad kontroll eller, i hard-fail-distributioner, avvisa anslutningen helt. Specifikt på Windows ADCS ställer onlinesvararen automatiskt in fältet nextUpdate i sina svar så att det matchar utgångsdatumet för den CRL som den förbrukade. Det finns inget inbyggt konfigurationsalternativ för att åsidosätta detta. Det enda sättet att förkorta klientsidans OCSP-svarscachefönster i ADCS är att minska CRL:ns giltighetstid på den utfärdande CA:n.

OCSP-häftning: Uppgradering av prestanda och integritet

Traditionell OCSP har två anmärkningsvärda driftsproblem. För det första ökar den latensen för varje TLS-handskakning eftersom klienten måste göra en separat HTTP-förfrågan till OCSP-respondern innan anslutningen kan slutföras. För det andra skapar den en integritetsrisk eftersom OCSP-respondern kan korrelera klient-IP-adresser med certifikatsökningar, vilket i vissa reglerade miljöer ger upphov till efterlevnadsproblem enligt ramverk som HIPAA och GDPR.

OCSP-häftning åtgärdar båda problemen genom att flytta ansvaret för återkallningskontroll från klienten till servern. Det implementeras via TLS Certificate Status Request (status_request)-tillägget som definieras i avsnitt 8 i RFC 6066.

Med OCSP-häftning på plats:

1. Servern frågar regelbundet CA:s OCSP-responder om sitt eget certifikats återkallningsstatus.
2. Det signerade, tidsstämplade OCSP-svaret cachas av servern.
3. Under varje TLS-handskakning inkluderar servern detta cachade svar tillsammans med sitt certifikat.
4. Klienten får både certifikatet och dess återkallningsstatus i en enda tur och retur, utan att någon separat anslutning till CA krävs.

Eftersom OCSP-svaret är digitalt signerat av CA:s OCSP-responder kan en skadlig server inte förfalska eller ändra det. Klienten validerar fortfarande signaturen på det häftade svaret innan den litar på det, så säkerheten upprätthålls samtidigt som den extra tur- och returresan och integritetsrisken elimineras.

För en djupare titt på OCSP Stapling-konfiguration, prestandakonsekvenser och hur kortare certifikatlivslängder förändrar OCSP-frågevolymer, läs våra dedikerade artiklar om Introduktion till OCSP-häftning och OCSP-häftning och certifikatlivslängder.

Konfigurera Windows Online Responder: Avancerade inställningar

Att distribuera Windows Online Responder-rollen är relativt enkelt, men att konfigurera den korrekt för en produktions-PKI-miljö kräver en djupare förståelse för hur ADCS hanterar återkallningsdata, svarsauktorisering, signeringscertifikat och svarsvalidering.

Många av standardinställningarna är utformade för grundläggande funktioner snarare än strikt säkerhetsgaranti eller storskalig företagsverksamhet. Som ett resultat upptäcker organisationer ofta luckor först efter att ha stött på interoperabilitetsproblem, inaktuella svar, fel i svarsförtroendet eller oväntat valideringsbeteende. Följande avsnitt täcker flera avancerade OCSP-konfigurationsområden i Windows ADCS som har betydande operativa och säkerhetsmässiga konsekvenser i verkliga distributioner.

Deterministiska GOOD-svar och snabbkorrigering 2960124

Ett beteende som ofta förbises i ADCS-miljöer är hur Windows Online Responder utvärderar certifikatstatus som standard. Respondern förlitar sig främst på CRL-data för att fastställa återkallningsstatus. Om ett certifikatserienummer inte finns i CRL:n kan respondern därför anta att certifikatet är giltigt och returnera statusen BRA, även om certifikatet aldrig utfärdades av CA:n.

I praktiken innebär detta att ett förfalskat certifikat med ett fabricerat serienummer kan klara OCSP-validering. CRL registrerar bara vad som har återkallats; den har ingen kännedom om vad som legitimt utfärdades. Så svararen, som enbart arbetar från CRL, kan inte skilja ett riktigt utfärdat certifikat från ett förfalskat med ett påhittat serienummer.

Microsoft åtgärdade detta med snabbkorrigering KB 2960124. När den här funktionen är aktiverad kan onlinesvararen konfigureras för att underhålla en referenslista över alla serienummer som utfärdats av certifikatutfärdaren. Med den listan på plats returnerar svararen OKÄND snarare än BRA för alla serienummer som den inte känner igen. Detta är en betydande säkerhetsförbättring som bringar beteendet i linje med RFC 6960:s avsikt.

Att aktivera den här funktionen innebär följande steg, vilka måste utföras i ordning. På Windows Server 2016 och senare krävs endast steg 1 och 2 eftersom snabbkorrigeringen är förintegrerad. På Server 2008 R2 och 2012 R2 krävs alla tre steg.

Exportprocessen för serienummer på CA-sidan som refereras till i KB 2960124-vägledningen krävs fortfarande för den utfärdande CA:n. Denna process extraherar utfärdade certifikatserienummer från CA-databasen och publicerar dem i OCSP-miljön. Utan denna kontinuerligt uppdaterade datauppsättning har svararen ingen referenslista att arbeta utifrån och kan inte skilja ett giltigt serienummer från ett påhittat. Deterministiskt beteende, som returnerar OKÄND istället för BRA för okända serienummer, fungerar inte utan den.

Om du kör flera online-svarare bör de organiseras i en OCSP-array. En array är en logisk gruppering av online-svarare som delar samma återkallningskonfiguration. En svarare betecknas som arraykontroller, vars konfiguration är den auktoritativa källan. Alla andra medlemmar synkroniserar sina inställningar från den. I den här konfigurationen måste serienummerkatalogen placeras på en nätverksresurs som är tillgänglig för alla medlemmar, snarare än att lagras lokalt på en enda server.

Steg 1: Skapa serienummerkatalogen

Skapa en katalog på CA-servern där tomma filer, namngivna efter varje utfärdat certifikats serienummer, ska lagras. Om du kör en OCSP-array med flera online-svarare, placera den här katalogen på en nätverksresurs så att alla arraymedlemmar kan komma åt den med läsbehörighet. Om den finns lokalt, se till att OCSP-tjänstkontot har läsåtkomst till katalogen.

Spara följande skript som Certs.ps1 på CA-servern:

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

Kör skriptet med katalogsökvägen som parameter:

.\Certs.ps1 -Sökväg "C:\OCSPSerials"

Schemalägg det här skriptet så att det körs regelbundet. Var fjärde timme är en rimlig startpunkt; anpassa det till din CRL publiceringsfrekvens. Om skriptet körs för sällan kommer ett certifikat som utfärdats efter den senaste körningen att få OKÄNT från OCSP-respondern tills nästa körning, vilket orsakar valideringsfel för nyligen registrerade certifikat.

Steg 2: Konfigurera registret på OCSP-servern

Öppna Registereditorn och navigera till:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OcspSvc\Responder

Expandera nyckeln, klicka på noden som motsvarar din CA:s återkallningskonfiguration och högerklicka sedan på Provider. Välj Nytt > Flersträngsvärde, namnge det IssuedSerialNumbersDirectories och ange dess värde till sökvägen till katalogen du skapade i steg 1. För nätverksresurs, använd UNC-formatet: \\servernamn\resursnamn.

Starta om OCSP-tjänsten efter att du har sparat registerändringen.

Steg 3: Installera snabbkorrigeringen

Installera snabbkorrigeringen nu på Windows Server 2008 R2 eller 2012 R2. Snabbkorrigeringen är förintegrerad i Server 2016+, men steg 1 och 2 (installation av serienummerkatalog och registerkonfiguration) krävs fortfarande på alla versioner.

När den väl är konfigurerad kommer alla OCSP-förfrågningar för ett serienummer som inte finns i referenskatalogen att returnera OKÄNT snarare än BRA. Du kan verifiera detta genom att aktivera OCSP-granskning och kontrollera händelse-ID 5125; ett okänt serienummer loggar OKÄNT status, medan samma begäran utan denna konfiguration skulle ha returnerat BRA.

Hantera återkallelse med den lokala CRL:n

Det finns en mindre känd funktion i Windows Online Responder som blir verkligt viktig i specifika scenarier: när din CA-databas inte har någon registrering av ett certifikat som utfärdats på ett giltigt sätt, eller när du behöver markera ett serienummer som återkallat som certifikatutfärdaren själv aldrig spårade.

Online-svararen har sin egen interna lokala CRL, en lista över serienummer som den behandlar som återkallade, oberoende av den CRL som publiceras av din CA. Det är inte en signerad CRL-fil och kräver inte åtkomst till CA:ns privata nyckel, vilket är just det som gör den användbar i situationer där CA själv inte kan agera. När en klient frågar OCSP-svararen efter ett serienummer som visas i den lokala CRL:en returnerar svararen REVOKED, oavsett vad den CA-utfärdade CRL:en säger.

Om din CA drabbades av ett fel och återställdes från säkerhetskopia, kommer eventuella certifikat som utfärdats mellan den senaste säkerhetskopian och felet inte att finnas kvar i den återställda databasen. Du kan inte återkalla det som CA inte vet att den utfärdat. Men om du har kännedom om dessa serienummer från loggar, registreringsposter eller någon annan källa kan du lägga till dem i den lokala CRL:n, och OCSP-svararen kommer att svara REVOKED för dem omedelbart. Detta är också mekanismen för att hantera rogue eller bedrägliga certifikat där du känner till serienumret, men CA aldrig utfärdade dem.

Använd den lokala CRL-filen medvetet och rensa bort poster när den CA-utfärdade CRL-filen visar korrekt återkallningsstatus. För arraydistributioner måste ändringar i den lokala CRL-filen göras på array-styrenheten. Ändringar som görs i en medlemsnod kommer att skrivas över vid nästa synkronisering med styrenheten.

Krav för OCSP-signeringscertifikat enligt RFC 6960

Signeringscertifikatet är det som gör OCSP-svar tillförlitliga. Klienter accepterar inte blint återkallningsstatus. De verifierar signaturen på svaret, validerar signeringscertifikatets kedja och bekräftar att signeraren är behörig att tala för den certifikatutfärdare som utfärdade certifikatet som kontrolleras. Om något av detta misslyckas avvisas svaret.

Vem kan signera svar?

Enligt RFC 6960 kan ett OCSP-svar signeras av en av tre enheter: den CA som utfärdade det certifikat som kontrolleras, en betrodd svarare vars publika nyckel är direkt betrodd av klienten, eller en CA-designerad svarare – en delegerad svarare som innehar ett särskilt markerat certifikat som utfärdats direkt av CA:n. Klienter litar inte blint på OCSP-svar; de validerar svarssignaturen, bygger och verifierar signerarens certifikatkedja och bekräftar att signeraren är behörig att tillhandahålla information om återkallningsstatus för det certifikat som efterfrågas.

I Microsoft ADCS-miljöer är den delegerade svarsmodellen standardimplementeringen. Online-svararen använder ett dedikerat OCSP-svarssigneringscertifikat som innehåller id-kp-OCSPSigning Extended Key Usage (EKU), och detta certifikat utfärdas vanligtvis av samma utfärdande certifikatutfärdare som utfärdade certifikatet som valideras. Till exempel bör certifikat som utfärdas av utfärdande certifikatutfärdare1 valideras med hjälp av OCSP-svar som signerats med ett OCSP-signeringscertifikat som också utfärdats av utfärdande certifikatutfärdare1, snarare än av rot-certifikatutfärdaren eller en systerutfärdande certifikatutfärdare.

RFC 6960 avsnitt 4.2.2.2 stärkte kraven för svarsbehörighet jämfört med RFC 2560. Som RFC anger: ”System som förlitar sig på OCSP-svar MÅSTE endast känna igen ett delegeringscertifikat som utfärdat av den CA som utfärdade certifikatet i fråga om delegeringscertifikatet och det certifikat som kontrolleras för återkallelse signerades med samma nyckel.” När detta villkor inte är uppfyllt är klienter inte skyldiga att känna igen svarspersonen som auktoriserad.

Även om RFC 6960 bevarar bakåtkompatibilitet och inte förbjuder alternativa utfärdandenycklar för ett OCSP-signeringscertifikat, avråds sådana konfigurationer starkt och accepteras eventuellt inte av strikt RFC 6960-kompatibla klienter. I praktiken innebär detta att användning av ett OCSP-signeringscertifikat utfärdat av en rot-CA för att signera svar för certifikat utfärdade av en utfärdande CA kan leda till interoperabilitets- eller valideringsfel, särskilt med tredjepartsklienter eller klienter som inte är Microsoft-klienter. Varje nyckelpar för utfärdande CA bör därför ha sitt eget dedikerade OCSP-signeringscertifikat.

CA-förnyelse och OCSP-signeringscertifikatkontinuitet

En relaterad fråga som ofta dyker upp i miljöer med flera CA:er är vad som händer med OCSP-förtroendet när en CA förnyas med ett nytt nyckelpar. Oron är förståelig. Om RFC 6960 kräver att delegeringscertifikatet signeras med samma nyckel som det certifikat som kontrolleras, gör då en CA-förnyelse bryta befintliga OCSP-responderkonfigurationer?

I praktiken är svaret nej för Windows-miljöer. RFC 6960 avsnitt 4.2.2.2 bevarar bakåtkompatibilitet med RFC 2560 och förbjuder inte användningen av ett svarscertifikat som utfärdats under ett annat CA-nyckelpar. RFC noterar dock att en sådan praxis starkt avråds, eftersom klienter inte är skyldiga att känna igen en svarare med ett sådant certifikat som en auktoriserad svarare. Windows implementerar detta korrekt, så en CA som förnyas med ett nytt nyckelpar kommer att fortsätta arbeta med en befintlig OCSP-svararkonfiguration utan någon särskild åtgärd.

Detta är värt att känna till eftersom en inställning som heter UseDefinedCACertInRequest ibland aktiveras i ADCS-miljöer för att tillåta OCSP-respondern att begära att dess signeringscertifikat utfärdas under ett specifikt CA-certifikat och nyckelpar, snarare än att automatiskt använda CA:ns senaste förnyelsenyckelpar. Detta ökar driftskomplexiteten utan betydande fördelar i de flesta Windows-miljöer och är främst relevant där tredjepartsklienter eller valideringsbibliotek strikt tillämpar RFC 6960-responderauktoriseringsbeteendet. Kompatibilitetskrav bör utvärderas baserat på de klientplattformar som används innan denna inställning aktiveras.

Tillägget id-pkix-ocsp-nocheck

Det finns ett logiskt problem med delegerade OCSP-signeringscertifikat: en klient som validerar ett OCSP-svar skulle behöva kontrollera återkallningsstatusen för signeringscertifikatet, vilket skulle kräva en separat OCSP-fråga, som skulle kräva att man kontrollerar återkallningsstatusen för den svararens signeringscertifikat, vilket skapar ett cirkulärt beroende utan tydlig lösning.

RFC 6960 åtgärdar detta med tillägget id-pkix-ocsp-nocheck. När detta tillägg finns i signeringscertifikatet, informerar det OCSP-klienter att de ska lita på svararen under certifikatets livslängd och inte utföra återkallningskontroll på det. Tillägget ska vara icke-kritiskt och dess värde måste vara NULL.

RFC 6960 noterar också att CA:er som utfärdar ett sådant certifikat bör inse att en kompromettering av svararens privata nyckel är lika allvarlig som en kompromettering av en CA-nyckel som används för att signera CRL:er, åtminstone under certifikatets giltighetstid. Det är därför CA:er kan välja att utfärda dessa certifikat med korta livstider och förnya dem ofta.

Den inbyggda OCSP-svarssignering Certifikatmallen i Windows ADCS inkluderar detta tillägg som standard. Om du har duplicerat den här mallen och tagit bort eller ändrat tillägg, kontrollera att id-pkix-ocsp-nocheck fortfarande finns innan du distribuerar.

Det obligatoriska EKU OID:t

Signeringscertifikatet måste också innehålla OID:t för OCSP-signering med utökad nyckelanvändning: 1.3.6.1.5.5.7.3.9. Utan detta kommer klienter inte att känna igen certifikatet som behörigt att signera OCSP-svar.

I Windows-miljöer kan registrering för ett OCSP-signeringscertifikat misslyckas med fel som CERT_E_INVALID_POLICY om någon CA i certifikatkedjan tillämpar explicita EKU-begränsningar som inte tillåter OCSP-signering. Det här problemet uppstår inte när CA-certifikat använder standardkonfigurationen "Alla programpolicyer", som inte begränsar EKU:er.

Om din PKI-hierarki använder explicita EKU-begränsningar i CA-certifikat bör du se till att OCSP Signing EKU (1.3.6.1.5.5.7.3.9) är tillåten där så är lämpligt. Detta är en kontroll som är värd att göra proaktivt under PKI-designen, inte under en incident.

OCSP för offline- och fristående certifikatutfärdare

I en standard tvånivå-PKI hierarkin, rot-CA:n är offline och den utfärdande CA:n är online. En fråga som uppstår i många ADCS-designgranskningar är om rot-CA:n behöver sin egen OCSP-responder.

I de flesta praktiska implementeringar gör det inte det. Rot-CA-certifikat är långlivade, återkallas sällan och betrodda direkt av klientens förtroendelager snarare än genom OCSP-validering. CRL-baserad återkallelse för rot-CA:n är i allmänhet tillräcklig.

För den utfärdande certifikatutfärdaren behöver OCSP-svararen inte finnas på samma server som certifikatutfärdaren. En dedikerad Windows-server som kör rollen Online Responder kan fungera som OCSP-svarare genom att importera CRL:n från den utfärdande certifikatutfärdaren och signera svar med ett delegerat OCSP-signeringscertifikat.

För fristående CA-miljöer (dvs. CA:er som inte är integrerade med Active Directory) är automatisk registrering inte tillgänglig. Därför måste OCSP-svarssigneringscertifikat begäras och förnyas manuellt, vanligtvis med hjälp av verktyg som certreq.exe. Certifikatbegäran måste konstrueras med en INF-konfigurationsfil som uttryckligen inkluderar både OCSP-signerings-EKU (OID 1.3.6.1.5.5.7.3.9) och tillägget id-pkix-ocsp-nocheck. På en fristående CA ingår inte tillägget id-pkix-ocsp-nocheck som standard i utfärdade certifikat. Innan du skickar in begäran måste du aktivera motsvarande flagga på CA:n med följande kommando:

certutil -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

Starta om CA-tjänsten efter att du har kört det här kommandot. Utan den här flaggan aktiverad kommer den fristående CA:n inte att inkludera tillägget id-pkix-ocsp-nocheck i det utfärdade signeringscertifikatet, vilket kommer att få klienter att försöka återkallningskontroll av själva signeringscertifikatet och potentiellt skapa rekursiv validering.

Eftersom förnyelse inte automatiseras i fristående miljöer krävs proaktiv övervakning av OCSP-signeringen. certifikatets giltighetstid är avgörande för att undvika avbrott i tjänsten.

Hur krypteringskonsulting kan hjälpa

Att distribuera OCSP i en företagsmiljö innebär mycket mer än att installera Online Responder-rollen och publicera en URL. Verkliga implementeringar kräver noggrann planering kring responderdesign, hantering av signeringscertifikat, återkallelsers aktualitet, skalbarhet, övervakning och interoperabilitet mellan olika klientplattformar. Felkonfigurationer förblir ofta obemärkta tills ett certifikatvalideringsavbrott eller en säkerhetsincident exponerar dem.

På Encryption Consulting, vår PKI-tjänster Teamet arbetar med organisationer inom finansiella tjänster, hälso- och sjukvård, myndigheter, teknik, detaljhandel, energi och många fler sektorer för att designa, driftsätta och validera OCSP-infrastruktur som fungerar under verkliga förhållanden. Vi utvärderar RFC 6960-efterlevnad i hela er CA-hierarki, identifierar problem med OCSP-signeringscertifikatkedjan innan de orsakar avbrott och konfigurerar alla inställningar enligt branschens bästa praxis och organisationskrav.

Dessutom hjälper vår CertSecure Manager-plattform till att automatisera certifikatlivscykelhantering och förbättra synligheten i företags-PKI-miljöer, vilket minskar driftskostnaderna samtidigt som certifikatstyrningen och beredskapen för återkallelse stärks.

Oavsett om du driftsätter OCSP för första gången, härdar en befintlig implementering inför en granskning eller förbereder din återkallningsinfrastruktur för kortare certifikatlivslängder, vårt team har praktisk erfarenhet av ADCS och PKI för flera plattformar för att hjälpa dig att göra det rätt.

Kontakta vårt team på [e-postskyddad] att komma igång.

Slutsats

OCSP spelar en avgörande roll för att säkerställa att information om certifikatåterkallelse kan valideras i realtid i moderna PKI-miljöer. Även om själva protokollet är enkelt kräver drift av en tillförlitlig OCSP-infrastruktur noggrann uppmärksamhet på svararkonfiguration, förtroende för signeringscertifikat, återkallelsernas aktualitet, skalbarhet och klientbeteende under felförhållanden.

Som den här guiden visade har flera avancerade konfigurationsområden en direkt inverkan på både säkerhet och driftsäkerhet. Deterministisk svarshantering säkerställer att svararen returnerar OKÄND snarare än BRA för serienummer som aldrig utfärdats av CA. Korrekt RFC 6960-kompatibel konfiguration av signeringscertifikat säkerställer interoperabilitet mellan olika plattformar och klientimplementeringar. Driftkontroller som övervakning av svarsaktualitet, hantering av förnyelse av OCSP-signeringscertifikat och skalning av svarare blir allt viktigare i takt med att certifikatvolymerna växer och certifikatens livslängd fortsätter att förkortas.

OCSP-häftning förbättrar ytterligare både integritet och prestanda genom att minska klientsidans svarstrafik och minimera TLS-handskakningslatens, vilket gör det till en viktig komponent i modern webbinfrastruktur.

I slutändan handlar en robust OCSP-implementering inte bara om att möjliggöra kontroll av återkallelser; det handlar om att säkerställa att återkallningsinformationen förblir korrekt, tillförlitlig, tillgänglig och operativt hållbar under verkliga förhållanden. Organisationer som investerar i korrekt utformad och kontinuerligt övervakad OCSP-infrastruktur minskar risken för tysta återkallningsfel avsevärt och stärker den övergripande tillförlitligheten hos sin PKI-miljö.