Ano ang sinusuri ng iyong VPN client bago ito magtiwala sa isang sertipiko

Sinasabi ng iyong VPN client na hindi ma-verify ang sertipiko, at doon tumitigil ang dialog. Naroon ang file, tumatakbo ang server, at gumana ang parehong profile sa ibang laptop noong nakaraang buwan. Sa ilalim ng isang-linyang babalang iyon pinadaan ng client ang sertipiko ng peer sa apat na pintuan: ang certificate authority na inayos mo ang nananagot sa landas ng lagda, naaabot ng landas na iyon ang awtoridad, ang pangalan ng peer ay ang hiniling mo, at magagamit na ang sertipiko ngayon para sa layuning ito. Hanapin ang pintuang nagsara at ang pag-aayos ay karaniwang isang file; laktawan ang hakbang na iyon at muling mag-i-import ka ng mga bundle buong hapon.

Basahin ang dialog bago i-edit ang profile

Ang mga error ng sertipiko ay binubuo ng aklatang nasa ilalim, hindi ng produktong VPN na ini-install mo, kaya ang eksaktong string ang una mong ebidensya. «Hindi makuha ang sertipiko ng lokal na issuer» ay tumutukoy sa landas o sa trust anchor. «Nag-expire na ang sertipiko o hindi pa ito valid» ay tumutukoy sa oras. «Hindi sinusuportahang layunin ng sertipiko» ay tumutukoy sa extended key usage. Ang hindi pagtutugma ng pangalan ay nagsasabi kung aling pangalan ang gusto nito. Wala sa apat ang naaayos sa pamamagitan ng muling pag-install ng client.

Itaas ang antas ng pag-log bago magbago ng anuman. Nag-uulat ang OpenVPN ng pagkabigo sa pag-verify sa paligid ng handshake kapag pinatakbo mo ito gamit ang --verb 4, at isinusulat ng strongSwan ang mga desisyon nito sa pagkakakilanlan at chain sa log ng charon. Pagkatapos ay tiyakin kung aling sertipiko ang sinusuri mo, dahil karaniwang sinusubukan ng mga tao ang file sa disk habang ang profile ay naglalagay ng mas lumang kopya sa loob. Kapag naglalagay ang profile ng mga bloke ng PEM, ang nakalagay na sertipiko ang sinusubukan.

Nilalagdaan ng certificate authority ang mga pagkakakilanlan, hindi ang mga pahintulot

May hawak ang awtoridad ng isang pangalan at isang signing key. Naglalabas ito ng mga sertipikong nagbibigkis ng pampublikong key sa pangalang iyon ayon sa sarili nitong patakaran, na may validity window at mga limitasyon sa paggamit. Kailangan lang ng iyong client ang sertipiko ng awtoridad upang makilala ang issuer; hindi nito kailanman kailangan ang signing key, at ang pagpapadala ng key na iyon sa mga client ay magbibigay sa kanila ng kakayahang gumawa ng anumang pagkakakilanlang pinagkakatiwalaan ng deployment.

Ang pagtitiwala sa isang awtoridad ay ginagawang kandidato ang bawat sertipikong nilagdaan nito, hindi ang tamang peer. Kandidato rin ang sertipiko ng web server mula sa parehong internal na CA. Iyon ang dahilan kung bakit may mga pintuan ng pangalan at layunin, at kung bakit mas mahalaga ang kompromisadong CA key kaysa sa alinmang solong server: naaabot nito ang bawat pagkakakilanlang inilabas ng awtoridad kailanman. Maglabas ng mga client certificate sa bawat device, upang ang nawawalang laptop ay isang pagbawi lamang sa halip na muling paggawa ng key sa buong deployment.

Itayong muli ang landas na sinusubukang itayo ng client

Ang landas ay mula sa sertipiko ng peer, sa pamamagitan ng zero o higit pang intermediate na sertipiko, hanggang sa root sa iyong trust store. Ang kulang na intermediate na sertipiko ang pinakakaraniwang pagkasira ng chain, at mula sa panig ng client ay mukhang kapareho ng hindi pinagkakatiwalaang root. Basahin muna ang leaf, pagkatapos ay hayaang buuin ng OpenSSL ang landas mula sa materyal na balak mong ipadala.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Ang zero na exit status ay nangangahulugang nabuo ang landas mula sa mga file na iyon; ang pagkabigo ay pinapangalanan ang sertipikong hindi naabot. Kung nagtagumpay ang openssl verify habang tumatanggi pa rin ang client, ang pagkakaiba ay nasa aktwal na ipinapadala ng server o sa kung aling trust file ang nilo-load ng profile. Sa OpenVPN ang mga intermediate ay maaaring sumama sa server certificate file o ibigay nang hiwalay gamit ang --extra-certs, at ang bundle na may dalawang root na nakasulat sa ilalim ng parehong subject name ay magpapadala sa isa sa iyong mga client sa maling sanga.

Magkahiwalay na pintuan ang pangalan at layunin

Hindi kailanman nagtatanong ang pagbuo ng chain kung sa iyo ang pangalan. Sinusuri lamang ito ng OpenVPN kapag itinakda ng profile ang --verify-x509-name, at ang lumang ugali ng pagtutugma lamang sa karaniwang pangalan ay nababasag sa mga sertipikong ang pagkakakilanlan ay nabubuhay sa subjectAltName. Itinutugma ng mga deployment ng IKEv2 ang naka-configure na pagkakakilanlan sa mga entry ng SAN o sa natatanging pangalan, depende sa client, at ang wildcard o %any na halaga ay tahimik na pinapatay ang paghahambing na inakala mong mayroon ka.

Susunod ang oras at layunin. Ang laptop na ang orasan ay nauuna ng ilang oras ay tumatanggi sa sertipikong hindi pa valid, at ang nag-expire na intermediate ay nagpapabigo sa landas habang ang leaf ay valid. Ang mga pagkabigo sa layunin ay nagmumula sa sertipikong walang serverAuth sa extended key usage, o may keyUsage na hindi pinapayagan ang lagda ng handshake, na iniuulat ng OpenSSL bilang hindi sinusuportahang layunin ng sertipiko. Muling maglabas mula sa tamang template; wala sa mensaheng iyon ang dahilan para patayin ang pag-verify.

Gumagana lamang ang pagbawi kung may nag-configure nito

Ang CRL o tugon ng OCSP ay hindi awtomatikong kinokonsulta. Sa server ng OpenVPN, ang mga client certificate ay inihahambing sa isang listahan lamang kapag ang --crl-verify ay tumuturo sa isa. Ang pagsuri ng sertipiko ng server sa panig ng client ay nakadepende sa implementasyon at kadalasang wala. Kailangan ng strongSwan ang plugin nito sa pagbawi at isang patakaran bago tumingin sa isang CRL para sa peer.

Iyon ang nagpapaliwanag sa ticket na matatanggap mo sa huli: ang binawing client certificate ay kumokonekta pa rin, at lahat ay naghihinuha na sira ang pagbawi. Wala namang nagsusuri. I-publish at i-refresh ang CRL, o panatilihing sapat na maikli ang buhay ng mga client certificate upang ang lumang pagbawi ay maghalaga nang panandalian, at sanayin ang landas ng pagbawi sa isang certificate sa laboratoryo bago mo ito kailanganin sa isang insidente.

Isang pagkakasunod-sunod ng pag-aayos na nagpapanatiling bukas ang pag-verify

Pag-uri-uriin ayon sa sintomas bago hawakan ang mga file, dahil ang bawat hilera ng talahanayan ay nagpapadala sa iyo sa ibang bagay.

Puntahan ang listahan sa isang pass: tiyakin ang file na nilo-load ng profile, itayo ang landas mismo, tingnan kung ipinapadala ng server ang intermediate, ihambing ang orasan, basahin ang SAN, basahin ang EKU, pagkatapos ay muling kumonekta at panoorin ang parehong linya ng log na mawala. Kung ang isang device ay hindi talaga mabibigyan ng CA, ang pinning ang tapat na alternatibo, dahil tinatanggap ng OpenVPN 2.6 ang --peer-fingerprint at pinapaliit ang tiwala sa isang key sa halip na alisin ang pagsuri. Ang RFC 5280 ang sanggunian sa kahulugan ng bawat isa sa mga field na iyon.