Una contrasenya VPN correcta no pot substituir un certificat que falta

Les credencials són correctes, el perfil s'importa net i la connexió encara falla abans que l'autenticació es completi. A Windows el missatge pot ser l'error 798, sobre un certificat que no s'ha trobat per al mètode EAP. A OpenVPN el registre del client mostra un handshake TLS que mai no satisfà el servidor. Tots dos descriuen el mateix objecte absent: un certificat de client que el client havia de presentar.

Una contrasenya demostra el coneixement d'un secret; un certificat demostra la possessió d'una clau, i l'un no substitueix l'altre.

La contrasenya mai no era el problema

L'error 798 és una fallada de cerca de certificat. Al client se li va demanar un certificat que coincidís amb el mètode d'autenticació configurat, va registrar el seu magatzem i no va trobar res utilitzable. Això pot significar que el certificat és absent, que hi és sense la clau privada, que ha caducat o que està desat on la cerca no arriba. Tornar a provar la contrasenya no pot canviar cap d'aquestes condicions, i per això l'error torna amb credencials correctes.

Llegiu el missatge abans d'actuar. Un rebuig de credencials, una fallada de cerca de certificat i una fallada de handshake TLS són tres troballes diferents, i només una afecta la contrasenya.

Què ha de contenir el magatzem del client

Hi intervenen dos objectes. El certificat de client s'ha d'instal·lar per a l'usuari que executa el client VPN, amb la seva clau privada, i l'arrel emissora ha de ser de confiança. Un fitxer .cer només conté el certificat públic, així que no pot autenticar res per si sol. Al gestor de certificats de Windows, la identitat del client pertany al magatzem personal de l'usuari actual, i l'arrel pertany al magatzem d'arrels de confiança.

Instal·lar la identitat al magatzem de l'equip, o només al magatzem d'arrels, no satisfà una cerca adreçada al magatzem personal de l'usuari. Comproveu el magatzem, l'indicador de clau privada i les dates de validesa alhora, i després reinicieu el client perquè torni a llegir el magatzem.

Dos productes, la mateixa credencial absent

Els servidors OpenVPN requereixen un certificat de client per defecte. Afegir auth-user-pass a un client envia un nom d'usuari i una contrasenya, i el handshake TLS encara demana un certificat, així que una contrasenya sola no pot completar la connexió sota verify-client-cert require. El servidor es pot configurar perquè no en requereixi cap, cosa que fa de la contrasenya l'única credencial del client i és una reducció real de la força. Un script de shell darrere de auth-user-pass-verify pot validar credencials, i requereix que l'execució d'scripts estigui habilitada, cosa que el converteix en un disseny més arriscat que un bon backend d'autenticació.

Un perfil només amb contrasenya també depèn d'opcions empenyades, que al seu torn depenen que el mecanisme d'estirada estigui habilitat.

No arregleu un certificat absent desactivant les comprovacions

La temptació és relaxar la verificació perquè el missatge desaparegui. Això elimina el control que feia la seva feina i deixa una connexió que ja no demostra el que afirma. Si la passarel·la ha canviat recentment la seva arrel, torneu a baixar el paquet del client en lloc d'editar el perfil, perquè el paquet antic encara pot portar l'arrel anterior. Si l'opció d'autenticació per certificat falta a l'editor de perfils, potser la versió de Windows instal·lada no exposa aquest mètode; actualitzeu el sistema en lloc d'editar l'XML a mà.

Anoteu quin magatzem contenia el certificat, quin usuari va executar el client i si la clau privada hi era. Aquests tres punts expliquen gairebé tots els casos d'aquesta fallada.

La contrasenya era correcta. La credencial que el mètode necessitava de debò era en un altre lloc.