Certifikata VPN e revokuar ende lidhet? Kontrollo zbatimin e CRL

E revokove certifikatën, gjenerove një listë të re, dhe profili i vjetër ende ngre një tunel. Vetë revokimi nuk është i prishur: CRL është një deklaratë e nënshkruar se një numër serial nuk është më i vlefshëm, dhe ndryshon aksesin vetëm kur komponenti që përfundon TLS e ngarkon atë, për emetuesin e duhur, përpara se të marrë vendimin e pranimit. Aty ndodhen shumica e këtyre rasteve, dhe prandaj revokimi dhe refuzimi janë dy fakte të ndryshme.

Kalo nëpër pesë kontrollet më poshtë me radhë, dhe ndalu tek i pari që nuk qëndron, sepse çdo kontroll i mëpasshëm supozon se të mëparshmit janë të vërtetë.

Kontrollo cili komponent merr vendimin e pranimit

Emërto procesin që validon certifikatën e klientit, sepse vetëm ai proces mund të zbatojë një listë. Në një server OpenVPN është vetë daemon-i, i konfiguruar me crl-verify. Në ocserv është rreshti crl në ocserv.conf. Në strongSwan hyrjet janë CRL-të e ngarkuara bashkë me strictcrlpolicy. Një proxy ose pajisje që përfundon TLS përpara VPN mund të jetë verifikuesi i vërtetë, dhe nëse është, daemon-i pas tij nuk e sheh kurrë certifikatën e klientit.

WireGuard i përket një kategorie tjetër. Nuk ka certifikata dhe as listë revokimi; një peer pranohet përmes çelësit të tij publik në konfigurim, pra përfundimi i aksesit do të thotë heqja e atij çelësi. Nëse kërkon një CRL në një vendosje vetëm me WireGuard, ai mekanizëm nuk ekziston.

Kujdes edhe për grackën nga ana e klientit. Një klient që refuzon të lidhet sepse nuk i pëlqen certifikata e serverit po zbaton zinxhirin e serverit, nuk po revokon kredencialin e vet. Një certifikatë përdoruesi revokohet vetëm aty ku validon ajo certifikatë përdoruesi, dhe kjo është pothuajse gjithmonë ana e serverit.

Kontrollo për cilin emetues u nënshkrua lista

Një CRL është i kufizuar në një CA emetues. Me një rrënjë dhe një ndërmjetëse, certifikatat gjethe vijnë nga ndërmjetësja, pra lista që ka rëndësi është CRL i ndërmjetëses; lista e rrënjës nuk thotë asgjë për ato gjethe. Një verifikues i drejtuar te skedari i gabuar e analizon me gëzim, nuk gjen asnjë zë përputhës dhe pranon gjithçka.

Konfirmo çiftëzimin përpara se të prekësh daemon-in. Emetuesi në certifikatë duhet të përputhet me subject e listës:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Kur të dyja vijnë nga e njëjta CA, numri serial i shtypur për certifikatën është vlera që duhet të shfaqet në listë. Nëse nuk përputhen, po mban CRL-në e gabuar ose kopjen e gabuar të saj.

Vlefshmëria i përket të njëjtit kontroll. Një nextUpdate në të kaluarën e bën listën të vjetëruar, dhe një verifikues që dështon i mbyllur do të refuzojë atëherë çdo klient në vend të vetëm atij të revokuar.

Kontrollo që numri serial të jetë në kopjen që ngarkoi daemon-i

Revokimi shkruan një zë në bazën e të dhënave të CA-së, dhe rigjenerimi shkruan një skedar të ri. Asnjëra nga veprimet nuk arrin një daemon që po punon dhe që ngarkoi kopjen e vjetër në nisje. Bëj dump listës dhe kërko numrin serial:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Pastaj kontrollo si e merr skedarin implementimi yt. OpenVPN lexon një shteg të dhënë crl-verify një herë në nisje, pra një listë e re kërkon rinisje ose një sinjal rinisjeje; i njëjti opsion i drejtuar te një drejtori rilexohet për çdo lidhje, dhe kjo është arsyeja pse ekziston modaliteti i drejtorisë. strongSwan duhet të ringarkojë kredencialet e tij, për shembull me swanctl --load-creds. Fakti që skedari në disk është i saktë dhe fakti që verifikuesi e përdor janë dy gjëra të ndryshme.

Kontrollo politikën për një listë që mungon ose ka skaduar

Ky është vendimi që shumë vendosje nuk e marrin kurrë në mënyrë eksplicite, dhe ai përcakton nëse revokimi të mbron apo i mbyll të gjithë jashtë. Fail-closed do të thotë që asnjë informacion i përdorshëm revokimi nuk prodhon refuzim; fail-open do të thotë që verifikuesi vazhdon pa të. strongSwan e ekspozon zgjedhjen si strictcrlpolicy. OpenVPN me crl-verify refuzon të nisë me një skedar që nuk mund ta lexojë ose analizojë, dhe një listë e skaduar shfaqet si gabim verifikimi TLS për një CRL të skaduar në vend të një pranimi të heshtur.

Cilado drejtim që zgjedh, automatizimi ka më shumë rëndësi se zgjedhja: një punë që rigjeneron CRL-në para nextUpdate, dhe një alarm kur kopja e vendosur vjetrohet, i mbajnë të dyja politikat larg nga kthimi në incident. Kontrolli online me OCSP e zhvendos freskinë te një përgjigjës, por vlen i njëjti rregull, sepse një verifikues që nuk është konfiguruar të kontrollojë përgjigjen nuk ndryshon asgjë.

Kontrollo sesionin aktiv, pastaj kopjet e çelësit

Revokimi vlerësohet gjatë validimit të certifikatës, që ndodh në lidhje dhe në rinegocim. Një sesion i vendosur vazhdon derisa të rinegociojë, dhe vlera e parazgjedhur e OpenVPN është një herë në orë me reneg-sec 3600. Nëse personi duhet të dalë nga rrjeti tani, përfundo sesionin përveç publikimit të listës, dhe pastaj konfirmo që rilidhja refuzohet.

Ndaj kredencialin nga kopjet e tij. Fshirja e një profili në një laptop nuk e pengon një kopje tjetër të të njëjtit çelës privat të autentikohet; revokimi është ai që e bën çdo kopje të papërdorshme, dhe vetëm kur kontrollet e mëparshme qëndrojnë. Jepi një pajisjeje zëvendësuese certifikatën e vet, që njëra të mund të revokohet pa prekur tjetrën.

Përpara se ta shpallësh të përfunduar: komponenti validues është identifikuar, emetuesi i listës përputhet me emetuesin e gjethes, numri serial i revokuar ndodhet në kopjen që daemon-i ngarkoi në të vërtetë, politika për listat që mungojnë ose kanë skaduar është e qëllimshme dhe e monitoruar, dhe sesioni aktiv u përfundua në vend që të pritej. Formatet pas gjithë kësaj janë të specifikuara në RFC 5280.