Perché cryptoapicert fallisce in OpenVPN 3 e Connect su Windows

Copia un profilo OpenVPN 2 funzionante in un client Windows più recente, e il certificato che il vecchio client trovava da solo non viene più offerto. La riga che lo rendeva possibile è un selettore specifico di Windows che appartiene al client Community 2, e l’applicazione più recente è un altro programma con un altro percorso delle credenziali. Il profilo è invariato tranne quella riga, ed è proprio questo che rende la differenza difficile da vedere.

In quel rapporto si confondono tre livelli: il client Community, la libreria principale e l’interfaccia che qualcuno ha installato. Solo una di esse ha mai capito la direttiva.

Che cosa significa l’opzione dove esiste

Nel client Community OpenVPN 2 su Windows, cryptoapicert indica un certificato che il client deve trovare nell’archivio certificati di Windows anziché in un file. È una comodità specifica di Windows, e funziona perché quel client sa enumerare l’archivio e consegnare la chiave risultante al proprio stack TLS. La direttiva fa quindi parte del linguaggio di configurazione di quel client, non di una proprietà del protocollo OpenVPN. Nulla nel formato di trasmissione la trasporta.

Copia la stessa riga in un’altra applicazione e avrai copiato una parola che il nuovo programma può analizzare, ignorare o rifiutare. Una direttiva non è una caratteristica del protocollo, e questa non è nemmeno una caratteristica di ogni client che parla OpenVPN.

Che cosa espone invece la libreria principale

OpenVPN 3 Core è una libreria che altre applicazioni integrano, e gestisce le credenziali esterne tramite un’API anziché una ricerca nell’archivio. L’applicazione che la integra fornisce una catena di certificati e, più tardi, chiede alla libreria di firmare con una chiave esterna, e la libreria richiama l’applicazione per farlo. È un progetto più generale, e significa che l’interfaccia decide quali provider esistono. Nella gestione delle opzioni della libreria stessa, cryptoapicert compare tra le direttive non implementate, il che è coerente con questa ripartizione delle responsabilità.

L’esistenza di questi callback non significa che una data applicazione pacchettizzata enumeri l’archivio personale dell’utente corrente, supporti un particolare provider di chiavi o possa completare una richiesta di smart card. Sono proprietà dell’interfaccia, e ognuna deve essere documentata dall’interfaccia.

Che cosa fa invece l’interfaccia Windows

OpenVPN Connect segue un’altra via: l’operatore importa un file PKCS#12 contenente il certificato e la sua chiave privata in un OpenVPN Certificate Store creato per questo scopo, poi assegna il certificato esterno al profilo. È un passo di importazione deliberato, non una scoperta automatica di ciò che si trova nell’archivio personale. La distinzione conta quando qualcuno presume che un certificato installato per un altro scopo comparirà semplicemente nell’elenco del client.

L’importazione ha anche una conseguenza per la politica delle chiavi, perché esportare una chiave in un file P12 è esattamente ciò che una chiave non esportabile è progettata per impedire. È una questione di politica e non di configurazione, e merita una risposta prima che qualcuno tenti l’importazione.

Scegli un percorso coerente con la politica della chiave

Se la credenziale è esportabile e la politica consente l’importazione documentata, usa il processo di registrazione protetto dell’organizzazione e tieni il P12 temporaneo e la sua password fuori dai log e dagli script. Se la chiave non deve mai lasciare una smart card o un provider protetto, scegli una combinazione di client e provider che supporti esplicitamente questo requisito, oppure ottieni conferma dal fornitore per la versione installata. Nessuno dei due rami è un’alternativa all’altro.

Rimettere la direttiva nel profilo non può fornire un’integrazione che l’applicazione non ha. Né una versione più recente del client la aggiunge necessariamente, perché la capacità appartiene al progetto dell’interfaccia stessa.

Una volta che la chiave locale funziona, il server controlla ancora l’identità del certificato, la catena e l’autorizzazione. Una chiave locale utilizzabile e un’identità VPN accettata sono esiti separati, e tenerli separati è ciò che impedisce a un limite dell’interfaccia di trasformarsi in una politica dei certificati indebolita.