Il certificato è visibile in Windows ma OpenVPN non può usarne la chiave

Il certificato è visibile nel visualizzatore di certificati di Windows e il client continua a non poterlo usare. Vedere un certificato dimostra solo che esiste un oggetto pubblico in un archivio. Non dimostra che il processo di connessione trovi la chiave privata corrispondente né che abbia il permesso di usarla.

Tre oggetti devono allinearsi. Il certificato selezionato, la chiave privata che sta dietro e l’account con cui viene eseguito il client sono cose separate, e ciascuna può fallire per conto proprio.

Tre oggetti, tre risposte

La versione community di OpenVPN su Windows documenta un selettore d’archivio CryptoAPI, cryptoapicert, che accetta un’impronta. Il valore deve indicare il certificato che intendete davvero usare, non un altro con un nome simile. Altre applicazioni basate su OpenVPN possono avere un modello di importazione del tutto diverso, quindi il selettore è una prova solo per la build che lo documenta. Confermate che il vostro client implementi il meccanismo prima di fare debug di qualsiasi cosa a valle.

Se la build non supporta il selettore, la soluzione è un altro formato di profilo, non un altro certificato.

Il selettore risolve sull’identità giusta

Un certificato pubblico può essere importato senza la sua chiave privata. Il visualizzatore lo mostra in entrambi i casi, ed è per questo che il guasto sembra un client che ignora un certificato palesemente presente. Controllate l’associazione della chiave, non solo la presenza della voce.

Un certificato rinnovato aggiunge una seconda trappola. Entrambe le voci possono restare nell’archivio mentre il profilo nomina ancora l’impronta più vecchia, e il client continua a selezionare l’identità che volevate ritirare.

Controllate a quale identità risolve il selettore prima di guardare i permessi. Un’impronta sbagliata fallisce allo stesso modo di una chiave assente.

Questo account può usare la chiave

L’accesso alla chiave è per account. Un servizio, un’attività pianificata e una sessione desktop interattiva possono avere viste diverse dell’archivio e permessi diversi per usare una chiave privata. Il fatto che il certificato sia visibile nella vostra sessione non dice nulla sull’account del servizio.

Una chiave supportata dall’hardware può richiedere il suo provider e un passaggio di conferma. Un servizio che non può mostrare una richiesta non viene salvato esportando la chiave in un file semplice.

Leggete l’errore locale prima di cambiare qualcosa. Un errore di selezione, un errore di firma e un rifiuto remoto sono tre esiti diversi. Solo i primi due sono locali. Il terzo significa che la chiave ha funzionato e che il server ha deciso contro il certificato.

L’uso locale non è accettazione remota

Un successo locale non è un’autorizzazione. Dopo che il client ha firmato con la sua chiave, il server valuta ancora l’emittente, la finestra di validità, il ruolo e la sua politica di accesso. Un certificato diverso della stessa CA non porta automaticamente gli stessi diritti VPN.

Il server ha bisogno della catena di fiducia, non di una copia della chiave privata del client. Inviare la chiave al server non è mai la riparazione di un problema di verifica.

Affrontate il guasto in ordine

Conservate il testo esatto dell’errore. Un permesso mancante sulla chiave non deve diventare un cambio di CA, e un rifiuto remoto non deve diventare una riparazione dell’archivio. Ciascuno ha le proprie prove.

Lavorate nell’ordine in cui il guasto compare: selettore, chiave, account, poi politica del server. La referenza community del client documenta il selettore d’archivio di Windows per la versione che eseguite.