Përse OpenConnect e refuzon gateway-in pas një ndërrimi certifikate?

Gateway-t zëvendësojnë certifikatat, dhe një klient që lidhej dje fillon të ndalet në shkëmbimin e parë TLS. Mesazhi përmend një arsye verifikimi dhe jo një defekt rrjeti, dhe vetë makina nuk ka ndryshuar, që është indici i dobishëm. Ajo që u thye është marrëdhënia midis certifikatës që paraqitet tani dhe rrënjëve që klienti është i gatshëm të marrë në konsideratë. Riparimi i saj është një vendim besimi, prandaj merreni atë vendim përpara se të shkruani një opsion.

Lexoni dështimin përpara se të ndryshoni çdo cilësim besimi

Një gabim i llojit nënshkrues mungon do të thotë që zinxhiri përfundon në diçka që klienti nuk e pranon. Mund të jetë një certifikatë e rinovuar nga një autoritet i brendshëm, një zëvendësim nga një autoritet publik, ose një pajisje në mes që paraqet certifikatën e vet. Vetëm formulimi nuk mund t'i dallojë këto raste, prandaj shikoni emetuesin përpara se të vendosni.

Ekzekutoni lidhjen një herë në plan të parë dhe lëreni të dështojë, sepse dalja interaktive mban emrin e serverit, zinxhirin e emetuesit dhe gjurmën e gishtave që klienti ka llogaritur. Krahasoni atë emetues me një autoritet që organizata juaj operon vërtet. Nëse gjurma e gishtave ndryshoi ndërsa emetuesi jo, trajtojeni si të dyshimtë derisa një rinovim të konfirmohet përmes një kanali që tashmë i besoni. Të hamendësosh në këtë pikë është mënyra se si dikush përfundon duke fiksuar çelësin e një përgjuesi.

Shënoni versionin e klientit në të njëjtën shënim. Një pjesë e mirë e dështimeve që duken si probleme besimi vijnë nga një klient më i vjetër që has një shkëmbim gateway më të ri.

Zgjidhni midis besimit te emetuesi dhe fiksimit të një çelësi

Të dyja opsionet e bëjnë lidhjen të suksesshme. Ato thyhen më vonë në mënyra të kundërta, prandaj zgjedhja i takon dështimit që mund të duroni.

Kthehuni te skedari CA kur certifikata vjen nga një autoritet që mund ta verifikoni në mënyrë të pavarur, sepse rinovimet vazhdojnë të funksionojnë pa prekur argumentet e klientit. Çiftojeni me çelësin që çaktivizon rrënjët e sistemit, përndryshe një autoritet publik mund të plotësojë kontrollin në emrin tuaj. Në vend të kësaj fiksoni kur gateway-i nuk ka një CA që mund të merrni ose kur përjashtimi më i ngushtë i mundshëm është qëllimi. Asnjë rrugë nuk është më e sigurt në mënyrë abstrakte: CA shkallëzohet përgjatë rinovimeve, fiksimi është më i lehtë për t'u rishikuar.

Cilindo që të zgjidhni, vlera e besuar duhet të arrijë përmes një kanali që ishte i besuar përpara se të ndodhte ndryshimi. Një administrator, një sesion konsol në gateway ose një kopje e marrë më parë të gjitha kualifikohen. Kopjimi i çdo gjurme gishtash që shfaq prompt-i është i përshtatshëm dhe është pikërisht ajo që shpreson një përgjues.

Vendoseni vlerën në komandën që ekzekutoni vërtet

Fiksimi udhëton në një opsion certifikate serveri, dhe prefiksi i tij vendos kodimin: tregues heksadecimalë të çelësit publik nën sha1 ose sha256, dhe fiksimi i çelësit base64 nën pin-sha256. Dhënia e tij çaktivizon gjithashtu besimin e sistemit për atë ekzekutim, kështu që çelësi i fiksuar bëhet i gjithë vendimi.

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

Klienti përputh një tregues të cunguar, duke pranuar vetëm katër karaktere pas prefiksit, që është një kurth dhe jo një lehtësi. Një vlerë e shkurtuar kalon lokalisht dhe prapë nuk identifikon gateway-in që kishit menduar. Kopjoni vargun e plotë që klienti shtypi në provën e parë, në vend që ta rishkruani nga një mesazh. Më pas zhvendosni opsionin e përfunduar në skriptin mbështjellës, skedarin e njësisë ose profilin që lëshon lidhjen, që vendimi i besimit të jetë i rishikueshëm dhe redaktimet e mëvonshme të jenë të qëllimshme.

Lëshuesit e desktopit dhe shtojca NetworkManager ruajnë kopjen e tyre të argumenteve të lidhjes. Një skript i redaktuar në disk nuk arrin në një profil të importuar më parë, kështu që vlera e ruajtur vazhdon të fitojë.

Trajtoni një rotacion pa u mbyllur jashtë

Opsioni mund të jepet më shumë se një herë, kështu që një ndryshim i planifikuar mund të pranojë çelësin dalës dhe atë hyrës së bashku. Shtoni fiksimin e ri përpara se gateway-i të ndërrohet, mbani të dy të listuar ndërsa sesionet migrojnë, dhe hiqni atë të tërhequr kur çelësi i vjetër zhduket. Ai dritare ka nevojë për një pronar, sepse një fiksim i dyfishtë i harruar lë një çelës të besuar pa askush që e mbikëqyr. Një rindërtim që prodhon një palë çelësash të re thyen një fiksim të pastër, dhe rikuperimi është i njëjti procedurë në drejtimin e kundërt.

Shkruani datën e ndryshimit pranë fiksimit. Një fiksim pa datë rishikimi është një ndërprerje e ardhshme që mbart një mesazh gabimi konfuz.

Përjashtoni versionin e klientit përpara se të redaktoni besimin

Një klient i vjetëruar mund të dështojë ndërsa analizon një përgjigje autentikimi që gateway-i e ka ndryshuar që atëherë, dhe mesazhi i sipërfaqes flet ende për lidhjen dhe jo për analizuesin. Krahasoni versionin e instaluar me atë që dokumenton gateway-i, dhe provoni një paketë aktuale në një profil njëpërdorimsh përpara se të ndryshoni çdo cilësim besimi.

openconnect --version

Pas riparimit, verifikoni dy gjëra dhe jo një: portali ngarkohet përmes tunelit, dhe një adresë e zakonshme e brendshme përgjigjet. Një shtrëngim duarsh i përfunduar dëshmon vetëm se vendimi i besimit u pranua.