Taisyklingas VPN slaptažodis nepakeičia trūkstamo sertifikato

Prisijungimo duomenys teisingi, profilis importuojamas švariai, o ryšys vis tiek nutrūksta prieš baigiantis autentifikacijai. Windows aplinkoje pranešimas gali būti 798 klaida apie sertifikatą, kurio nepavyko rasti EAP metodui. Naudojant OpenVPN kliento žurnale matomas TLS rankos paspaudimas, kuris niekada netenkina serverio. Abu apibūdina tą patį trūkstamą objektą: kliento sertifikatą, kurį klientas turėjo pateikti.

Slaptažodis įrodo žinojimą paslapties; sertifikatas įrodo rakto turėjimą, ir vienas nepakeičia kito.

Slaptažodis niekada nebuvo problema

798 klaida yra sertifikato paieškos nesėkmė. Kliento buvo paprašyta sertifikato, atitinkančio sukonfigūruotą autentifikavimo metodą, jis peržiūrėjo savo saugyklą ir nerado nieko tinkamo. Tai gali reikšti, kad sertifikato nėra, jis yra be privataus rakto, pasibaigęs arba saugomas ten, kur paieška nepasiekia. Bandymas dar kartą įvesti slaptažodį negali pakeisti nė vienos iš šių sąlygų, todėl klaida grįžta net ir su teisingais duomenimis.

Perskaitykite pranešimą prieš imdamiesi veiksmų. Prisijungimo duomenų atmetimas, sertifikato paieškos nesėkmė ir TLS rankos paspaudimo nesėkmė yra trys skirtingi radiniai, ir tik vienas jų susijęs su slaptažodžiu.

Ką turi turėti kliento saugykla

Dalyvauja du objektai. Kliento sertifikatas turi būti įdiegtas naudotojui, kuris paleidžia VPN klientą, kartu su privačiuoju raktu, o išduodanti šaknis turi būti patikima. .cer failas turi tik viešąjį sertifikatą, todėl pats savaime negali nieko autentifikuoti. Windows sertifikatų tvarkyklėje kliento tapatybė priklauso dabartinio naudotojo asmeninei saugyklai, o šaknis – patikimų šaknų saugyklai.

Tapatybės įdiegimas kompiuterio saugykloje arba vien tik šaknų saugykloje netenkina paieškos, nukreiptos į naudotojo asmeninę saugyklą. Patikrinkite saugyklą, privataus rakto žymą ir galiojimo datas kartu, tada iš naujo paleiskite klientą, kad jis iš naujo perskaitytų saugyklą.

Du produktai, tas pats trūkstamas duomuo

OpenVPN serveriai pagal numatytuosius nustatymus reikalauja kliento sertifikato. Pridėjus auth-user-pass prie kliento siunčiamas naudotojo vardas ir slaptažodis, o TLS rankos paspaudimas vis tiek prašo sertifikato, todėl vien slaptažodis negali užbaigti ryšio pagal verify-client-cert require. Serverį galima nustatyti nereikalauti nieko, o tai slaptažodį paverčia vieninteliu kliento duomeniu ir yra tikras stiprumo sumažėjimas. Shell scenarijus už auth-user-pass-verify gali tikrinti duomenis, ir jam reikia įjungto scenarijų vykdymo, todėl tai rizikingesnis sprendimas nei tinkama autentifikavimo sistema.

Profilis, pagrįstas vien slaptažodžiu, taip pat priklauso nuo stumiamų parinkčių, kurios savo ruožtu priklauso nuo to, ar įjungtas traukimo mechanizmas.

Netaisykite trūkstamo sertifikato išjungdami patikras

Pagunda – sušvelninti tikrinimą, kad pranešimas išnyktų. Tai pašalina kontrolę, kuri atliko savo darbą, ir palieka ryšį, kuris nebeįrodo to, ką teigia. Jei tarpinė neseniai pakeitė savo šaknį, atsisiųskite kliento paketą iš naujo, o ne redaguokite profilį, nes sename pakete gali dar būti ankstesnė šaknis. Jei profilio rengyklėje nėra sertifikato autentifikavimo parinkties, galbūt įdiegta Windows versija to metodo nerodo; atnaujinkite sistemą, o ne redaguokite XML rankiniu būdu.

Užrašykite, kurioje saugykloje buvo sertifikatas, kuris naudotojas paleido klientą ir ar buvo privatusis raktas. Šie trys paaiškina beveik kiekvieną šios nesėkmės atvejį.

Slaptažodis buvo geras. Duomuo, kurio metodui iš tikrųjų reikėjo, buvo kitur.