Miért utasítja el az OpenConnect az átjárót a tanúsítvány cseréje után?

Az átjárók cserélik a tanúsítványokat, és a tegnap még csatlakozó kliens az első TLS-cserénél megáll. Az üzenet ellenőrzési okot nevez meg hálózati hiba helyett, és maga a gép nem változott, ez a hasznos nyom. Ami eltört, az a most bemutatott tanúsítvány és a gyökerek közötti kapcsolat, amelyeket a kliens hajlandó figyelembe venni. Ennek megjavítása bizalmi döntés, ezért hozza meg ezt a döntést, mielőtt bármilyen opciót beírna.

Olvassa el a hibát, mielőtt bármilyen bizalmi beállítást módosítana

A hiányzó aláíró típusú hiba azt jelenti, hogy a lánc olyan valaminél ér véget, amit a kliens nem fogad el. Ez lehet egy belső hatóság megújított tanúsítványa, egy nyilvános hatóság helyettesítője, vagy egy középen álló eszköz, amely a saját tanúsítványát mutatja be. Önmagában a megfogalmazás nem tudja megkülönböztetni ezeket az eseteket, ezért nézze meg a kibocsátót, mielőtt döntene.

Futtassa a kapcsolatot egyszer előtérben, és hagyja, hogy elbukjon, mert az interaktív kimenet hordozza a kiszolgáló nevét, a kibocsátói láncot és a kliens által kiszámított ujjlenyomatot. Hasonlítsa össze ezt a kibocsátót egy olyan hatósággal, amelyet a szervezete valóban üzemeltet. Ha az ujjlenyomat megváltozott, a kibocsátó viszont nem, kezelje gyanúsnak, amíg a megújítást egy már megbízható csatornán meg nem erősítik. Ezen a ponton találgatni az az út, amelyen valaki végül rögzíti egy elfogó kulcsát.

Jegyezze fel a kliens verzióját ugyanabba a feljegyzésbe. A bizalmi problémáknak tűnő hibák jó része régebbi kliensből ered, amely újabb átjáró-cserével találkozik.

Válasszon a kibocsátóba vetett bizalom és egyetlen kulcs rögzítése között

Mindkét lehetőség sikeressé teszi a kapcsolatot. Később ellentétes módon törnek el, ezért a választás ahhoz a hibához tartozik, amelyet el tud viselni.

Nyúljon a CA-fájlhoz, amikor a tanúsítvány olyan hatóságtól származik, amelyet önállóan ellenőrizni tud, mert a megújítások akkor a kliens argumentumainak érintése nélkül működnek tovább. Párosítsa azt a kapcsolóval, amely letiltja a rendszergyökereket, különben egy nyilvános hatóság az Ön nevében teljesítheti az ellenőrzést. Inkább rögzítsen, ha az átjárónak nincs beszerezhető CA-ja, vagy ha a lehető legszűkebb kivétel a cél. Egyik út sem biztonságosabb elvont értelemben: a CA a megújításokon át skálázódik, a rögzítést könnyebb áttekinteni.

Bármelyiket választja, a megbízható értéknek olyan csatornán kell érkeznie, amely a változás előtt megbízható volt. Egy rendszergazda, egy konzol-munkamenet az átjárón vagy egy előre vett másolat mind megfelel. A kérés által mutatott ujjlenyomat másolása kényelmes, és pontosan az, amit egy elfogó remél.

Tegye az értéket abba a parancsba, amelyet valóban elindít

A rögzítés egy kiszolgáló-tanúsítvány opcióban utazik, és az előtagja dönti el a kódolást: hexadecimális nyilvános kulcsú kivonatok sha1 vagy sha256 alatt, és a base64 kulcsrögzítés pin-sha256 alatt. Megadása a rendszerbizalmat is letiltja arra a futásra, így a rögzített kulcs lesz az egész döntés.

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

A kliens csonkolt kivonatot illeszt, akár négy karaktert is elfogad az előtag után, ami csapda, nem kényelem. A rövidített érték helyben átmegy, és még mindig nem azonosítja a szándékolt átjárót. Másolja a kliens által az első próbálkozáskor kiírt teljes karakterláncot, ahelyett hogy egy üzenetből újragépelné. Ezután helyezze a kész opciót a kapcsolatot indító burkolószkriptbe, unit fájlba vagy profilba, hogy a bizalmi döntés áttekinthető legyen, és a későbbi módosítások szándékosak.

Az asztali indítók és a NetworkManager bővítmény saját másolatot tárolnak a kapcsolati argumentumokról. A lemezen szerkesztett szkript nem ér el egy korábban importált profilt, ezért a tárolt érték továbbra is nyer.

Kezeljen egy váltást anélkül, hogy kizárná magát

Az opció többször is megadható, így egy tervezett változás a kimenő és a bejövő kulcsot együtt is elfogadhatja. Adja hozzá az új rögzítést, mielőtt az átjáró vált, tartsa mindkettőt listázva, amíg a munkamenetek áttelepülnek, és dobja el a nyugdíjazottat, amint a régi kulcs eltűnt. Ennek az ablaknak gazdára van szüksége, mert egy elfelejtett kettős rögzítés felügyelet nélkül hagy egy kulcsot megbízhatóként. Az új kulcspárt előállító újraépítés megtöri a tiszta rögzítést, és a helyreállítás ugyanaz az eljárás a másik irányban.

Írja a változás dátumát a rögzítés mellé. A felülvizsgálati dátum nélküli rögzítés jövőbeli kiesés zavaró hibaüzenettel.

Zárja ki a kliens verzióját, mielőtt szerkesztené a bizalmat

Egy elavult kliens meghiúsulhat egy olyan hitelesítési válasz elemzésekor, amelyet az átjáró azóta megváltoztatott, és a felszíni üzenet még mindig a kapcsolatról beszél, nem az elemzőről. Hasonlítsa össze a telepített verziót azzal, amit az átjáró dokumentál, és próbáljon ki egy aktuális csomagot egy eldobható profilban, mielőtt bármilyen bizalmi beállítást módosítana.

openconnect --version

A javítás után két dolgot ellenőrizzen, ne egyet: a portál betölt az alagúton, és egy közönséges belső cím válaszol. A befejezett kézfogás csak azt bizonyítja, hogy a bizalmi döntést elfogadták.