Na-renew na VPN certificate: tinatanggihan pa rin ito ng ilang kliyente

Kalahati ng kapaligiran ay muling kumokonekta pagkatapos ng renewal at tatlong device ang tumatanggi, bawat isa ay may babala tungkol sa pagkakakilanlan ng gateway. Ang renewal mismo ay karaniwang gawain. Ang hawak ng tatlong device na iyon ay isang pin sa lumang object, at ang pin ay hindi listahan ng CA, pagsusuri ng pangalan o entry sa trust store. Ihambing ang tatlong mekanismo bago hawakan ang sinumang kliyente.

Isang renewal, dalawang pag-uugali

Ang mga kliyenteng muling kumokonekta ay may desisyon sa tiwala na pumapasa pa, at ang mga tumatanggi ay may pangangailangan na hindi natutugunan ng bagong certificate. Ang pagkakaibang iyon ay impormasyon, hindi ingay. Basahin nang tumpak ang mensahe ng kliyenteng nabigo. Ang hindi pagtugma ng pangalan, hindi kilalang issuer at nabagong fingerprint ay tatlong magkaibang hatol, at ang huli lamang ang tumuturo sa isang pin.

Tingnan din kung aling profile ang pinili ng kliyenteng nabigo. Ang na-import na kopya na naninirahan sa sarili nitong store ay hindi nagbabago kapag in-edit ng administrator ang orihinal na file sa ibang lugar.

Pinapalitan ng renewal ang object, hindi lamang ang petsa

Ang fingerprint ay tumutukoy sa naka-encode na nilalaman ng certificate. Ang renewal ay gumagawa ng bagong certificate, kaya nagbabago ang fingerprint kahit manatiling pareho ang pangalan ng subject at ang public key. Inaasahan iyon at walang pinsala sa mga kliyenteng nagtitiwala sa isang CA at nagbe-verify ng pangalan. Nakamamatay iyon sa kliyenteng naka-configure na tumanggap ng eksaktong isang certificate, at nakamamatay din ito sa kliyenteng hindi kailanman nakatanggap ang trust store ng bagong issuer.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

Ang ikalawang linya ay sumasagot sa ibang tanong, kung nakaligtas ang key pair. Ang renewal na muling gumagamit ng key ay pinapanatili ang halagang iyon at binabago lamang ang certificate, at iyon mismo ang kaso kung saan natutukso ang administrator na ipagpalagay na walang nagbago. Suriin ang certificate na naka-deploy, hindi ang nasa build host. Ang paghahambing ng file sa isang repository ay nagpapatunay kung ano ang nabuo, hindi kung ano ang ipinapakita ng isang listener sa ngayon.

Basahin kung ano ang pinipin ng kliyente

Ang ilang kliyente ay nagtatago ng fingerprint sa kanilang profile at inihahambing ito sa bawat koneksyon. Ang iba ay nag-iimbak nito sa trust store ng platform, at ang iba pa ay umaasa lamang sa isang CA. Iba-iba ang pag-aayos sa bawat kaso, kaya tukuyin muna ang mekanismo.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Ipinapakita ng unang command ang isang pin sa karaniwang profile; ipinapakita ng pangalawa ang fingerprint na aktwal na inihahain ng endpoint ngayon. Kapag magkaiba ang dalawang iyon, natagpuan mo ang sira nang hindi nanghuhula. Huwag idikit ang bagong halaga sa bawat kliyenteng nagrereklamo. Ang kliyenteng tumatanggi dahil sa issuer ay patuloy na tatanggi, at ikaw ay magpapaniwala sa sarili mo na ang fingerprint ang problema noong hindi naman.

Ihambing ang certificate na inihahain ng bawat backend

Ang pabago-bagong resulta ay karaniwang nangangahulugang higit sa isang endpoint, at ang renewal na inilapat sa isang node ay iniiwan ang iba na nagpapakita ng lumang object. Ihambing ang bawat backend ayon sa address at hindi sa pinagsamang pangalan.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Ang isang pool kung saan nahuhuli ang isang node ay nagpapaliwanag ng kliyenteng kumokonekta sa ikalawang pagtatangka at nabibigo sa una. Nagpapaliwanag din ito ng monitoring check na pumapasa habang nagrereklamo ang mga user. Ayusin muna ang pagkahuli. Ang pag-roll ng trust configuration bago maghatid ng bagong certificate ang bawat node ay lumilikha ng window kung saan walang gumagana, at ang pag-roll pagkatapos ay iniiwan ang mga kliyenteng nabibigo nang hindi mahulaan.

Baguhin ang tiwala sa pamamagitan ng pinamamahalaang landas

Kumpirmahin ang pagpapalit sa pamamagitan ng pinagkakatiwalaang administrative channel bago ito tanggapin saanman. Ang makatwirang petsa ng pag-expire ay hindi patunay ng pagmamay-ari. I-update ang pinamamahalaang configuration sa pamamagitan ng prosesong nagmamay-ari nito, kasama ang anumang planadong overlap ng mga katanggap-tanggap na pagkakakilanlan, at panatilihin ang pag-verify ng pangalan na kailangan ng deployment. Ang pin na walang pagsusuri ng pangalan ay mas mahinang disenyo kaysa sa tiwala sa CA na pinalitan nito.

Pagkatapos ay i-verify bawat kliyente, kumonekta, kumpirmahin ang pagkakakilanlang tinanggap nito, at itala ang bersyon ng certificate na pinagkakatiwalaan nito ngayon. Ang babalang itinanggi nang isang beses ay may ugali na bumalik sa susunod na renewal.