OCSP kontraŭ CRL: kiel ĉiu revoka kontrolo efektive funkcias

Unu el ĉi tiuj du revokaj kontroloj redonas subskribitan respondon pri unu sola atestilo, kaj la alia redonas subskribitan liston, kiun vi elŝutas tute. Ambaŭ celas sciigi al kontrolanto, ĉu legitimilo ankoraŭ estas fidata, kaj ambaŭ malsukcesas laŭ manieroj, kiuj tute ne similas unu al la alia. La suba ordo sekvas tion, kion operatoro efektive renkontas en produkto, komencante per la bajtoj sur la drato kaj finiĝante per pordego, kiu rifuzas konekton. Preterlasi paŝon estas la maniero, kiel deplojo finiĝas per revoka politiko, kiu ekzistas nur sur papero.

Paŝo 1: Kion ĉiu kontrolo redonas kaj kiom longe ĝi restas uzebla

CRL estas publikigata kiel unu subskribita objekto kovranta ĉiun atestilon, kiun eldoninto revokis, do kontrolanto prenas ĝin unufoje kaj reuzas ĝin ĝis la nextUpdate de la listo pasos. Respondo de OCSP estas pli mallarĝa: ĝi respondas pri ekzakte unu atestilo kaj portas thisUpdate, producedAt kaj kutime ankaŭ nextUpdate. Tiu diferenco direktas ĉion alian. Kaŝmemorigita CRL malnoviĝas silente, ĉar la dosiero ankoraŭ analiziĝas kaj ĝia subskribo ankoraŭ validiĝas, dum eksvalidiĝinta respondo de OCSP estas evidente senutila en la momento, kiam vi legas ĝiajn tempindikojn.

Kaŝmemorigo do estas la unua afero difinenda: kiu komponanto tenas la kopion kaj al kiu plafono tiu kopio obeas. En pordego la plafono devus esti nextUpdate minus sekureca marĝeno, neniam tio, kion hazarde sugestas kaŝmemora kapo de HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate presas ambaŭ datojn, kaj listo, kies nextUpdate jam estas en la pasinteco, devas esti traktata kiel mankanta, ne nur kiel malnova.

Paŝo 2: Kien la atestilo direktas la klienton

La folia atestilo kutime portas du spurojn: etendon de distribuejo de CRL kaj eron de aliro al aŭtoritata informo por OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints presas la unuan, kaj la dua troviĝas sub la sekcio AIA de openssl x509 -in client.pem -noout -text. Ĉiu el la etendoj estas montrilo, ne devigo. Kliento, kiu neniam efektivigas revokan kontroladon, konektiĝos tute bone al atestilo, kies etendoj nomas respondanton, kiu estas morta jam de jaro.

Distribuejoj ofte nomas internan gastiganton, kiu solviĝas nur ene de unu reta segmento, kaj iuj pli malnovaj klientoj tute rifuzas ldap-adresojn. Testu atingeblon de la gastiganto, kiu finas la tunelon, ne de via propra tekkomputilo, ĉar tio estas la sola vidpunkto, kies malsukceso vere gravas.

Paŝo 3: Elektu fail-closed aŭ fail-open antaŭ la interrompo

Neatingebla respondanto aŭ eksvalidiĝinta listo devigas decidon: rifuzi la konekton, aŭ akcepti ĝin kaj registri la mankon. La subkomando verify de OpenSSL igas la striktan elekton eksplicita, ĉar aldoni -crl_check igas neatingeblan CRL unable to get certificate CRL kaj malsukcesan validigon. Mola malsukceso en la plej multaj stakoj tute ne estas ŝaltilo, ĝi estas la foresto de la kontrolo, kaj ĝuste tial ĝi venas hazarde.

Por vidi, kiun konduton kliento vere havas, forigu la respondanton kaj rekonektiĝu. Se la tunelo tamen leviĝas, trovu la protokollinion, kiu registris la preterlasitan kontrolon, kaj poste demandu, ĉu iu legus tiun linion dum okazaĵo. La sama vendisto povas diferenci laŭ protokolo: kliento IKEv2 kaj kliento OpenVPN sur unu maŝino legas nesrilatajn agordajn butonojn.

Paŝo 4: Pruvu, ke la kontrolo funkcias tie, kie trafiko estas allasata

Trovu la procezon, kiu finas aŭ rajtigas la konekton, kaj poste demandu ĝin pri la agorda linio, kiu ebligas revokan kontroladon. Pordego, kiu validigas la ĉenon sed neniam demandas pri revoko, plenumas alian politikon ol tiu en via dokumentaro, kaj neniu ekrankopio de atestila ĉeno pruvas la malon. OpenVPN literumas la opcion kiel crl-verify; strongSwan tenas serĉojn pri CRL kaj OCSP sub la CA-agordo, kie crl_uris aŭ ocsp_uris estas agordataj. Se vi ne povas montri al unu el ili, supozu, ke la kontrolo forestas.

Respondo de OCSP validas nur kiam la eldonanta CA subskribis ĝin, aŭ kiam subskribis ĝin respondanto havanta la etenditan ŝlosiluzon OCSPSigning delegitan de tiu CA, do respondo de nerilata servo pruvas nenion. Se vi mem funkciigas la respondanton, monitoru ĝin kiel malmolan dependon, ĉar unu morta servo fariĝas interrompo por ĉiu fail-closed-kliento samtempe.

Paŝo 5: Intence revoku unu atestilon

Prenu testan atestilon, revoku ĝin per la sama kanalo, kiun uzas produkto, kaj demandu la respondanton rekte. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text devus raporti Cert Status: revoked kune kun revoka tempo, kaj respondo good signifas, ke via revoko ne atingis la respondanton, kiun viaj klientoj demandas. Poste rulu openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem por vidi la saman decidon tra la lista vojo. Legu la kialan ĉenon anstataŭ la elirkodon, ĉar revoka malakcepto kaj ĉena eraro ambaŭ finiĝas per malsukceso.

La paŝo, kiu vere gravas, estas la lasta: rekonektiĝu per la malnova profilo kontraŭ la reala plenum-punkto kaj konfirmu, ke la rifuzo venas de la revoko. Poste rekonektiĝu per freŝa, valida atestilo por pruvi, ke vi ne nur rompis la aŭskultanton. Forigi la profilon en la kliento pruvas nenion pri la decido de la servilo, kaj same ne faras sukcesa openssl verify-rulado sur maŝino, kiu neniam finas tunelon. RFC 6960 difinas, kion enhavas konforma respondo de OCSP, inkluzive de la statvaloroj, kiujn ĉi tiu testo legas.