Isang karaniwang pangalan, dalawang sertipiko: listahan ng pinapayagan o pagbawi?

Ang muling pag-isyu ng sertipiko ng laptop sa ilalim ng parehong karaniwang pangalan ay parang kapalit, at inaakala ng lahat na patay na ang luma. Hindi. Ang nauna ay nananatiling wastong sertipikong nilagdaan ng parehong awtoridad, at anumang kontrol na tumatanggap ng mga kliyente ayon sa pangalan ay patuloy na tatanggap dito. Ang naghihiwalay sa pagsusuri ng pagkakakilanlan mula sa pagsusuri ng kredensyal ay ang serial number, at doon dapat ang pagwawasto.

Magsimula sa patakaran sa pagpapangalan na ginagamit ng server

Dalawang kontrol ang napagsasama: ang pagtanggap ng kliyente dahil sa sinasabi nitong siya, at ang pag-alis ng isang partikular na sertipiko sa serbisyo. Ang una ay pagsusuri ng pangalan, ang pangalawa ay pagsusuri ng pagbawi. Sumasagot sila sa magkaibang tanong, at ang isang deployment ay maaaring may isa nang wala ang isa.

Basahin ang configuration ng server at tandaan kung aling pinagmumulan ng pagkakakilanlan ang ginagamit. username-as-common-name ginagawang epektibong pangalan ang na-authenticate na username para sa mga paghahanap na partikular sa kliyente. Kung wala ito, ginagamit ang karaniwang pangalan ng subject mula sa sertipiko. Anuman ang sagot, isulat ito bago hawakan ang anumang listahan ng pinapayagan.

Ang dalawang landas ay nagbibigay ng magkaibang set ng pinapayagang pangalan para sa parehong sertipiko. Ang manghula rito ay nangangahulugan ng pag-edit ng maling file at paghihinuha na hindi gumagana ang kontrol.

Suriin kung ano talaga ang tumatanggap ng kliyente

Ang client-config-dir na may tugmang file ay nagbibigay ng mga pagpipiliang partikular sa kliyente; mag-isa ay hindi ito patakaran sa pagtanggap. Ang pagtanggap ayon sa pangalan ay nangangailangan ng ccd-exclusive, na tumatanggi sa mga kliyenteng walang tugmang file. Ang pagpapagana nito sa isang tumatakbong deployment ay naghihiwalay sa lahat na ang pangalan ay walang file, kaya bilangin ang mga file bago baguhin ang anuman.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Ang bilang ay ang pagsusuri: ihambing ang listahan ng direktoryo sa mga pagkakakilanlang inaasahan mong kumonekta.

Pagkatapos ay tiyakin na ang bawat pangalan ng file ay eksaktong tumutugma sa epektibong pagkakakilanlan, kabilang ang laki ng titik at mga puwang. Ang file para sa office-laptop ay walang ginagawa sa sertipikong ang subject ay nababasa bilang Office-Laptop. Ang mga puwang sa dulo ay nagtatago rin mula sa karaniwang listahan, at ganoon nananatiling hindi nababasa ang isang file na mukhang naroon.

Suriin ang CRL na ikinakarga ng gateway

Pinapangalanan ng CRL ang mga binawing sertipiko ayon sa issuer at serial number, at iyon ang detalye na wala sa pagsusuri ng pangalan. Maaaring magbahagi ng karaniwang pangalan ang dalawang sertipiko at magkaiba sa serial number, at tanging listahan sa antas ng serial number ang naghihiwalay sa kanila.

Kumpirmahin ang naka-configure na landas, ang petsa ng pag-isyu at ang field ng susunod na update bago magtiwala sa file.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

Ihambing ang serial number sa CRL sa serial number sa sertipikong balak mong itago. Ang paghahambing na iyon ang buong pagsubok, at ang gawin ito nang isang beses gamit ang mata ay mas mahalaga kaysa magtiwala sa script na walang nakabasa. Ipamahagi ang na-update na CRL sa landas na binabasa na ng gateway. Ang CRL na nasa maling direktoryo ay walang ipinapatupad, at walang log ng kliyente ang magbabanggit nito.

Palitan, pagkatapos ay patunayan ang dalawang resulta

Isyu ang kapalit sa ilalim ng parehong karaniwang pangalan, itala ang dalawang serial number, at saka lamang bawiin ang luma. Ang pagkakasunod-sunod na iyon ay nagpapanatiling magagamit ang isang gumaganang pagkakakilanlan habang inihahanda mo ang pagbabago.

Subukan muna ang kapalit: dapat itong mag-authenticate at maabot ang lahat ng nararapat sa pangalan nito. Pagkatapos ay subukan ang lumang sertipiko at kumpirmahing tinatanggihan ito, dahil walang sinasabi ang matagumpay na kapalit tungkol sa pagbawi. Kung pareho pa ring kumonekta, hindi binabasa ang input ng pagbawi o hindi kailanman nailista ang lumang serial number. Kung wala sa dalawa ang kumonekta, sinira mo ang patakaran sa pagtanggap at hindi ang kredensyal.

Ang mga sesyong naitatag na ay hiwalay na usapin, dahil ang pagbawi ay nalalapat sa mga bagong authentication maliban kung naka-configure din ang gateway na putulin ang mga aktibong koneksyon. Magpasya kung kailangan ang agarang pag-alis bago ito ipangako sa kaninuman.

Ang hindi kayang gawin ng pagsusuri ng pangalan

Sinasagot ng listahan ng pinapayagan kung maaaring kumonekta ang pagkakakilanlang ito. Hindi nito masasabi kung aling sertipiko ang ginamit ng pagkakakilanlang iyon, at tatanggapin nito ang mas lumang kredensyal hangga't ito ay may bisa at hindi binawi. Ang puwang na iyon ay lumilitaw sa panahon ng insidente, kapag ang kapalit ay inisyu ilang buwan na ang nakalipas at gumagana pa rin ang nauna.

Kung saan kailangan ang kontrol sa antas ng sertipiko, gumamit ng mekanismong nagpapangalan sa sertipiko: mga entry sa CRL, o verify hook na sumusuri ng fingerprint na pinapanatili ng operator. Pareho silang nangangailangan ng maintenance, at pareho silang tapat sa bagay na sinusuri nila. manual ng OpenVPN 2.6 ay nagdodokumento ng crl-verify at pagtanggap na partikular sa kliyente bilang magkahiwalay na opsyon, dahil mismo sa kadahilanang iyon.

Isulat kung aling kontrol ang gumagawa ng aling trabaho, pagkatapos ay subukan ang negatibong kaso. Ang pagbawing hindi mo pa nakitang tumanggi sa isang koneksyon ay isang configuration na inaasahan mong gumana.