A helyes VPN-jelszó nem pótol egy hiányzó tanúsítványt

A hitelesítő adatok helyesek, a profil tisztán importálható, és a kapcsolat mégis meghiúsul, mielőtt a hitelesítés befejeződne. Windows alatt az üzenet a 798-as hiba lehet, egy tanúsítványról, amelyet az EAP-módszerhez nem találtak. OpenVPN esetén az ügyféllog olyan TLS-kézfogást mutat, amely soha nem elégíti ki a kiszolgálót. Mindkettő ugyanazt a hiányzó objektumot írja le: egy ügyféltanúsítványt, amelyet az ügyfélnek be kellett volna mutatnia.

A jelszó egy titok ismeretét bizonyítja; a tanúsítvány egy kulcs birtoklását bizonyítja, és az egyik nem helyettesíti a másikat.

A jelszó soha nem volt a probléma

A 798-as hiba tanúsítványkeresési hiba. Az ügyféltől a beállított hitelesítési módszerhez illő tanúsítványt kértek, az átkutatta a tárolóját, és semmi használhatót nem talált. Ez azt jelentheti, hogy a tanúsítvány hiányzik, titkos kulcs nélkül van jelen, lejárt, vagy olyan helyen tárolják, ahová a keresés nem ér el. A jelszó újbóli megadása egyik feltételt sem változtathatja meg, ezért a hiba helyes hitelesítő adatokkal is visszatér.

Olvassa el az üzenetet, mielőtt cselekedne. A hitelesítő adatok elutasítása, a tanúsítványkeresés hibája és a TLS-kézfogás hibája három különböző megállapítás, és csak az egyik érinti a jelszót.

Mit kell tartalmaznia az ügyféltárolónak

Két objektum érintett. Az ügyféltanúsítványt annak a felhasználónak kell telepíteni, aki a VPN-ügyfelet futtatja, a titkos kulcsával együtt, és a kibocsátó gyökérnek megbízhatónak kell lennie. A .cer fájl csak a nyilvános tanúsítványt tartalmazza, ezért önmagában semmit nem tud hitelesíteni. A Windows tanúsítványkezelőjében az ügyfél identitása az aktuális felhasználó személyes tárolójába, a gyökéré pedig a megbízható gyökerek tárolójába tartozik.

Az identitás telepítése a géptárolóba, vagy csak a gyökértárolóba, nem elégít ki egy a felhasználó személyes tárolójára irányuló keresést. Ellenőrizze a tárolót, a titkos kulcs jelzőjét és az érvényességi dátumokat együtt, majd indítsa újra az ügyfelet, hogy újraolvassa a tárolót.

Két termék, ugyanaz a hiányzó hitelesítő adat

Az OpenVPN-kiszolgálók alapértelmezés szerint ügyféltanúsítványt követelnek. Ha az ügyfélhez auth-user-pass kerül, az felhasználónevet és jelszót küld, a TLS-kézfogás pedig továbbra is tanúsítványt kér, így a jelszó önmagában nem tudja befejezni a kapcsolatot a verify-client-cert require beállítás alatt. A kiszolgáló beállítható úgy, hogy semmit ne követeljen, ami a jelszót teszi az ügyfél egyetlen hitelesítő adatává, és ez valódi erőcsökkenés. Az auth-user-pass-verify mögötti shell-szkript hitelesítheti a hitelesítő adatokat, és ehhez engedélyezett szkriptfuttatás kell, ami kockázatosabb tervezéssé teszi, mint egy rendes hitelesítési háttérszolgáltatás.

A csak jelszóra épülő profil a továbbított beállításoktól is függ, amelyek viszont attól függenek, hogy a lehúzási mechanizmus engedélyezve van-e.

Ne javítsa a hiányzó tanúsítványt az ellenőrzések kikapcsolásával

A kísértés az, hogy lazítsuk az ellenőrzést, hogy eltűnjön az üzenet. Ez eltávolítja azt a kontrollt, amely a dolgát végezte, és olyan kapcsolatot hagy maga után, amely már nem bizonyítja azt, amit állít. Ha az átjáró nemrég megváltoztatta a gyökerét, töltse le újra az ügyfélcsomagot a profil szerkesztése helyett, mert a régi csomag még hordozhatja az előző gyökeret. Ha a tanúsítványalapú hitelesítés lehetősége hiányzik a profilszerkesztőből, előfordulhat, hogy a telepített Windows-verzió nem teszi elérhetővé ezt a módszert; frissítse a rendszert, ne szerkessze kézzel az XML-t.

Jegyezze fel, melyik tároló tartalmazta a tanúsítványt, melyik felhasználó futtatta az ügyfelet, és jelen volt-e a titkos kulcs. Ez a három magyarázza a hiba szinte minden esetét.

A jelszó rendben volt. A hitelesítő adat, amelyre a módszernek valóban szüksége volt, máshol volt.