O parolă VPN corectă nu poate înlocui un certificat lipsă

Datele de autentificare sunt corecte, profilul se importă curat, iar conexiunea eșuează în continuare înainte ca autentificarea să se încheie. În Windows, mesajul poate fi eroarea 798, despre un certificat care nu a fost găsit pentru metoda EAP. Pe OpenVPN, jurnalul clientului arată un handshake TLS care nu satisface niciodată serverul. Ambele descriu același obiect lipsă: un certificat de client pe care clientul trebuia să îl prezinte.

O parolă dovedește cunoașterea unui secret; un certificat dovedește deținerea unei chei, iar unul nu îl înlocuiește pe celălalt.

Parola nu a fost niciodată problema

Eroarea 798 este o căutare de certificat eșuată. Clientului i s-a cerut un certificat care să corespundă metodei de autentificare configurate, a căutat în magazinul său și nu a găsit nimic utilizabil. Aceasta poate însemna că certificatul lipsește, există fără cheia privată, a expirat sau este stocat unde căutarea nu ajunge. Reîncercarea parolei nu poate schimba niciuna dintre aceste condiții, de aceea eroarea revine chiar și cu date corecte.

Citiți mesajul înainte să acționați. Respingerea datelor de autentificare, o căutare de certificat eșuată și un handshake TLS eșuat sunt trei constatări diferite, iar doar una implică parola.

Ce trebuie să conțină magazinul clientului

Sunt implicate două obiecte. Certificatul de client trebuie instalat pentru utilizatorul care rulează clientul VPN, împreună cu cheia sa privată, iar rădăcina emitentă trebuie să fie de încredere. Un fișier .cer conține doar certificatul public, așa că singur nu poate autentifica nimic. În managerul de certificate Windows, identitatea clientului aparține magazinului personal al utilizatorului curent, iar rădăcina magazinului de rădăcini de încredere.

Instalarea identității în magazinul computerului, sau doar în magazinul rădăcinilor, nu satisface o căutare adresată magazinului personal al utilizatorului. Verificați împreună magazinul, marcajul cheii private și datele de valabilitate, apoi reporniți clientul ca să recitească magazinul.

Două produse, aceeași acreditare lipsă

Servere OpenVPN cer implicit un certificat de client. Adăugarea auth-user-pass la un client trimite un nume de utilizator și o parolă, iar handshake-ul TLS cere în continuare un certificat, deci o parolă singură nu poate finaliza conexiunea sub verify-client-cert require. Serverul poate fi configurat să nu ceară nimic, ceea ce face parola singura acreditare a clientului și reprezintă o reducere reală a robusteții. Un script shell din spatele auth-user-pass-verify poate valida datele de autentificare și necesită activarea execuției scripturilor, ceea ce îl face un design mai riscant decât un backend de autentificare corespunzător.

Un profil bazat doar pe parolă depinde și de opțiuni împinse, care la rândul lor depind de activarea mecanismului de extragere.

Nu reparați un certificat lipsă dezactivând verificările

Tentația este să relaxați verificarea pentru ca mesajul să dispară. Asta elimină controlul care își făcea treaba și lasă o conexiune care nu mai dovedește ce susține. Dacă poarta a schimbat recent rădăcina, descărcați din nou pachetul clientului în loc să editați profilul, deoarece pachetul vechi poate purta încă rădăcina anterioară. Dacă opțiunea de autentificare prin certificat lipsește din editorul de profiluri, este posibil ca versiunea Windows instalată să nu expună acea metodă; actualizați sistemul în loc să editați XML manual.

Notați care magazin conținea certificatul, care utilizator a rulat clientul și dacă cheia privată era prezentă. Aceste trei explică aproape fiecare caz al acestei erori.

Parola era în regulă. Acreditarea de care metoda avea nevoie cu adevărat era în altă parte.