OCSP:s magiska nummer

Online Certificate Status Protocol (OCSP) är en av de viktigaste komponenterna i en modern Public Key Infrastructure (PKI). Det ger klienter en snabb metod i realtid för att avgöra om ett certifikat fortfarande är tillförlitligt utan att ladda ner en hel lista över återkallade certifikat (CRL). I de flesta företagsmiljöer är effektivitet viktigt. Smartkortsautentisering, VPN-åtkomst, TLS-anslutningar, Wi-Fi-autentisering och arbetsflöden för enhetsregistrering är alla beroende av återkallelse av certifikat kontroller sker snabbt och tillförlitligt bakom kulisserna.

Begravt inuti Windows återkallningsmotor finns ett mindre känt beteende som i tysthet kan förändra hur certifikat Validering fungerar på ett klientsystem. PKI-experter hänvisar ofta till denna tröskel som OCSP Magic Number. När en Windows-klient cachar mer än ett visst antal OCSP-svar från samma svarare kan CryptoAPI sluta prioritera OCSP och börja föredra CRL:er istället. Som standard är den tröskeln bara 50 cachade OCSP-svar.

För vissa miljöer är detta beteende ofarligt och till och med fördelaktigt. För andra, särskilt organisationer som implementerat OCSP specifikt för att undvika stora CRL:er eller för att stödja deterministisk återkallningskontroll, kan det skapa drifts- och säkerhetsproblem som är extremt svåra att diagnostisera. Det som gör problemet särskilt utmanande är att övergången sker tyst. Själva OCSP-respondern förblir felfri, inga uppenbara fel visas i Windows händelseloggar och administratörer kanske inte har någon indikation på att klienter har ändrat återkallningsmetoder alls.

Att förstå OCSP:s magiska nummer kräver förståelse för hur Windows hanterar kontroll av certifikatåterkallelse bakom kulisserna. När du väl ser hur CryptoAPI väljer mellan OCSP och CRL:er blir många återkallningsbeteenden som verkar inkonsekventa eller oförutsägbara i företagsmiljöer med Active Directory Certificate Services (AD CS) mycket enklare att förklara och felsöka. Här är vad alla PKI-administratörer behöver veta om det.

Vad är OCSP?

Online Certificate Status Protocol (OCSP) standardiserades först i RFC 2560 år 1999 och uppdaterades senare till RFC 6960 i juni 2013, vilket fortfarande är den nuvarande standarden. Det ger förlitande parter ett sätt att kontrollera om ett specifikt X.509-certifikat har återkallats i realtid, utan att ladda ner en hel lista över återkallade certifikat (CRL).

Kärnskillnaden mellan de två är enkel. Certifikatåterkallningslista (CRL) är en regelbundet publicerad lista över alla certifikat som har återkallats medan de fortfarande var giltiga. CRL utfärdas av Certifikatmyndighet (CA) och laddas ner i sin helhet av klienter för validering. I stora företagsmiljöer kan CRL:er bli stora (från megabyte till mer), vilket ökar bandbreddsanvändningen och fördröjer återkallelsernas aktualitet till nästa publiceringscykel.

OCSP är däremot en förfrågningsbaserad mekanism som utför validering per certifikat. Klienten skickar en riktad förfrågan som innehåller utfärdarnamnets hash, utfärdarnyckelns hash och certifikatets serienummer till en OCSP-responder, som returnerar ett digitalt signerat, tidsstämplat svar som anger en av tre statusar: Bra, Återkallad eller Okänd. OCSP-svar är vanligtvis små (cirka ~2 KB), vilket gör dem betydligt effektivare när det gäller nätverksanvändning.

Detta gör OCSP betydligt effektivare än CRL-baserad återkallelse, särskilt i stora PKI-distributioner där CRL-storlekar skapar verkliga nätverks- och prestandaproblem. Det möjliggör också återkallningssvar i realtid som CRL:er helt enkelt inte kan tillhandahålla.

Vad är OCSP:s magiska tal?

När en Windows-klient utför en kontroll av återkallelse av certifikat och ett certifikat innehåller både en OCSP-URL och en CRL-URL, använder CryptoAPI inte bara OCSP varje gång. OCSP-URL:en publiceras i Åtkomst till myndighetsinformation (AIA) certifikattillägget, medan CRL-URL:en publiceras i CDP-tillägget. CryptoAPI utvärderar båda under återkallningskontrollen och fattar ett beslut baserat på hur många OCSP-svar som redan har cachats från den svararen för den CA:n.

Enligt Microsofts dokumentation I avsnittet ”Hur certifikatåterkallelse fungerar” beräknar CryptoAPI det totala antalet cachade OCSP-svar från en enda OCSP-svars-URL och jämför detta antal med ett fördefinierat tröskelvärde som kallas magic count. Som standard är tröskelvärdet satt till 50.

CryptoAPI tillämpar sedan tre regler baserat på det antalet. Om antalet är mindre än eller lika med det magiska antalet bearbetas OCSP-URL:erna i den ordning som anges av Authority Information Access-tillägget. Om antalet är större än det magiska antalet bearbetas CRL-URL:erna i den ordning som anges av CRL-distributionspunktstillägget. Och om ingen av OCSP-URL:erna i Authority Information Access-tillägget lyckas, återgår klienten till att använda CRL:er.

Det är också viktigt att förstå att det magiska talet inte är det enda villkoret som kan utlösa denna reservfunktion. Microsofts dokumentation identifierar en andra utlösare: en gruppolicy som explicit konfigurerats för att föredra CRL:er framför OCSP för återkallningskontroll. När den policyn är på plats återgår klienten till CRL oavsett hur många OCSP-svar som har cachas, vilket effektivt kringgår den räknebaserade logiken helt och hållet.

De två utlösarna är oberoende av varandra. Det magiska numret styr den automatiska reservfunktionen som sker baserat på cachevolym. Grupprincip styr den administrativa reservfunktionen som en organisation avsiktligt kan tillämpa. Båda resulterar i samma resultat: OCSP-frågor stoppas och CRL-kontroll tar över.

Varför Microsoft introducerade det

Det magiska numret är inte en bugg. Microsoft dokumenterade motiveringen tydligt, och den är rimlig i specifika scenarier.

Tänk dig en domänkontrollant som hanterar inloggningar med smartkort. Varje autentiseringshändelse utlöser en återkallningskontroll. Enligt Microsofts dokumentation är ett typiskt OCSP-svar ungefär 2 kB stort.

I ett scenario där tiotusentals användare, till exempel 50 000 användare, autentiserar sig via smartkort inom en enda återkallningsperiod, skulle dessa individuella svar ackumuleras till ungefär 100 MB cachade OCSP-svarsdata. En CRL som täcker samma poster skulle vara cirka 4 MB, baserat på uppskattningsvis 80 byte per post. I den skalan är det betydligt effektivare att ladda ner CRL:en en gång och återanvända den lokalt än att göra tiotusentals individuella OCSP-frågor.

Det magiska numret ger CryptoAPI ett sätt att göra den effektivitetsbestämningen automatiskt. När den cachade OCSP När svarsantalet överstiger tröskeln växlar klienten till CRL utan någon administratörsintervention. För miljöer med små CRL:er och höga certifikatvalideringsvolymer är detta en förnuftig inbyggd optimering.

Problemet är att det gäller universellt i alla Windows-miljöer, oavsett om den avvägningen är rimlig för en given distribution. Och när den aktiveras gör den det utan någon loggpost, varning eller synlig indikation på att återkallningsmekanismen har ändrats. Det är den osynligheten som förvandlar en rimlig optimering till en verklig drifts- och säkerhetsrisk, beroende på varför din organisation driftsatte OCSP från första början.

Varför detta är ett problem

Det är här det magiska numret slutar att vara en optimering och börjar bli en belastning. Dina OCSP-servrar fortsätter att se friska ut. De tar fortfarande emot frågor från klienter som ännu inte har passerat tröskeln. Ingenting på serversidan signalerar att vissa klienter har slutat använda det helt. Det finns två scenarier där denna reservlösning orsakar ett direkt säkerhetsfel eller driftstörningar.

Scenario 1: Stora CRL:er

Du driftsatte OCSP just för att din CRL hade blivit otymplig. Slutpunkterna fick timeout när de försökte ladda ner den. Återkallningskontroller misslyckades. Du skapade en OCSP-responder, uppdaterade din CA-konfiguration, testade allt och gick vidare. Sedan aktiverades det magiska numret. Windows-klienter återgår till att ladda ner samma CRL som du försökte komma ifrån. Du är tillbaka till timeouts och misslyckanden, utan någon indikation på vad som hände eller varför. Din OCSP-infrastruktur fungerar perfekt. Den används bara inte.

Scenario 2: Deterministiska svar och begränsningarna för CRL-reservfunktioner

Som standard returnerar Microsoft Online Responder GOOD för certifikatserienummer som inte visas i CRL:n. Microsoft Hotfix 2960124 åtgärdar detta genom att aktivera Online Responder att returnera deterministiska svar som kan skilja mellan legitimt utfärdade certifikat och förfalskade. När klienter återgår till CRL-kontroll försvinner det skyddet helt. Ett förfalskat certifikat med ett serienummer som inte finns i CRL:n kommer att klara valideringen utan problem.

Det som gör detta särskilt farligt är att Windows inte genererar en dedikerad händelse som indikerar att OCSP-cachegränsen har överskridits och att återkallningsinställningarna har ändrats. Det finns ingen händelse i Windows händelselogg och ingen varning på OCSP-respondern. Det enda sättet att upptäcka växeln är att titta på rå nätverkstrafik och lägga märke till att klienter har slutat skicka OCSP-förfrågningar och börjat hämta CRL:n.

Kombinationen av tyst växling och en välfungerande OCSP-infrastruktur innebär att organisationer kan arbeta under längre perioder i tron ​​att deras återkallningskontroll fungerar exakt som avsett, när i verkligheten en betydande del av deras kunder övergav OCSP för flera veckor sedan.

Hur cachen fungerar och vad Windows faktiskt räknar

När CryptoAPI hämtar och validerar ett OCSP-svar, ignoreras det inte. CryptoAPI lagrar svaret lokalt i en katalog som heter CryptnetUrlCache. För vanliga användarkonton finns denna cache på:

%ANVÄNDARPROFILE%\AppData\LocalLow\Microsoft\CryptnetUrlCache

För systemnivåtjänster, till exempel en domänkontrollant som bearbetar smartkortsinloggningar, lagras den på:

%WINDIR%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache

Varje gång ett giltigt OCSP-svar lagras här för en given kombination av svars-URL och CA, ökar CryptoAPI antalet som spåras mot det magiska taltröskelvärdet. Räkningen är inte global. Den spåras per användare, per OCSP-svars-URL och per CA. Det betyder att om en enda online-svarare betjänar två utfärdande CA:er, underhålls antalet oberoende för varje CA den betjänar. Att överskrida tröskeln för en CA har ingen effekt på antalet för den andra.

Denna spårning per användare, per certifikatutfärdare förklarar också ett beteende som verkligen förvirrar administratörer: två maskiner som utför identiska certifikatvalideringsarbetsbelastningar kan ha helt olika värden beroende på hur länge de har körts och hur många certifikat de har validerat. Den ena kan fortfarande fråga OCSP medan den andra redan har bytt till CRL, utan någon synlig konfigurationsskillnad mellan dem.

Räkningen varar inte i all oändlighet. Det är därför vissa team observerar problem med återkallningskontroll som verkar lösa sig själva efter en omstart; när maskinen startas om återupptas OCSP-frågor normalt tills tröskeln passeras igen. Att förstå denna cykel är viktigt, men att veta hur man fångar upp växlingen innan den orsakar skada är det som faktiskt skyddar din miljö.

Hur man upptäcker det

Eftersom Windows inte genererar någon loggpost och inte utlöser någon varning när det magiska numret utlöses, kräver detektering antingen proaktiv övervakning eller direkt inspektion.

Den mest tillförlitliga metoden är nätverkstrafikanalys. En klient som har passerat tröskeln kommer att sluta skicka förfrågningar till din OCSP-responder och börja göra HTTP GET-förfrågningar till din CRL distributionspunkt istället. Om du baslinjevärderar normal OCSP-frågevolym per klient och övervakar oväntade minskningar blir växeln detekterbar. Att observera en motsvarande topp i CRL-nedladdningstrafik från samma klient förstärker signalen.

På klientsidan kan du inspektera den aktuella registerkonfigurationen direkt. Det relevanta värdet är:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config\CryptnetCachedOcspSwitchToCrlCount

Om den här nyckeln inte finns på en given maskin gäller standardtröskelvärdet. Om det finns visar värdet vilket tröskelvärde som har konfigurerats. Att granska den här nyckeln i din miljö via grupprinciprapportering eller ett konfigurationshanteringsverktyg ger dig en tydlig bild av om det magiska numret har ställts in korrekt på dina klienter.

För djupare undersökning kan CAPI2-diagnostikloggning aktiveras på Windows-klienter för att fånga detaljerad aktivitet för certifikatkedjebyggande och återkallningskontroll. Även om CAPI2 inte loggar själva den magiska sifferväxlingen, loggar den vilken återkallningsmetod som användes för varje certifikatvalidering. Ett mönster av CRL-baserade valideringar på en klient som borde använda OCSP är en stark indikator på att tröskeln har passerats. När du har bekräftat det, eller vill förhindra att det händer från första början, är konfigurationsändringen enkel.

Hur man konfigurerar det magiska numret

Det finns två sätt att ändra tröskelvärdet för magiska tal: via grupprincip, vilket är den rekommenderade metoden för domänanslutna miljöer, eller direkt via registret för enskilda maskiner eller teständamål.

1. Via grupprincip

Navigera till följande sökväg i redigeraren för grupprinciphantering:

Datorkonfiguration > Windows-inställningar > Säkerhetsinställningar > Principer för offentliga nycklar > Inställningar för validering av certifikatsökväg

Under fliken Återkallelse letar du upp alternativet "Föredra CRL framför OCSP-svar om antalet cachade OCSP-svar som motsvarar samma CRL-distributionspunkt är större än". Ställ in detta till ett värde som återspeglar din förväntade certifikatvalideringsvolym.

När den här principen tillämpas skapar Windows följande registervärde automatiskt:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config\CryptnetCachedOcspSwitchToCrlCount

2. Via registret

Om grupprincip inte är tillgänglig kan du skapa eller ändra DWORD-värdet CryptnetCachedOcspSwitchToCrlCount direkt i samma registersökväg. Detta är lämpligt för enskilda maskiner eller laboratorietester, men grupprincip är fortfarande den rekommenderade metoden för bred distribution.

Två viktiga anmärkningar:

Det finns inget sätt att stänga av den räknarbaserade reservfunktionen enbart genom denna registerinställning. Att ställa in CryptnetCachedOcspSwitchToCrlCount till 0 inaktiverar inte reservfunktionen; det återställer helt enkelt standardtröskeln på 50. Organisationer som behöver inaktivera OCSP-hämtning helt måste använda Options DWORD med flaggan CERT_CHAIN_OPTION_DISABLE_AIA_URL_RETRIEVAL (0x2) vid samma registersökväg. För de flesta miljöer är det dock den praktiska metoden att sätta tröskeln tillräckligt högt så att den aldrig nås under maximala valideringsvolymer.

Det finns inte heller något universellt korrekt värde. Rätt tröskelvärde beror helt på dina certifikatvalideringsvolymer. En RADIUS-server som validerar VPN-certifikat kommer att ha helt andra krav än en domänkontrollant som bearbetar smartkortsinloggningar. Granska din miljö först, förstå dina högsta valideringsvolymer per system och sätt tröskelvärdet baserat på vad du faktiskt observerar snarare än ett godtyckligt antal. Den granskningen kräver insyn i din fullständiga återkallningsarkitektur, och det är där rätt expertis gör skillnaden.

Hur krypteringskonsulting kan hjälpa

OCSP:s magiska nummer är den typ av konfigurationsgap som sällan dyker upp förrän något går sönder. De flesta organisationer upptäcker det genom ett fel i återkallelsen, ett resultat av en säkerhetsrevision eller en nätverksavbildning som avslöjar att deras kunder i tysthet har övergett OCSP. Vid den tidpunkten har exponeringsfönstret redan varit öppet ett tag. Att identifiera och korrigera det proaktivt kräver att man vet att det existerar, vet var man ska leta och förstår hur det interagerar med resten av er återkallningsarkitektur.

Det är precis det arbete vårt team gör. På Encryption Consulting arbetar vårt PKI-tjänsteteam med organisationer inom finansiella tjänster, hälso- och sjukvård, myndigheter och teknik för att utvärdera, designa och validera återkallningsinfrastruktur som håller under verkliga förhållanden. Vi erbjuder både professionella tjänster och vår automatiseringsplattform (CertSecure Manager) för att säkerställa att er PKI är säker, motståndskraftig och framtidsklar.

PKI-tjänster

Krypteringskonsulttjänster PKI-tjänster täcka hela engagemangslivscykeln, från initial omfattning till driftsättning och långsiktig support. Varje fas är strukturerad kring din miljö, dina regulatoriska krav och din operativa verklighet.

• Projekt planering

Vi utvärderar er kryptografiska miljö, granskar PKI-konfigurationer, beroenden och krav, och sammanställer resultaten i en strukturerad, kundgodkänd projektplan.

• CP/CPS-utveckling

I nästa fas utvecklar vi certifikatpolicyn (CP) och certifieringspraxisutlåtandet (CPS) i linje med RFC#3647. Dessa dokument är anpassade till din organisations regelverk, säkerhetskrav och operativa krav.

• PKI-design och implementering

Vi designar och driftsätter robusta PKI-infrastrukturer med offline rot-CA, utfärdande CA:er, NDES-servrar, integration med HSM:er etc., beroende på kundens behov. Leveranserna inkluderar PKI-designdokument, byggguider, ceremoniskript och systemkonfigurationer. När driftsättningen är klar genomför vi grundliga tester, validering, finjusteringar och kunskapsöverföringssessioner för att stärka ditt team.

• Företagets kontinuitet och katastrofåterställning

Efter driftsättningen utvecklar och implementerar vi strategier för affärskontinuitet och katastrofåterställning, genomför redundantester och dokumenterar operativa arbetsflöden för hela PKI- och HSM-infrastrukturen, med stöd av en omfattande PKI-driftsguide.

• Löpande support och underhåll (valfritt)

Efter implementeringen erbjuder vi ett prenumerationsbaserat årligt supportpaket som ger omfattande täckning för PKI-, CLM- och HSM-komponenter. Detta inkluderar incidenthantering, felsökning, systemoptimering, hantering av certifikatlivscykeln, CP/CPS-uppdateringar, nyckelarkivering, uppgraderingar av HSM-firmware, granskningsloggning och patchhantering.

Denna metod säkerställer att din PKI-infrastruktur inte bara är säker och kompatibel, utan också skalbar, robust och helt i linje med dina långsiktiga operativa och regulatoriska mål.

Vår lösning för hantering av certifikatlivscykeln: CertSecure Manager

CertSecure Manager från Encryption Consulting är en lösning för hantering av certifikatlivscykeln som förenklar och automatiserar hela livscykeln, så att du kan fokusera på säkerhet snarare än förnyelser.

CertSecure Manager från Encryption Consulting är en lösning för hantering av certifikatlivscykeln som centraliserar identifiering, automatisering, registrering, policytillämpning och integrationer i hela din PKI-miljö. Den förhindrar avbrott med automatiserade förnyelser, förbättrar efterlevnaden och förenar hanteringen av offentliga och privata certifikatutfärdare genom en enda, skalbar plattform. Några av de viktigaste funktionerna i CertSecure Manager inkluderar:

• Automatisering för kortlivade certifikat: Med ACME- och 90-dagars/47-dagars TLS-certifikat som blir standard är manuell förnyelse inte längre ett praktiskt alternativ. CertSecure Manager automatiserar registrering, förnyelse och driftsättning för att säkerställa att certifikat aldrig går ut obemärkt.
• Sömlös DevOps- och molnintegration: Certifikat kan tillhandahållas direkt till webbservrar och molninstanser, och de integreras med moderna loggverktyg som Datadog, Splunk, ITSM-verktyg som ServiceNow och DevOps-verktyg som Terraform och Ansible.
• Stöd för flera CA: Många organisationer använder flera CA:er (interna Microsoft CA, publika CA:er som DigiCert och GlobalSign, etc.). CertSecure Manager integreras mellan dessa källor och ger en enda överblick över utfärdande och livscykelhantering.
• Enhetliga utgivnings- och förnyelsepolicyer: CertSecure Manager tillämpar din organisations nyckelstorlekar, algoritmer och förnyelseregler konsekvent över alla certifikat, inte bara automatiserar förnyelser med flera certifikatutfärdare, utan säkerställer också att varje certifikat uppfyller dina säkerhetsstandarder varje gång.
• Proaktiv övervakning och förnyelsetestning: Kontinuerlig övervakning, i kombination med simulerade förnyelse-/utgångstester, säkerställer att du identifierar risker innan certifikat påverkar produktionssystemen.
• Centraliserad synlighet och efterlevnad: En konsoliderad instrumentpanel visar alla certifikat, nyckellängder, starka och svaga algoritmer samt deras utgångsdatum. Granskningsspår och policytillämpning förenklar efterlevnaden av PCI DSS, HIPAA och andra ramverk.

If you’re still wondering where and how to get started with securing your PKI, Encryption Consulting is here to support you with its PKI Support Services. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise. Reach out to us at [e-postskyddad] att komma igång.

Slutsats

OCSP Magic Number är ett av de där Microsoft PKI-beteendena som bara dyker upp vid felsökning, men orsaken bakom det är enkel. Det som inte är enkelt är att diagnostisera det. Ingen händelseloggpost. Ingen varning. Ingen indikation på OCSP-respondern. Bara en tyst switch som gör att din återkallningsinfrastruktur fungerar perfekt medan dina klienter redan har gått vidare. Det enda sättet att ligga steget före är att känna din miljö tillräckligt väl för att konfigurera den avsiktligt, innan tröskeln konfigurerar sig själv åt dig.

Microsoft skapade detta beteende medvetet. CryptoAPI är utformat för att dynamiskt avgöra om OCSP eller CRL:er ger den effektivaste återkallningsmekanismen under rådande cacheförhållanden. Den magiska tröskeln för antal är helt enkelt den brytpunkt som används för att fatta det beslutet. Att förstå detta beteende är viktigt för alla som hanterar PKI-miljöer för företag, särskilt de som involverar storskaliga autentiseringssystem.

Om din organisation implementerade OCSP specifikt för att hantera stora CRL:er eller för att framtvinga deterministisk återkallningskontroll, är det magiska numret inte en implementeringsdetalj. Det är en konfiguration som måste hanteras aktivt. Känn till din CRL-storlek, känn till dina maximala certifikatvalideringsvolymer på kritiska system och sätt tröskelvärdet medvetet baserat på dina krav snarare än att acceptera en standard som är utformad för en annan miljö än den du arbetar i.