OCSP mot en CRL: hvordan hver tilbakekallingssjekk egentlig virker

Én av disse to tilbakekallingssjekkene returnerer et signert svar om ett enkelt sertifikat, og den andre returnerer en signert liste som du laster ned i sin helhet. Begge skal fortelle en verifiserer om en legitimasjon fortsatt er til å stole på, og begge feiler på måter som slett ikke ligner hverandre. Rekkefølgen nedenfor følger det en operatør faktisk møter i produksjon, fra bytene på tråden til en gateway som avviser en tilkobling. Å hoppe over et trinn er måten en utrulling ender opp med en tilbakekallingspolicy som bare finnes på papiret.

Trinn 1: Hva hver sjekk gir tilbake, og hvor lenge den forblir brukbar

En CRL publiseres som ett signert objekt som dekker hvert sertifikat en utsteder har tilbakekalt, så en verifiserer henter den én gang og gjenbruker den til listens nextUpdate er passert. Et OCSP-svar er smalere: det svarer på nøyaktig ett sertifikat og bærer thisUpdate, producedAt og vanligvis også nextUpdate. Den forskjellen styrer alt annet. En bufret CRL blir stille utdatert, fordi filen fortsatt kan parses og signaturen fortsatt verifiseres, mens et utløpt OCSP-svar åpenbart er verdiløst i det øyeblikket du leser tidsstemplene.

Hurtiglagring er derfor det første som må fastsettes: hvilken komponent holder kopien, og hvilket tak den kopien følger. På en gateway bør taket være nextUpdate minus en sikkerhetsmargin, aldri det en HTTP-bufferheader tilfeldigvis foreslår. openssl crl -in issuer.crl -noout -lastupdate -nextupdate skriver ut begge datoene, og en liste hvis nextUpdate allerede er i fortiden må behandles som manglende og ikke bare som gammel.

Trinn 2: Hvor sertifikatet peker klienten hen

Bladsertifikatet bærer vanligvis to hint: en CRL-distribusjonspunktutvidelse og en oppføring for autoritetsinformasjonstilgang for OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints skriver ut den første, og den andre ligger under AIA-delen av openssl x509 -in client.pem -noout -text. Hver av utvidelsene er en peker, ikke en forpliktelse. En klient som aldri implementerer tilbakekallingssjekk, kobler helt fint til et sertifikat hvis utvidelser navngir en responder som har vært død i et år.

Distribusjonspunkter navngir ofte en intern vert som bare løses innenfor ett nettverkssegment, og noen eldre klienter avviser ldap-URL-er helt. Test rekkevidde fra verten som terminerer tunnelen, ikke fra din egen bærbare, fordi det er det eneste synspunktet hvis feil faktisk betyr noe.

Trinn 3: Velg fail-closed eller fail-open før avbruddet

En utilgjengelig responder eller en utløpt liste tvinger frem en beslutning: avvis tilkoblingen, eller godta den og registrer gapet. verify-underkommandoen i OpenSSL gjør det strenge valget eksplisitt, fordi å legge til -crl_check gjør en utilgjengelig CRL til unable to get certificate CRL og en mislykket verifisering. Soft-fail i de fleste stakker er ikke et flagg i det hele tatt, det er fraværet av sjekken, og det er nettopp derfor den leveres ved en feil.

For å se hvilken oppførsel en klient egentlig har, fjern responder-en og koble til på nytt. Hvis tunnelen fortsatt kommer opp, finn logglinjen som registrerte den hoppede sjekken, og spør så om noen ville lese den linjen under en hendelse. Samme leverandør kan variere per protokoll, med en IKEv2-klient og en OpenVPN-klient på én maskin som leser ubeslektede konfigurasjonsbrytere.

Trinn 4: Bevis at sjekken kjører der trafikk slipper inn

Finn prosessen som terminerer eller autoriserer tilkoblingen, og spør den om konfigurasjonslinjen som aktiverer tilbakekallingssjekk. En gateway som validerer kjeden, men aldri spør om tilbakekalling, håndhever en annen policy enn den i dokumentasjonen din, og ingen skjermbilde av en sertifikatkjede beviser det motsatte. OpenVPN skriver alternativet som crl-verify; strongSwan holder CRL- og OCSP-oppslag under CA-konfigurasjonen, der crl_uris eller ocsp_uris settes. Hvis du ikke kan peke på noen av dem, anta at sjekken mangler.

Et OCSP-svar teller bare når den utstedende CA har signert det, eller når en responder med OCSPSigning-utvidelsen for utvidet nøkkelbruk, delegert av den CA-en, har signert det, så et svar fra en urelatert tjeneste beviser ingenting. Hvis du selv kjører responder-en, overvåk den som en hard avhengighet, fordi én død tjeneste på én gang blir et avbrudd for hver fail-closed-klient.

Trinn 5: Tilbakekall ett sertifikat med vilje

Ta et testsertifikat, tilbakekall det gjennom samme kanal som produksjonen bruker, og spør responder-en direkte. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text bør rapportere Cert Status: revoked sammen med et tilbakekallingstidspunkt, og et good-svar betyr at tilbakekallingen din ikke nådde responder-en klientene dine spør. Kjør deretter openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem for å se samme beslutning gjennom listeløpet. Les årsakstrengen i stedet for utgangskoden, fordi en tilbakekallingsavvisning og en kjedefeil begge ender i feil.

Trinnet som faktisk betyr noe, er det siste: koble til på nytt med den gamle profilen mot det reelle håndhevelsespunktet og bekreft at avvisningen kommer fra tilbakekallingen. Koble deretter til på nytt med et frisk, gyldig sertifikat for å bevise at du ikke bare ødela lytteren. Å slette profilen på klienten beviser ingenting om serverens beslutning, og det gjør heller ikke en vellykket openssl verify-kjøring på en maskin som aldri terminerer en tunnel. RFC 6960 definerer hva et konformt OCSP-svar inneholder, inkludert statusverdiene denne testen leser.