OCSP mot ein CRL: korleis kvar tilbakekallingssjekk eigentleg verkar

Ein av desse to tilbakekallingssjekkane returnerer eit signert svar om eitt einskild sertifikat, og den andre returnerer ei signert liste som du lastar ned i sin heilskap. Begge skal fortelje ein verifiserar om ein legitimasjon framleis er til å stole på, og begge feilar på måtar som slett ikkje liknar kvarandre. Rekkjefølgja nedanfor følgjer det ein operatør faktisk møter i produksjon, frå byta på tråden til ein gateway som avviser ei tilkopling. Å hoppe over eit trinn er måten ein utrulling endar opp med ein tilbakekallingspolicy som berre finst på papiret.

Trinn 1: Kva kvar sjekk gir tilbake, og kor lenge ho blir brukbar

Ein CRL blir publisert som eitt signert objekt som dekkjer kvart sertifikat ein utstedar har tilbakekalla, så ein verifiserar hentar han éin gong og brukar han på nytt til nextUpdate på lista er passert. Eit OCSP-svar er smalare: det svarar på nøyaktig eitt sertifikat og ber thisUpdate, producedAt og vanlegvis også nextUpdate. Den skilnaden styrer alt anna. Ein bufra CRL blir stille utdatert, fordi fila framleis kan parsast og signaturen framleis kan verifiserast, medan eit utløpt OCSP-svar openbert er verdlaust i det augeblikket du les tidsstempla.

Hurtiglagring er difor det første som må fastsetjast: kva komponent som held kopien, og kva tak den kopien følgjer. På ein gateway bør taket vere nextUpdate minus ein tryggleiksmargin, aldri det ein HTTP-bufferheader tilfeldigvis føreslår. openssl crl -in issuer.crl -noout -lastupdate -nextupdate skriv ut begge datoane, og ei liste der nextUpdate allereie ligg i fortida må handsamast som manglande og ikkje berre som gammal.

Trinn 2: Kvar sertifikatet peikar klienten

Bladsertifikatet ber vanlegvis to hint: ei CRL-distribusjonspunktutviding og ein oppføring for autoritetsinformasjonstilgang for OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints skriv ut den første, og den andre ligg under AIA-delen av openssl x509 -in client.pem -noout -text. Kvar av utvidingane er ein peikar, ikkje ei plikt. Ein klient som aldri implementerer tilbakekallingssjekk, koplar heilt fint til eit sertifikat der utvidingane namngir ein responder som har vore død i eitt år.

Distribusjonspunkt namngir ofte ein intern vert som berre blir løyst innanfor eitt nettverkssegment, og nokre eldre klientar avviser ldap-URL-ar heilt. Test rekkevidd frå verten som terminerer tunnelen, ikkje frå din eigen berbare, fordi det er det einaste synspunktet der feilen faktisk tel.

Trinn 3: Vel fail-closed eller fail-open før avbrotet

Ein utilgjengeleg responder eller ei utløpt liste tvingar fram ei avgjerd: avvis tilkoplinga, eller godta ho og registrer gapet. verify-underkommandoen i OpenSSL gjer det strenge valet eksplisitt, fordi å leggje til -crl_check gjer ein utilgjengeleg CRL til unable to get certificate CRL og ein mislukka verifisering. Soft-fail i dei fleste stakkar er ikkje eit flagg i det heile, det er fråværet av sjekken, og det er nettopp difor han blir levert ved ein feil.

For å sjå kva oppførsel ein klient eigentleg har, fjern responder-en og kople til på nytt. Om tunnelen framleis kjem opp, finn logglinja som registrerte den hoppande sjekken, og spør så om nokon ville lese den linja under ein hending. Same leverandør kan variere per protokoll, med ein IKEv2-klient og ein OpenVPN-klient på éin maskin som les ubeslekta konfigurasjonsbrytarar.

Trinn 4: Prov at sjekken køyrer der trafikk slepp inn

Finn prosessen som terminerer eller autoriserer tilkoplinga, og spør han om konfigurasjonslinja som slår på tilbakekallingssjekk. Ein gateway som validerer kjeda, men aldri spør om tilbakekalling, handhevar ein annan policy enn den i dokumentasjonen din, og ingen skjermbilete av ei sertifikatkjede provar det motsette. OpenVPN skriv alternativet som crl-verify; strongSwan held CRL- og OCSP-oppslag under CA-konfigurasjonen, der crl_uris eller ocsp_uris blir sette. Om du ikkje kan peike på nokon av dei, rekn med at sjekken manglar.

Eit OCSP-svar tel berre når den utstedande CA-en har signert det, eller når ein responder med OCSPSigning-utvidinga for utvida nøkkelbruk, delegert av den CA-en, har signert det, så eit svar frå ein urelatert teneste provar ingenting. Om du sjølv køyrer responder-en, overvak han som ein hard avhengnad, fordi éin død teneste på éin gong blir eit avbrot for kvar fail-closed-klient.

Trinn 5: Tilbakekall eitt sertifikat med vilje

Ta eit testsertifikat, tilbakekall det gjennom same kanal som produksjonen brukar, 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 saman med eit tilbakekallingstidspunkt, og eit good-svar betyr at tilbakekallinga di ikkje nådde responder-en klientane dine spør. Køyr deretter openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem for å sjå same avgjerd gjennom listeløpet. Les årsakstrengen i staden for utgangskoden, fordi ei tilbakekallingsavvising og ein kjedefeil endar begge i feil.

Trinnet som faktisk tel, er det siste: kople til på nytt med den gamle profilen mot det reelle handhevingspunktet og stadfest at avvisinga kjem frå tilbakekallinga. Kople deretter til på nytt med eit friskt, gyldig sertifikat for å prove at du ikkje berre øydela lyttaren. Å slette profilen på klienten provar ingenting om avgjerda til serveren, og det gjer heller ikkje ein vellukka openssl verify-køyring på ein maskin som aldri terminerer ein tunnel. RFC 6960 definerer kva eit konformt OCSP-svar inneheld, inkludert statusverdiane denne testen les.