Ett korrekt VPN-lösenord kan inte ersätta ett saknat certifikat

Inloggningsuppgifterna är korrekta, profilen importeras rent och anslutningen misslyckas ändå innan autentiseringen är klar. I Windows kan meddelandet vara fel 798, om ett certifikat som inte hittades för EAP-metoden. På OpenVPN visar klientloggen en TLS-handskakning som aldrig tillfredsställer servern. Båda beskriver samma saknade objekt: ett klientcertifikat som klienten skulle ha visat upp.

Ett lösenord bevisar kunskap om en hemlighet; ett certifikat bevisar innehav av en nyckel, och det ena ersätter inte det andra.

Lösenordet var aldrig problemet

Fel 798 är ett misslyckat certifikatsök. Klienten ombads hitta ett certifikat som matchar den konfigurerade autentiseringsmetoden, sökte igenom sitt arkiv och hittade inget användbart. Det kan betyda att certifikatet saknas, finns utan sin privata nyckel, har gått ut eller är lagrat där sökningen inte når. Ett nytt försök med lösenordet kan inte ändra något av dessa villkor, därför återkommer felet även med korrekta uppgifter.

Läs meddelandet innan du agerar på det. Ett avvisande av inloggningsuppgifter, ett misslyckat certifikatsök och ett misslyckat TLS-handskakning är tre olika fynd, och bara ett av dem rör lösenordet.

Vad klientarkivet måste innehålla

Två objekt är inblandade. Klientcertifikatet måste vara installerat för den användare som kör VPN-klienten, tillsammans med sin privata nyckel, och den utfärdande roten måste vara betrodd. En .cer-fil innehåller bara det offentliga certifikatet, så den kan inte autentisera något på egen hand. I Windows certifikathanterare hör klientidentiteten till den aktuella användarens personliga arkiv, och roten till arkivet för betrodda rötter.

Att installera identiteten i datorarkivet, eller bara i rotarkivet, uppfyller inte ett sök riktat mot användarens personliga arkiv. Kontrollera arkivet, flaggan för privat nyckel och giltighetsdatumen tillsammans och starta sedan om klienten så att den läser arkivet igen.

Två produkter, samma saknade uppgift

OpenVPN-servrar kräver ett klientcertifikat som standard. Att lägga till auth-user-pass på en klient skickar ett användarnamn och ett lösenord, och TLS-handskakningen begär fortfarande ett certifikat, så ett lösenord ensamt kan inte slutföra anslutningen under verify-client-cert require. Servern kan ställas in på att inte kräva något, vilket gör lösenordet till den enda klientuppgiften och är en verklig försvagning. Ett shellskript bakom auth-user-pass-verify kan validera uppgifter, och det kräver att skriptkörning är aktiverad, vilket gör det till en riskablare konstruktion än en ordentlig autentiseringsbackend.

En profil med bara lösenord är också beroende av påtvingade alternativ, som i sin tur är beroende av att hämtningsmekanismen är aktiverad.

Reparera inte ett saknat certifikat genom att stänga av kontroller

Frestelsen är att lätta på verifieringen så att meddelandet försvinner. Det tar bort kontrollen som gjorde sitt jobb och lämnar en anslutning som inte längre bevisar det den påstår. Om gatewayen nyligen har bytt rot, ladda ner klientpaketet igen i stället för att redigera profilen, eftersom det gamla paketet fortfarande kan innehålla den tidigare roten. Om alternativet för certifikatautentisering saknas i profilredigeraren visar kanske inte den installerade Windows-versionen den metoden; uppdatera systemet i stället för att redigera XML för hand.

Anteckna vilket arkiv som innehöll certifikatet, vilken användare som körde klienten och om den privata nyckeln fanns. De tre förklarar nästan varje fall av detta fel.

Lösenordet var i ordning. Den uppgift som metoden faktiskt behövde fanns någon annanstans.