OCSP pret CRL: kā patiesībā darbojas katra atsaukšanas pārbaude

Viena no šīm divām atsaukšanas pārbaudēm atgriež parakstītu atbildi par vienu sertifikātu, bet otra atgriež parakstītu sarakstu, ko lejupielādējat pilnībā. Abām jāpasaka pārbaudītājam, vai akreditācija joprojām ir uzticama, un abas neizdodas tā, ka tās nemaz nelīdzinās viena otrai. Tālāk dotā secība seko tam, ar ko operators ražošanā patiešām saskaras, sākot no baitiem tīklā un beidzot ar vārteju, kas atsaka savienojumu. Soļa izlaišana ir tieši tas ceļš, kā izvietošana paliek ar atsaukšanas politiku, kas pastāv tikai uz papīra.

1. solis: Ko katra pārbaude atgriež un cik ilgi tā paliek lietojama

CRL tiek publicēts kā viens parakstīts objekts, kas aptver katru sertifikātu, ko izdevējs ir atsaucis, tāpēc pārbaudītājs to paņem vienreiz un izmanto atkārtoti, līdz saraksta nextUpdate ir pagājis. OCSP atbilde ir šaurāka: tā atbild tieši par vienu sertifikātu un satur thisUpdate, producedAt un parasti arī nextUpdate. Šī atšķirība nosaka visu pārējo. Kešotais CRL klusi noveco, jo fails joprojām tiek parsēts un tā paraksts joprojām tiek pārbaudīts, bet novecojusi OCSP atbilde acīmredzami ir bezvērtīga tajā brīdī, kad izlasāt tās laika zīmogus.

Tāpēc kešošana ir pirmā lieta, kas jānosaka: kura komponente tur kopiju un kādam griestam šī kopija pakļaujas. Vārtejā griestiem jābūt nextUpdate mīnus drošības rezerve, nekad ne tas, ko nejauši ierosina HTTP keša galvene. openssl crl -in issuer.crl -noout -lastupdate -nextupdate izdrukā abus datumus, un saraksts, kura nextUpdate jau ir pagātnē, jāuzskata par trūkstošu, nevis vienkārši vecu.

2. solis: Kur sertifikāts novirza klientu

Lapas sertifikāts parasti satur divus norādījumus: CRL izplatīšanas punkta paplašinājumu un iestādes informācijas piekļuves ierakstu OCSP vajadzībām. openssl x509 -in client.pem -noout -ext crlDistributionPoints izdrukā pirmo, un otrais atrodas openssl x509 -in client.pem -noout -text izvades AIA sadaļā. Jebkurš paplašinājums ir rādītājs, nevis pienākums. Klients, kas nekad neievieš atsaukšanas pārbaudi, lieliski savienosies ar sertifikātu, kura paplašinājumi nosauc atbildētāju, kas miris jau gadu.

Izplatīšanas punkti bieži nosauc iekšēju resursdatoru, kas atrisinās tikai vienā tīkla segmentā, un daži vecāki klienti ldap URL atsaka pilnībā. Pārbaudiet sasniedzamību no resursdatora, kas izbeidz tuneli, nevis no sava portatīvā datora, jo tas ir vienīgais skatpunkts, kura neveiksmei patiešām ir nozīme.

3. solis: Pirms pārtraukuma izvēlieties fail-closed vai fail-open

Nesasniedzams atbildētājs vai novecojis saraksts liek izlemt: atteikt savienojumu vai pieņemt to un fiksēt trūkumu. OpenSSL verify apakškomanda padara stingro izvēli skaidru, jo -crl_check pievienošana nepiesejamu CRL pārvērš par unable to get certificate CRL un neizdevušos pārbaudi. Mīkstā kļūme lielākajā daļā steiku nemaz nav slēdzis, bet pārbaudes neesamība, un tieši tāpēc tā tiek piegādāta nejauši.

Lai redzētu, kāda uzvedība klientam patiešām ir, noņemiet atbildētāju un pievienojieties vēlreiz. Ja tunelis joprojām ceļas, atrodiet žurnāla rindu, kas fiksēja izlaisto pārbaudi, un tad pajautājiet, vai kāds šo rindu lasītu incidenta laikā. Viens un tas pats piegādātājs var atšķirties atkarībā no protokola: IKEv2 klients un OpenVPN klients vienā mašīnā lasa nesaistītus konfigurācijas parametrus.

4. solis: Pierādiet, ka pārbaude darbojas tur, kur satiksme tiek pieņemta

Atrodiet procesu, kas izbeidz vai autorizē savienojumu, un tad pajautājiet tam konfigurācijas rindu, kas iespējo atsaukšanas pārbaudi. Vārteja, kas validē ķēdi, bet nekad nejautā par atsaukšanu, piemēro citu politiku nekā jūsu dokumentācijā, un neviens sertifikātu ķēdes ekrānuzņēmums nepierāda pretējo. OpenVPN šo opciju raksta kā crl-verify; strongSwan tur CRL un OCSP meklējumus CA konfigurācijā, kur tiek iestatīti crl_uris vai ocsp_uris. Ja nevarat norādīt ne uz vienu, pieņemiet, ka pārbaudes nav.

OCSP atbilde ir spēkā tikai tad, kad to parakstījusi izdevēja CA, vai kad to parakstījis atbildētājs, kuram ir šīs CA deleģētā paplašinātā atslēgas izmantošana OCSPSigning, tāpēc atbilde no nesaistīta pakalpojuma neko nepierāda. Ja atbildētāju uzturat paši, novērojiet to kā stingru atkarību, jo viens miris pakalpojums uzreiz kļūst par pārtraukumu katram fail-closed klientam.

5. solis: Apzināti atsauciet vienu sertifikātu

Paņemiet testa sertifikātu, atsauciet to pa to pašu kanālu, ko izmanto ražošana, un pajautājiet atbildētājam tieši. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text būtu jāziņo Cert Status: revoked kopā ar atsaukšanas laiku, un atbilde good nozīmē, ka jūsu atsaukšana nav sasniegusi atbildētāju, kam jautā jūsu klienti. Pēc tam palaidiet openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, lai redzētu to pašu lēmumu saraksta ceļā. Lasiet iemesla virkni, nevis izejas kodu, jo atsaukšanas atteikums un ķēdes kļūda abi beidzas ar neveiksmi.

Solis, kam patiešām ir nozīme, ir pēdējais: pievienojieties vēlreiz ar veco profilu pret īsto izpildes punktu un apstipriniet, ka atteikums nāk no atsaukšanas. Pēc tam pievienojieties vēlreiz ar svaigu, derīgu sertifikātu, lai pierādītu, ka neesat tikai salauzis klausītāju. Profila dzēšana klientā neko nepierāda par servera lēmumu, un to nepadara arī veiksmīga openssl verify palaišana mašīnā, kas nekad neizbeidz tuneli. RFC 6960 nosaka, ko satur atbilstoša OCSP atbilde, tostarp statusa vērtības, ko lasa šis tests.