Eit riktig VPN-passord kan ikkje erstatte eit manglande sertifikat
Feil 798 er eit mislukka sertifikatoppslag, ikkje eit feil passord. Kontroller brukarlageret, den private nøkkelen og kravet til tenaren om klientsertifikat.
Påloggingsinformasjonen er riktig, profilen blir importert reint, og tilkoplinga feilar likevel før autentiseringa er fullført. På Windows kan meldinga vere feil 798, om eit sertifikat som ikkje vart funne for EAP-metoden. På OpenVPN viser klientloggen eit TLS-handtrykk som aldri tilfredsstiller tenaren. Begge skildrar det same manglande objektet: eit klientsertifikat som klienten skulle ha lagt fram.
Eit passord provar kunnskap om ein løyndom; eit sertifikat provar eigarskap til ein nøkkel, og det eine erstattar ikkje det andre.
Passordet var aldri problemet
Feil 798 er eit mislukka sertifikatoppslag. Klienten vart beden om eit sertifikat som samsvarar med den konfigurerte autentiseringsmetoden, søkte gjennom lageret sitt og fann ingenting brukbart. Det kan tyde på at sertifikatet manglar, finst utan den private nøkkelen, er utløpt eller er lagra der oppslaget ikkje når. Eit nytt forsøk med passordet kan ikkje endre noko av desse tilhøva, og difor kjem feilen tilbake sjølv med riktig påloggingsinformasjon.
Les meldinga før du handlar på henne. Ei avvising av påloggingsinformasjon, eit mislukka sertifikatoppslag og eit mislukka TLS-handtrykk er tre ulike funn, og berre eitt av dei gjeld passordet.
Kva klientlageret må innehalde
To objekt er involverte. Klientsertifikatet må vere installert for brukaren som køyrer VPN-klienten, saman med sin private nøkkel, og den utstedande rota må vere klarert. Ei .cer-fil inneheld berre det offentlege sertifikatet, så ho kan ikkje autentisere noko åleine. I Windows-sertifikatbehandlaren høyrer klientidentiteten til det personlege lageret til den gjeldande brukaren, og rota til lageret for klarerte røter.
Installasjon av identiteten i maskinlageret, eller berre i rotlageret, oppfyller ikkje eit oppslag retta mot det personlege lageret til brukaren. Kontroller lageret, flagget for privat nøkkel og gyldigheitsdatoane saman, og start deretter klienten på nytt slik at han les lageret igjen.
To produkt, same manglande påloggingsinformasjon
OpenVPN-tenarar krev eit klientsertifikat som standard. Å leggje til auth-user-pass på ein klient sender eit brukarnamn og eit passord, og TLS-handtrykket ber framleis om eit sertifikat, så eit passord åleine kan ikkje fullføre tilkoplinga under verify-client-cert require. Tenaren kan setjast til å ikkje krevje noko, noko som gjer passordet til den einaste klientpåloggingsinformasjonen og er ei reell svekking. Eit shell-skript bak auth-user-pass-verify kan validere påloggingsinformasjon, og det krev at skriptkøyring er slått på, noko som gjer det til ein meir risikabel konstruksjon enn ein skikkeleg autentiseringsbackend.
Ein profil med berre passord er også avhengig av dytta val, som igjen er avhengige av at hentemekanismen er slått på.
Ikkje reparer eit manglande sertifikat ved å slå av kontrollar
Freistinga er å lempe på verifiseringa slik at meldinga forsvinn. Det fjernar kontrollen som gjorde jobben sin, og etterlèt ei tilkopling som ikkje lenger provar det ho påstår. Dersom gatewayen nyleg har bytt rot, last ned klientpakka på nytt i staden for å redigere profilen, fordi den gamle pakka framleis kan innehalde den førre rota. Dersom alternativet for sertifikatautentisering manglar i profilredigeraren, viser kanskje ikkje den installerte Windows-versjonen den metoden; oppdater systemet i staden for å redigere XML for hand.
Noter kva lager som inneheldt sertifikatet, kva brukar som køyrde klienten og om den private nøkkelen var til stades. Dei tre forklarar nesten kvart tilfelle av denne feilen.
Passordet var i orden. Påloggingsinformasjonen metoden faktisk trengde, var ein annan stad.