Et riktig VPN-passord kan ikke erstatte et manglende sertifikat

Påloggingsinformasjonen er riktig, profilen importeres rent, og tilkoblingen feiler likevel før autentiseringen er fullført. På Windows kan meldingen være feil 798, om et sertifikat som ikke ble funnet for EAP-metoden. På OpenVPN viser klientloggen et TLS-håndtrykk som aldri tilfredsstiller serveren. Begge beskriver det samme manglende objektet: et klientsertifikat som klienten skulle ha lagt fram.

Et passord beviser kunnskap om en hemmelighet; et sertifikat beviser eierskap til en nøkkel, og det ene erstatter ikke det andre.

Passordet var aldri problemet

Feil 798 er et mislykket sertifikatoppslag. Klienten ble bedt om et sertifikat som samsvarer med den konfigurerte autentiseringsmetoden, søkte gjennom lageret sitt og fant ingenting brukbart. Det kan bety at sertifikatet mangler, finnes uten den private nøkkelen, er utløpt eller er lagret der oppslaget ikke når. Et nytt forsøk med passordet kan ikke endre noen av disse forholdene, og derfor kommer feilen tilbake selv med riktig påloggingsinformasjon.

Les meldingen før du handler på den. En avvisning av påloggingsinformasjon, et mislykket sertifikatoppslag og et mislykket TLS-håndtrykk er tre forskjellige funn, og bare ett av dem gjelder passordet.

Hva klientlageret må inneholde

To objekter er involvert. Klientsertifikatet må være installert for brukeren som kjører VPN-klienten, sammen med sin private nøkkel, og den utstedende roten må være klarert. En .cer-fil inneholder bare det offentlige sertifikatet, så den kan ikke autentisere noe alene. I Windows-sertifikatbehandleren hører klientidentiteten til den gjeldende brukerens personlige lager, og roten til lageret for klarerte røtter.

Installasjon av identiteten i maskinlageret, eller bare i rotlageret, oppfyller ikke et oppslag rettet mot brukerens personlige lager. Kontroller lageret, flagget for privat nøkkel og gyldighetsdatoene sammen, og start deretter klienten på nytt slik at den leser lageret igjen.

To produkter, samme manglende påloggingsinformasjon

OpenVPN-servere krever et klientsertifikat som standard. Å legge til auth-user-pass på en klient sender et brukernavn og et passord, og TLS-håndtrykket ber fortsatt om et sertifikat, så et passord alene kan ikke fullføre tilkoblingen under verify-client-cert require. Serveren kan settes til å ikke kreve noe, noe som gjør passordet til den eneste klientpåloggingsinformasjonen og er en reell svekkelse. Et shell-skript bak auth-user-pass-verify kan validere påloggingsinformasjon, og det krever at skriptkjøring er aktivert, noe som gjør det til en mer risikabel konstruksjon enn en skikkelig autentiseringsbackend.

En profil med bare passord avhenger også av dyttede valg, som igjen avhenger av at hentemekanismen er aktivert.

Ikke reparer et manglende sertifikat ved å slå av kontroller

Fristelsen er å lempe på verifiseringen slik at meldingen forsvinner. Det fjerner kontrollen som gjorde jobben sin, og etterlater en tilkobling som ikke lenger beviser det den påstår. Hvis gatewayen nylig har byttet rot, last ned klientpakken på nytt i stedet for å redigere profilen, fordi den gamle pakken fortsatt kan inneholde den forrige roten. Hvis alternativet for sertifikatautentisering mangler i profileditoren, viser kanskje ikke den installerte Windows-versjonen den metoden; oppdater systemet i stedet for å redigere XML for hånd.

Noter hvilket lager som inneholdt sertifikatet, hvilken bruker som kjørte klienten og om den private nøkkelen var til stede. De tre forklarer nesten hvert tilfelle av denne feilen.

Passordet var i orden. Påloggingsinformasjonen metoden faktisk trengte, var et annet sted.