En korrekt VPN-adgangskode kan ikke erstatte et manglende certifikat

Legitimationsoplysningerne er korrekte, profilen importeres rent, og forbindelsen fejler stadig, før godkendelsen er fuldført. På Windows kan meddelelsen være fejl 798 om et certifikat, der ikke kunne findes til EAP-metoden. På OpenVPN viser klientloggen et TLS-håndtryk, der aldrig tilfredsstiller serveren. Begge beskriver det samme manglende objekt: et klientcertifikat, som klienten skulle have fremvist.

En adgangskode beviser kendskab til en hemmelighed; et certifikat beviser besiddelse af en nøgle, og det ene erstatter ikke det andet.

Adgangskoden var aldrig problemet

Fejl 798 er et mislykket certifikatopslag. Klienten blev bedt om et certifikat, der matcher den konfigurerede godkendelsesmetode, gennemsøgte sit lager og fandt intet brugbart. Det kan betyde, at certifikatet mangler, findes uden sin private nøgle, er udløbet eller er gemt et sted, som opslaget ikke når. Et nyt forsøg med adgangskoden kan ikke ændre nogen af disse tilstande, og derfor vender fejlen tilbage med korrekte oplysninger.

Læs meddelelsen, før du handler på den. En afvisning af legitimationsoplysninger, et mislykket certifikatopslag og et mislykket TLS-håndtryk er tre forskellige fund, og kun ét af dem involverer adgangskoden.

Hvad klientlageret skal indeholde

Der er to objekter involveret. Klientcertifikatet skal være installeret for den bruger, der kører VPN-klienten, sammen med sin private nøgle, og den udstedende rod skal være betroet. En .cer-fil indeholder kun det offentlige certifikat, så den kan ikke godkende noget alene. I Windows' certifikatadministrator hører klientidentiteten til den aktuelle brugers personlige lager, og roden hører til lageret for betroede rødder.

Installation af identiteten i maskinlageret eller kun i rodlageret opfylder ikke et opslag rettet mod brugerens personlige lager. Kontroller lageret, flaget for privat nøgle og gyldighedsdatoerne sammen, og genstart derefter klienten, så den læser lageret igen.

To produkter, samme manglende legitimationsoplysning

OpenVPN-servere kræver et klientcertifikat som standard. Tilføjelse af auth-user-pass til en klient sender et brugernavn og en adgangskode, og TLS-håndtrykket beder stadig om et certifikat, så en adgangskode alene kan ikke fuldføre forbindelsen under verify-client-cert require. Serveren kan sættes til at kræve intet, hvilket gør adgangskoden til den eneste klientlegitimationsoplysning og er en reel svækkelse. Et shell-script bag auth-user-pass-verify kan validere oplysninger, og det kræver, at scriptkørsel er aktiveret, hvilket gør det til en mere risikabel konstruktion end en ordentlig godkendelsesbackend.

En profil med kun adgangskode afhænger også af skubbede valgmuligheder, som igen afhænger af, at trækmekanismen er aktiveret.

Ret ikke et manglende certifikat ved at slå kontroller fra

Fristelsen er at lempe verifikationen, så meddelelsen forsvinder. Det fjerner den kontrol, der gjorde sit arbejde, og efterlader en forbindelse, der ikke længere beviser, hvad den påstår. Hvis gatewayen for nylig har skiftet rod, skal du downloade klientpakken igen i stedet for at redigere profilen, fordi den gamle pakke stadig kan indeholde den tidligere rod. Hvis valgmuligheden for certifikatgodkendelse mangler i profileditoren, viser den installerede Windows-version måske ikke den metode; opdater systemet i stedet for at redigere XML manuelt.

Notér, hvilket lager der indeholdt certifikatet, hvilken bruger der kørte klienten, og om den private nøgle var til stede. De tre forklarer næsten hvert tilfælde af denne fejl.

Adgangskoden var fin. Den legitimationsoplysning, metoden faktisk havde brug for, var et andet sted.