Una password VPN corretta non può sostituire un certificato mancante

Le credenziali sono corrette, il profilo viene importato senza problemi e la connessione fallisce comunque prima che l’autenticazione sia completata. In Windows il messaggio può essere l’errore 798, relativo a un certificato non trovato per il metodo EAP. Su OpenVPN il registro del client mostra una stretta di mano TLS che non soddisfa mai il server. Entrambi descrivono lo stesso oggetto mancante: un certificato client che il client avrebbe dovuto presentare.

Una password dimostra la conoscenza di un segreto; un certificato dimostra il possesso di una chiave, e l’uno non sostituisce l’altro.

La password non è mai stata il problema

L’errore 798 è un errore di ricerca del certificato. Al client è stato chiesto un certificato corrispondente al metodo di autenticazione configurato, ha esaminato il proprio archivio e non ha trovato nulla di utilizzabile. Ciò può significare che il certificato è assente, presente senza la sua chiave privata, scaduto o conservato dove la ricerca non arriva. Riprovare la password non può cambiare nessuna di queste condizioni, per questo l’errore ritorna anche con credenziali corrette.

Leggi il messaggio prima di agire. Un rifiuto delle credenziali, un errore di ricerca del certificato e un errore di stretta di mano TLS sono tre riscontri diversi, e solo uno riguarda la password.

Cosa deve contenere l’archivio del client

Sono coinvolti due oggetti. Il certificato client deve essere installato per l’utente che esegue il client VPN, con la sua chiave privata, e la radice emittente deve essere attendibile. Un file .cer contiene solo il certificato pubblico, quindi da solo non può autenticare nulla. Nel gestore certificati di Windows, l’identità del client appartiene all’archivio personale dell’utente corrente, e la radice all’archivio delle radici attendibili.

Installare l’identità nell’archivio del computer, o solo in quello delle radici, non soddisfa una ricerca mirata all’archivio personale dell’utente. Controlla insieme l’archivio, l’indicatore della chiave privata e le date di validità, poi riavvia il client perché rilegga l’archivio.

Due prodotti, la stessa credenziale mancante

I server OpenVPN richiedono un certificato client per impostazione predefinita. Aggiungere auth-user-pass a un client invia un nome utente e una password, e la stretta di mano TLS chiede comunque un certificato, quindi una password da sola non può completare la connessione sotto verify-client-cert require. Il server può essere configurato per non richiederne alcuno, il che rende la password l’unica credenziale del client ed è una reale riduzione della sicurezza. Uno script shell dietro auth-user-pass-verify può convalidare le credenziali, e richiede che l’esecuzione degli script sia abilitata, il che lo rende un progetto più rischioso di un backend di autenticazione adeguato.

Un profilo basato solo sulla password dipende anche da opzioni inviate, che a loro volta dipendono dall’attivazione del meccanismo di recupero.

Non correggere un certificato mancante disattivando i controlli

La tentazione è allentare la verifica affinché il messaggio scompaia. Questo rimuove il controllo che stava facendo il suo lavoro e lascia una connessione che non dimostra più ciò che dichiara. Se il gateway ha cambiato di recente la sua radice, scarica di nuovo il pacchetto client invece di modificare il profilo, perché il vecchio pacchetto potrebbe portare ancora la radice precedente. Se l’opzione di autenticazione tramite certificato manca nell’editor dei profili, forse la versione di Windows installata non espone quel metodo; aggiorna il sistema invece di modificare l’XML a mano.

Annota quale archivio conteneva il certificato, quale utente ha eseguito il client e se la chiave privata era presente. Questi tre elementi spiegano quasi ogni caso di questo errore.

La password andava bene. La credenziale di cui il metodo aveva davvero bisogno era altrove.