Revoked na VPN Certificate, Kumokonekta Pa Rin? Suriin ang Pagpapatupad ng CRL

Nag-revoke ka ng certificate, gumawa ng bagong listahan, at nagbubukas pa rin ng tunnel ang lumang profile. Hindi sira ang revoke mismo: ang CRL ay isang pinirmahang pahayag na hindi na valid ang isang serial number, at binabago nito ang access kapag ni-load lamang ng component na nagtatapos ng TLS, para sa tamang issuer, bago ito gumawa ng desisyon sa pagtanggap. Doon nakalagay ang karamihan ng mga kasong ito, at kaya magkaibang katotohanan ang revoke at pagtanggi.

Daanan ang limang pagsusuri sa ibaba sa pagkakasunod-sunod, at huminto sa unang hindi tumatama, dahil ipinapalagay ng bawat sumunod na pagsusuri na tama ang mga nauna.

Suriin kung aling component ang gumagawa ng desisyon sa pagtanggap

Pangalanan ang prosesong nagbe-verify ng certificate ng client, dahil ang prosesong iyon lamang ang makakapagpatupad ng listahan. Sa server na OpenVPN ito ang daemon mismo, na naka-configure sa crl-verify. Sa ocserv ito ang linyang crl sa ocserv.conf. Sa strongSwan ang mga input ay ang mga na-load na CRL kasama ang strictcrlpolicy. Ang proxy o device na nagtatapos ng TLS sa harap ng VPN ay maaaring maging tunay na verifier din, at kung gayon, hindi kailanman nakikita ng daemon sa likod nito ang certificate ng client.

Ang WireGuard ay kabilang sa ibang kategorya. Wala itong certificate at listahan ng revoke; tinatanggap ang peer sa pamamagitan ng pampublikong key nito sa configuration, kaya ang pagtatapos ng access ay nangangahulugang pag-alis ng key na iyon. Kung naghahanap ka ng CRL sa deployment na WireGuard lamang, wala roon ang mekanismong iyon.

Mag-ingat din sa bitag sa panig ng client. Ang client na tumatanggi kumonekta dahil hindi gusto ang certificate ng server ay nagpapatupad ng chain ng server, hindi nito ni-revoke ang sariling kredensyal. Ang certificate ng user ay ni-revoke lamang kung saan vine-verify ang certificate ng user na iyon, at iyon ay halos palaging panig ng server.

Suriin kung para sa aling issuer pinirmahan ang listahan

Ang CRL ay limitado sa isang CA na nag-isyu. Sa root at intermediate, galing sa intermediate ang mga leaf certificate, kaya ang mahalagang listahan ay ang CRL ng intermediate; walang sinasabi ang listahan ng root tungkol sa mga dahong iyon. Ang verifier na nakaturo sa maling file ay masayang nagpa-parse nito, walang mahanap na tugmang entry at tinatanggap ang lahat.

Kumpirmahin ang pagtutugma bago hawakan ang daemon. Dapat tumugma ang issuer sa certificate sa subject ng listahan:

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

Kapag galing sa parehong CA ang dalawa, ang serial number na inimprenta para sa certificate ang halagang dapat lumitaw sa listahan. Kung hindi tugma, hawak mo ang maling CRL o maling kopya nito.

Ang validity ay kabilang sa parehong pagsusuri. Ang nextUpdate sa nakaraan ay nagpapaluma ng listahan, at ang verifier na nabigo nang sarado ay tatanggihan ang bawat client sa halip na ang ni-revoke lamang.

Suriin kung nasa kopyang ni-load ng daemon ang serial number

Ang revoke ay nagsusulat ng entry sa database ng CA, at ang muling pagbuo ay nagsusulat ng bagong file. Wala sa dalawa ang umaabot sa tumatakbong daemon na nag-load ng lumang kopya noong nagsimula. I-dump ang listahan at hanapin ang serial number:

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

Pagkatapos suriin kung paano kinukuha ng iyong implementasyon ang file. Binabasa ng OpenVPN ang path na ibinigay sa crl-verify isang beses sa pagsisimula, kaya kailangan ng bagong listahan ang restart o restart signal; ang parehong opsyon na nakaturo sa isang directory ay muling binabasa sa bawat koneksyon, at kaya may mode na directory. Kailangang muling i-load ng strongSwan ang mga kredensyal nito, halimbawa gamit ang swanctl --load-creds. Magkaibang katotohanan ang tamang file sa disk at ang paggamit ng verifier dito.

Suriin ang patakaran para sa nawawala o paso nang listahan

Ito ang desisyong hindi kailanman ginagawa nang malinaw ng maraming deployment, at ito ang nagtatakda kung pinoprotektahan ka ng revoke o kinukulong ang lahat sa labas. Ang fail-closed ay nangangahulugang walang magagamit na impormasyon sa revoke ay may pagtanggi; ang fail-open ay nangangahulugang nagpapatuloy ang verifier nang wala ito. Inilalantad ng strongSwan ang pagpipilian bilang strictcrlpolicy. Ang OpenVPN na may crl-verify ay tumatangging magsimula sa file na hindi nito mabasa o ma-parse, at ang paso nang listahan ay lumalabas bilang error sa TLS verification tungkol sa paso nang CRL sa halip na tahimik na pagtanggap.

Anuman ang direksiyong piliin mo, mas mahalaga ang automation kaysa sa pagpipilian: ang trabahong muling bumubuo ng CRL bago ang nextUpdate, at ang alerto kapag tumanda ang na-deploy na kopya, ay pumipigil sa alinman sa dalawang patakaran na maging insidente. Ang online na pagsusuri gamit ang OCSP ay naglilipat ng pagkasariwa sa responder, ngunit gayon pa rin ang tuntunin, dahil ang verifier na hindi naka-configure upang suriin ang sagot ay walang binabago.

Suriin ang aktibong session, pagkatapos ang mga kopya ng key

Sinusuri ang revoke sa panahon ng validation ng certificate, na nangyayari sa pagkonekta at sa muling negosasyon. Ang naitatag na session ay nagpapatuloy hanggang sa muling makipagnegosasyon, at ang default ng OpenVPN ay isang beses kada oras na may reneg-sec 3600. Kung kailangang lumabas ng network ngayon ang tao, tapusin ang session bukod sa paglalathala ng listahan, pagkatapos kumpirmahin na tinatanggihan ang muling pagkonekta.

Ihiwalay ang kredensyal sa mga kopya nito. Ang pagbura ng profile sa isang laptop ay hindi pumipigil sa ibang kopya ng parehong pribadong key na mag-authenticate; ang revoke ang gumagawa sa bawat kopya na walang silbi, at kapag tumatayo lamang ang mga naunang pagsusuri. Bigyan ang kapalit na device ng sarili nitong certificate upang ma-revoke ang isa nang hindi hinahawakan ang isa.

Bago sabihing tapos na ito: nakilala ang component na nagbe-verify, tumutugma ang issuer ng listahan sa issuer ng dahon, nasa kopyang aktuwal na ni-load ng daemon ang ni-revoke na serial number, sinasadya at sinusubaybayan ang patakaran para sa nawawala o paso nang listahan, at tinapos ang aktibong session sa halip na hinintay. Ang mga format sa likod ng lahat ng ito ay tinukoy sa RFC 5280.