OCSP versus CRL: kuidas kumbki tühistamiskontroll tegelikult töötab

Üks neist kahest tühistamiskontrollist tagastab ühe sertifikaadi kohta allkirjastatud vastuse ja teine tagastab allkirjastatud nimekirja, mille laadite tervikuna alla. Mõlemad peavad ütlema kontrollijale, kas mandaat on endiselt usaldusväärne, ja mõlemad nurjuvad viisidel, mis ei sarnane üldse. Alljärgnev järjekord järgib seda, millega operaator tootmises tegelikult kokku puutub, alustades võrgus liikuvatest baitidest ja lõpetades lüüsiga, mis ühenduse tagasi lükkab. Sammu vahelejätmine ongi see, kuidas juurutus jääb tühistamispoliitikaga, mis eksisteerib ainult paberil.

Samm 1: Mida kumbki kontroll tagastab ja kui kaua see kasutatav püsib

CRL avaldatakse ühe allkirjastatud objektina, mis katab iga sertifikaadi, mille väljaandja on tühistanud, seega kontrollija hangib selle üks kord ja kasutab uuesti, kuni nimekirja nextUpdate on möödunud. OCSP-vastus on kitsam: see vastab täpselt ühe sertifikaadi kohta ning kannab thisUpdate, producedAt ja tavaliselt ka nextUpdate. See erinevus määrab kõik muu. Vahemällu salvestatud CRL vananeb vaikselt, sest fail ikka parsitakse ja selle allkiri ikka valideeritakse, samas kui aegunud OCSP-vastus on ilmselgelt väärtusetu hetkel, mil loete selle ajatempleid.

Seega tuleb esimesena paika panna vahemällu salvestamine: milline komponent hoiab koopiat ja millisele ülempiirile see koopia allub. Lüüsil peaks ülempiiriks olema nextUpdate miinus turvamarginaal, mitte kunagi see, mida HTTP-vahemälu päis juhtumisi soovitab. openssl crl -in issuer.crl -noout -lastupdate -nextupdate prindib mõlemad kuupäevad ja nimekirja, mille nextUpdate on juba minevikus, tuleb käsitleda puuduva, mitte lihtsalt vanana.

Samm 2: Kuhu sertifikaat kliendi suunab

Lehtsertifikaat kannab tavaliselt kahte vihjet: CRL-i jaotuspunkti laiendust ja OCSP jaoks mõeldud asutuse teabejuurdepääsu kirjet. openssl x509 -in client.pem -noout -ext crlDistributionPoints prindib esimese ja teine asub openssl x509 -in client.pem -noout -text väljundi AIA jaotises. Kumbki laiendus on osuti, mitte kohustus. Klient, kes ei rakenda kunagi tühistamiskontrolli, ühendub täiesti hästi sertifikaadiga, mille laiendused nimetavad vastajat, kes on olnud surnud juba aasta.

Jaotuspunktid nimetavad sageli sisemist hosti, mis lahendatakse ainult ühe võrgusegmendi sees, ja mõned vanemad kliendid keelduvad ldap-URL-idest täielikult. Testige kättesaadavust hostist, mis tunnelit lõpetab, mitte oma sülearvutist, sest see on ainus vaatepunkt, mille tõrge tegelikult loeb.

Samm 3: Valige fail-closed või fail-open enne katkestust

Kättesaamatu vastaja või aegunud nimekiri sunnib otsustama: keelduda ühendusest või see vastu võtta ja lünk kirja panna. OpenSSL-i verify alamkäsk teeb range valiku selgesõnaliseks, sest -crl_check lisamine muudab kättesaamatu CRL-i unable to get certificate CRL-ks ja ebaõnnestunud valideerimiseks. Pehmelt nurjumine ei ole enamikus virnades üldse lipp, vaid kontrolli puudumine, ja just seetõttu jõuab see kogemata tootmisesse.

Et näha, milline käitumine kliendil tegelikult on, eemaldage vastaja ja ühenduge uuesti. Kui tunnel tõuseb ikkagi, leidke logirida, mis vahelejäetud kontrolli kirja pani, ja küsige siis, kas keegi seda rida intsidendi ajal loeks. Sama tarnija võib protokolliti erineda: IKEv2 klient ja OpenVPN klient samas masinas loevad omavahel sidumata konfiguratsiooninuppe.

Samm 4: Tõestage, et kontroll töötab seal, kus liiklus lubatakse

Leidke protsess, mis ühenduse lõpetab või volitab, ja küsige sellelt konfiguratsioonirida, mis tühistamiskontrolli lubab. Lüüs, mis valideerib ahela, kuid ei küsi kunagi tühistamise kohta, rakendab teistsugust poliitikat kui teie dokumentatsioonis, ja ükski sertifikaadiahela ekraanipilt ei tõesta vastupidist. OpenVPN kirjutab selle valiku kujul crl-verify; strongSwan hoiab CRL-i ja OCSP otsinguid CA konfiguratsiooni all, kus seatakse crl_uris või ocsp_uris. Kui te ei saa osutada kummalelegi, eeldage, et kontroll puudub.

OCSP-vastus loeb ainult siis, kui väljaandev CA on selle allkirjastanud, või kui selle on allkirjastanud vastaja, kellel on selle CA delegeeritud OCSPSigningi laiendatud võtmekasutus, seega seotud teenuse vastus ei tõesta midagi. Kui haldatega vastajat ise, jälgige seda kõva sõltuvusena, sest üks surnud teenus muutub korraga katkestuseks igale fail-closed kliendile.

Samm 5: Tühistage üks sertifikaat meelega

Võtke testsertifikaat, tühistage see sama kanali kaudu, mida tootmine kasutab, ja küsige vastajalt otse. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text peaks teatama Cert Status: revoked koos tühistamisajaga ja vastus good tähendab, et teie tühistamine ei jõudnud vastajani, kellelt teie kliendid küsivad. Seejärel käivitage openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, et näha sama otsust nimekirja teekonnal. Lugege põhjuse stringi, mitte väljumiskoodi, sest tühistamisest keeldumine ja ahela viga lõpevad mõlemad ebaõnnestumisega.

Samm, mis tõesti loeb, on viimane: ühenduge uuesti vana profiiliga tegeliku jõustamispunkti vastu ja kinnitage, et keeldumine tuleb tühistamisest. Seejärel ühenduge uuesti värske, kehtiva sertifikaadiga, et tõestada, et te lihtsalt ei rikkunud kuulajat. Profiili kustutamine kliendis ei tõesta serveri otsuse kohta midagi, ja seda ei tee ka edukas openssl verify käivitamine masinas, mis ei lõpeta kunagi tunnelit. RFC 6960 määratleb, mida ühilduv OCSP-vastus sisaldab, sealhulgas olekuväärtused, mida see test loeb.