Bakit tinatanggihan ng OpenConnect ang gateway pagkatapos ng pagpapalit ng sertipiko?

Nagpapalit ng sertipiko ang mga gateway, at ang kliyenteng kumonekta kahapon ay nagsisimulang huminto sa unang palitan ng TLS. Binabanggit ng mensahe ang dahilan ng pagpapatunay at hindi ang sira ng network, at ang makina mismo ay hindi nagbago, iyon ang kapaki-pakinabang na palatandaan. Ang nasira ay ang ugnayan ng sertipikong inihaharap ngayon at ng mga ugat na handang isaalang-alang ng kliyente. Ang pagsasaayos nito ay desisyon sa pagtitiwala, kaya gawin ang desisyong iyon bago mag-type ng opsyon.

Basahin ang kabiguan bago baguhin ang anumang setting ng pagtitiwala

Ang error na uri ng nawawalang tagapirma ay nangangahulugang nagtatapos ang kadena sa isang bagay na hindi tinatanggap ng kliyente. Maaaring ito ay na-renew na sertipiko mula sa panloob na awtoridad, kapalit mula sa pampublikong awtoridad, o aparato sa gitna na naghaharap ng sarili nitong sertipiko. Ang pananalita lamang ay hindi makapag-iiba ng mga kasong iyon, kaya tingnan ang nag-isyu bago magpasya.

Patakbuhin ang koneksyon nang isang beses sa harapan at hayaang mabigo, dahil dala ng interactive na output ang pangalan ng server, ang kadena ng nag-isyu at ang fingerprint na kinuha ng kliyente. Ihambing ang nag-isyu na iyon sa awtoridad na talagang pinapatakbo ng iyong organisasyon. Kung nagbago ang fingerprint pero hindi ang nag-isyu, ituring itong kahina-hinala hanggang makumpirma ang renewal sa isang channel na pinagkakatiwalaan mo na. Ang manghula sa puntong ito ay ang paraan para mapirmi ng isang tao ang susi ng isang nagsisingit.

Isulat ang bersyon ng kliyente sa parehong tala. Malaking bahagi ng mga kabiguang mukhang problema sa pagtitiwala ay nagmumula sa lumang kliyenteng nakatagpo ng mas bagong palitan ng gateway.

Pumili sa pagitan ng pagtitiwala sa nag-isyu at pag-pin ng isang susi

Parehong opsyon ang nagpapagana ng koneksyon. Masisira sila mamaya sa magkasalungat na paraan, kaya nauukol ang pagpili sa kabiguang kaya mong tiisin.

Gamitin ang file ng CA kapag ang sertipiko ay galing sa awtoridad na kaya mong i-verify nang nakapag-iisa, dahil patuloy na gumagana ang mga renewal nang hindi hinahawakan ang mga argumento ng kliyente. Ipares ito sa switch na nagpapahinto sa mga ugat ng system, kung hindi ay may pampublikong awtoridad na makakapuno ng pagsusuri sa ngalan mo. Sa halip, i-pin kapag walang CA ang gateway na makukuha mo o kapag ang pinakamakitid na posibleng eksepsiyon ang layunin. Walang landas na mas ligtas sa abstrakto: lumalawak ang CA sa mga renewal, mas madaling suriin ang pag-pin.

Alin man ang piliin mo, ang pinagkakatiwalaang halaga ay dapat dumating sa channel na pinagkatiwalaan bago nangyari ang pagbabago. Kwalipikado ang administrador, sesyon ng console sa gateway, o kopyang kinuha nang maaga. Ang kopyahin ang anumang fingerprint na ipinapakita ng prompt ay maginhawa at eksaktong inaasahan ng isang nagsisingit.

Ilagay ang halaga sa command na talagang inilulunsad mo

Nagbibiyahe ang pag-pin sa isang opsyon ng sertipiko ng server, at ang prefix nito ang nagtatakda ng encoding: hexadecimal na digest ng pampublikong susi sa ilalim ng sha1 o sha256, at pag-pin ng susi sa base64 sa ilalim ng pin-sha256. Ang pagbibigay nito ay nagpapahinto rin ng pagtitiwala ng system para sa run na iyon, kaya ang naka-pin na susi ang nagiging buong desisyon.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Itinatapat ng kliyente ang pinutol na digest, tumatanggap ng kasing-kaunti ng apat na karakter pagkatapos ng prefix, na isang patibong at hindi kaginhawahan. Ang pinaikling halaga ay pumapasa lokal at hindi pa rin tinutukoy ang gateway na nilayon mo. Kopyahin ang buong string na inilimbag ng kliyente sa unang pagtatangka sa halip na i-type muli mula sa mensahe. Pagkatapos ay ilipat ang tapos na opsyon sa wrapper script, unit file o profile na naglulunsad ng koneksyon, para masuri ang desisyon sa pagtitiwala at ang mga susunod na pag-edit ay sinasadya.

Ang mga desktop launcher at ang NetworkManager plugin ay nag-iimbak ng sarili nilang kopya ng mga argumento ng koneksyon. Ang script na na-edit sa disk ay hindi umabot sa profile na na-import kanina, kaya patuloy na nananalo ang naka-store na halaga.

Pangasiwaan ang rollover nang hindi nakakandado sa labas

Maaaring ibigay ang opsyon nang higit sa isang beses, kaya kayang tanggapin ng planadong pagbabago ang papalabas at papasok na susi nang sabay. Idagdag ang bagong pin bago magpalit ang gateway, panatilihing nakalista ang dalawa habang lumilipat ang mga sesyon, at alisin ang retirado kapag wala na ang lumang susi. Kailangan ng may-ari ang window na iyon, dahil ang nakalimutang dobleng pin ay nag-iiwan ng susi na pinagkakatiwalaan nang walang nagbabantay. Ang muling pagbuo na gumagawa ng bagong pares ng susi ay sinira ang purong pin, at ang pagbawi ay parehong pamamaraan sa kabilang direksyon.

Isulat ang petsa ng pagbabago sa tabi ng pin. Ang pin na walang petsa ng pagsusuri ay isang kabiguan sa hinaharap na may nakakalitong mensahe ng error.

Ibukod ang bersyon ng kliyente bago i-edit ang pagtitiwala

Maaaring mabigo ang lumang kliyente habang pinaparsa ang tugon ng authentication na binago ng gateway mula noon, at ang mensahe sa ibabaw ay tungkol pa rin sa koneksyon at hindi sa parser. Ihambing ang naka-install na bersyon sa dokumentado ng gateway, at subukan ang kasalukuyang pakete sa isang profile na ginagamit isang beses bago baguhin ang anumang setting ng pagtitiwala.

openconnect --version

Pagkatapos ng pagkukumpuni, i-verify ang dalawang bagay at hindi isa: naglo-load ang portal sa pamamagitan ng tunnel, at tumutugon ang ordinaryong panloob na address. Ang natapos na handshake ay nagpapatunay lamang na tinanggap ang desisyon sa pagtitiwala.