'n Korrekte VPN-wagwoord kan nie 'n ontbrekende sertifikaat vervang nie

Die geloofsbriewe is reg, die profiel voer skoon in, en die verbinding misluk steeds voordat verifikasie voltooi is. Op Windows kan die boodskap fout 798 wees, oor 'n sertifikaat wat nie vir die EAP-metode gevind kon word nie. Op OpenVPN wys die kliëntlog 'n TLS-handshake wat nooit die bediener tevrede stel nie. Albei beskryf dieselfde ontbrekende objek: 'n kliëntsertifikaat wat die kliënt veronderstel was om te toon.

'n Wagwoord bewys kennis van 'n geheim; 'n sertifikaat bewys besit van 'n sleutel, en die een vervang nie die ander nie.

Die wagwoord was nooit die probleem nie

Fout 798 is 'n mislukte sertifikaatsoektog. Die kliënt is gevra vir 'n sertifikaat wat by die gekonfigureerde verifikasiemetode pas, het sy store deursoek en niks bruikbaars gevind. Dit kan beteken die sertifikaat ontbreek, is teenwoordig sonder sy private sleutel, het verval, of is gestoor waar die soektog nie bykom nie. Om die wagwoord weer te probeer kan nie een van daardie toestande verander nie, en daarom bly die fout opduik selfs met korrekte geloofsbriewe.

Lees die boodskap voordat jy daarop reageer. 'n Geloofsbriefverwerping, 'n mislukte sertifikaatsoektog en 'n mislukte TLS-handshake is drie verskillende bevindings, en net een daarvan het met die wagwoord te make.

Wat die kliëntstore moet bevat

Twee objekte is betrokke. Die kliëntsertifikaat moet vir die gebruiker wat die VPN-kliënt bestuur, geïnstalleer wees, saam met sy private sleutel, en die uitreikende wortel moet vertrou word. 'n .cer-lêer bevat net die openbare sertifikaat, so dit kan niks op sy eie verifieer nie. In die Windows-sertifikaatbestuurder hoort die kliëntidentiteit in die huidige gebruiker se persoonlike store, en die wortel hoort in die vertroude wortelstore.

Om die identiteit in die masjienstore te installeer, of net in die wortelstore, voldoen nie aan 'n soektog wat op die gebruiker se persoonlike store gemik is nie. Kontroleer die store, die private-sleutel-vlag en die geldigheidsdatums saam, en herbegin dan die kliënt sodat dit die store weer lees.

Twee produkte, dieselfde ontbrekende geloofsbrief

OpenVPN-bediener vereis by verstek 'n kliëntsertifikaat. As jy auth-user-pass by 'n kliënt voeg, stuur dit 'n gebruikersnaam en wagwoord, en die TLS-handshake vra steeds 'n sertifikaat, dus 'n wagwoord alleen kan die verbinding onder verify-client-cert require nie voltooi nie. Die bediener kan ingestel word om niks te vereis nie, wat die wagwoord die enigste kliëntgeloofsbrief maak en 'n werklike verswakking is. 'n Shell-skrip agter auth-user-pass-verify kan geloofsbriewe valideer, en dit vereis dat skripuitvoering geaktiveer is, wat dit 'n riskanter ontwerp maak as 'n behoorlike verifikasiemeganisme.

'n Profiel wat net op 'n wagwoord staatmaak, hang ook van gestuurde opsies af, wat op hul beurt afhang daarvan dat die trek-meganisme geaktiveer is.

Moet 'n ontbrekende sertifikaat nie regstel deur kontroles af te skakel nie

Die versoeking is om verifikasie te verslap sodat die boodskap verdwyn. Dit verwyder die kontrole wat sy werk gedoen het en laat 'n verbinding wat nie meer bewys wat dit beweer nie. As die gateway onlangs sy wortel verander het, laai die kliëntpakket weer af eerder as om die profiel te wysig, want die ou pakket kan steeds die vorige wortel bevat. As die sertifikaatverifikasiopsie in die profielredigeerder ontbreek, is dit moontlik dat die geïnstalleerde Windows-weergawe daardie metode nie blootlê nie; dateer eerder die stelsel op as om XML met die hand te wysig.

Teken aan watter store die sertifikaat bevat het, watter gebruiker die kliënt bestuur het en of die private sleutel teenwoordig was. Daardie drie verduidelik byna elke geval van hierdie mislukking.

Die wagwoord was reg. Die geloofsbrief wat die metode eintlik nodig gehad het, was elders.