OCSP mot en CRL: hur varje återkallningskontroll egentligen fungerar

En av dessa två återkallningskontroller returnerar ett signerat svar om ett enda certifikat, och den andra returnerar en signerad lista som du laddar ned i sin helhet. Båda ska tala om för en verifierare om en autentiseringsuppgift fortfarande är betrodd, och båda misslyckas på sätt som inte alls liknar varandra. Ordningen nedan följer det en operatör faktiskt möter i produktion, från byten på tråden till en gateway som nekar en anslutning. Att hoppa över ett steg är hur en driftsättning slutar med en återkallningspolicy som bara finns på papper.

Steg 1: Vad varje kontroll ger tillbaka och hur länge den förblir användbar

En CRL publiceras som ett signerat objekt som täcker varje certifikat en utfärdare har återkallat, så en verifierare hämtar den en gång och återanvänder den tills listans nextUpdate har passerat. Ett OCSP-svar är smalare: det svarar för exakt ett certifikat och bär thisUpdate, producedAt och vanligtvis även nextUpdate. Den skillnaden styr allt annat. En cachad CRL blir tyst inaktuell, eftersom filen fortfarande kan tolkas och dess signatur fortfarande verifieras, medan ett utgånget OCSP-svar uppenbart är värdelöst i samma stund du läser dess tidsstämplar.

Cachelagring är därför det första som måste fastställas: vilken komponent som håller kopian, och vilket tak den kopian lyder under. På en gateway bör taket vara nextUpdate minus en säkerhetsmarginal, aldrig vad ett HTTP-cachehuvud råkar föreslå. openssl crl -in issuer.crl -noout -lastupdate -nextupdate skriver ut båda datumen, och en lista vars nextUpdate redan ligger i det förflutna måste behandlas som saknad och inte bara som gammal.

Steg 2: Vart certifikatet pekar klienten

Lövcertifikatet bär vanligtvis två ledtrådar: ett CRL-distributionspunktstillägg och en post för auktoritetsinformationsåtkomst för OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints skriver ut den första, och den andra finns under AIA-avsnittet i openssl x509 -in client.pem -noout -text. Båda tilläggen är en pekare, inte en skyldighet. En klient som aldrig implementerar återkallningskontroll ansluter alldeles utmärkt till ett certifikat vars tillägg namnger en responder som varit död i ett år.

Distributionspunkter namnger ofta en intern värd som bara löses inom ett nätverkssegment, och vissa äldre klienter avvisar ldap-URL:er helt. Testa nåbarheten från värden som terminerar tunneln, inte från din egen bärbara dator, eftersom det är den enda synvinkel vars fel verkligen spelar roll.

Steg 3: Välj fail-closed eller fail-open före avbrottet

En otillgänglig responder eller en utgången lista tvingar fram ett beslut: neka anslutningen, eller acceptera den och registrera gapet. verify-underkommandot i OpenSSL gör det strikta valet explicit, eftersom att lägga till -crl_check förvandlar en otillgänglig CRL till unable to get certificate CRL och en misslyckad verifiering. Soft-fail i de flesta stackar är inte en flagga alls, det är frånvaron av kontrollen, och det är just därför den levereras av misstag.

För att se vilket beteende en klient egentligen har, ta bort respondern och anslut igen. Om tunneln ändå kommer upp, hitta loggraden som registrerade den överhoppade kontrollen, och fråga sedan om någon skulle läsa den raden under en incident. Samma leverantör kan skilja sig per protokoll, med en IKEv2-klient och en OpenVPN-klient på en maskin som läser orelaterade konfigurationsreglage.

Steg 4: Bevisa att kontrollen körs där trafik släpps in

Hitta processen som terminerar eller auktoriserar anslutningen, och fråga den om konfigurationsraden som aktiverar återkallningskontroll. En gateway som validerar kedjan men aldrig frågar om återkallning tillämpar en annan policy än den i din dokumentation, och ingen skärmbild av en certifikatkedja bevisar motsatsen. OpenVPN skriver alternativet som crl-verify; strongSwan håller CRL- och OCSP-sökningar under CA-konfigurationen, där crl_uris eller ocsp_uris sätts. Om du inte kan peka på någon av dem, anta att kontrollen saknas.

Ett OCSP-svar räknas bara när den utfärdande CA:n har signerat det, eller när en responder med OCSPSigning-tillägget för utökad nyckelanvändning, delegerat av den CA:n, har signerat det, så ett svar från en orelaterad tjänst bevisar ingenting. Om du själv kör respondern, övervaka den som ett hårt beroende, eftersom en enda död tjänst på en gång blir ett avbrott för varje fail-closed-klient.

Steg 5: Återkalla ett certifikat med avsikt

Ta ett testcertifikat, återkalla det genom samma kanal som produktionen använder, och fråga respondern direkt. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text bör rapportera Cert Status: revoked tillsammans med en återkallningstid, och ett good-svar betyder att din återkallning inte nådde respondern som dina klienter frågar. Kör sedan openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem för att se samma beslut via listvägen. Läs orsakssträngen i stället för utgångskoden, eftersom en återkallningsavvisning och ett kedjefel båda slutar i misslyckande.

Steget som verkligen spelar roll är det sista: anslut igen med den gamla profilen mot den verkliga tillämpningspunkten och bekräfta att avvisandet kommer från återkallningen. Anslut sedan igen med ett färskt, giltigt certifikat för att bevisa att du inte bara förstörde lyssnaren. Att radera profilen på klienten bevisar ingenting om serverns beslut, och det gör inte heller en lyckad openssl verify-körning på en maskin som aldrig terminerar en tunnel. RFC 6960 definierar vad ett konformt OCSP-svar innehåller, inklusive de statusvärden som detta test läser.