Perché OpenVPN chiede ancora un file di chiave privata quando è presente un token

Collegate il token, lo strumento del fornitore stesso lo vede, e il client VPN chiede ancora un file di chiave privata. Quel messaggio non prova che il token non sia supportato. Di solito significa che il profilo non ha mai detto al client di usare il token, così è tornato agli input di certificato e chiave che si aspetta per impostazione predefinita.

Due valori distinti devono essere corretti prima che questo ripiego si fermi: il fornitore che espone il token e l’identità del certificato al suo interno. Sono forniti da opzioni diverse ed è facile confonderli.

Il client chiede un file perché il profilo lo impone

Un profilo predefinito si aspetta un file di certificato e un file di chiave privata, oppure un singolo pacchetto PKCS#12. Quando questi input mancano il client non ha nulla da caricare e si comporta quasi come con un file assente, per cui il sintomo viene letto come un percorso rotto e non come un meccanismo mancante. Il percorso PKCS#11 sostituisce quegli input invece di integrarli, quindi un profilo che nomina ancora un file di chiave continuerà a usare il file. Rimuovete deliberatamente gli input di file e lasciate che il token fornisca entrambe le metà.

L’opzione del fornitore nomina una libreria middleware, non un dispositivo e non un certificato. Che un client pacchettizzato possa caricare quella libreria dipende da come è stato compilato, incluso il supporto opzionale di p11-kit che alcune build abilitano e altre omettono. Un tutorial generico non può dirvi quale disposizione abbia il vostro pacchetto.

L’identità serializzata è un valore diverso

L’identità del certificato è una lunga stringa serializzata prodotta dal processo di scoperta, e non è il percorso della libreria, né il PIN del token, né il nome dell’account VPN. Spesso contiene caratteri che richiedono virgolette, e un valore senza virgolette può essere troncato o letto male senza un errore chiaro. Usate l’opzione scoperta dell’identità del client stesso per elencare ciò che il token espone, poi copiate esattamente la voce desiderata. Scegliere il primo oggetto dell’elenco è il modo in cui un dispositivo finisce per presentare il certificato sbagliato.

L’output della scoperta risponde anche a una domanda precedente: se il token sia visibile o meno attraverso quel fornitore. Se non elenca nulla, il problema è a monte del client VPN e appartiene al middleware.

Il processo che si connette deve raggiungere il token

Un’operazione sul token che funziona nella vostra sessione desktop non prova nulla su un servizio di sistema. Il servizio può essere eseguito come un altro utente, in uno spazio dei nomi di mount diverso, con un percorso dei moduli che omette la libreria del fornitore, o senza il permesso di aprire il nodo del dispositivo. Identificate quale processo detiene realmente la connessione e provate da quel contesto.

La gestione del PIN merita una decisione a sé. L’implementazione di riferimento offre una cache del PIN e un percorso di autenticazione protetto, ed entrambi esistono perché un operatore scelga un flusso di lavoro invece di inventarlo. Non trasformate un requisito senza supervisione in un PIN in chiaro dentro un profilo condiviso, perché così si scambia la protezione del token con la comodità. Dove il token vieta l’esportazione della chiave, la firma avviene sul dispositivo e il PIN è l’unico segreto locale. Trattatelo con la cura che ciò implica.

Ciò che il token non sostituisce

Il token autentica il client secondo la policy distribuita e non sostituisce i controlli del client sul server. Un certificato selezionato con successo non è il permesso di accettare un certificato gateway inatteso, e le due verifiche proteggono direzioni opposte.

L’iscrizione deve ancora avvenire presso l’emittente, e il gateway deve ancora autorizzare l’identità.

Per l’accettazione, separate le fasi: il fornitore si carica, il certificato previsto viene trovato, la chiave privata viene usata con autorizzazione locale, il VPN si autentica e l’operazione sulla risorsa riesce. Fermatevi alla prima fase che fallisce invece di scorrere le password e reinstallare lo stack crittografico.

Registrate le versioni, la proprietà dei moduli, l’identificatore pubblico scelto e gli errori ripuliti, e lasciate i PIN e i pacchetti di credenziali fuori da quel registro.