Quale URI PKCS#11 serve a OpenConnect per un token?

Una smart card che contiene già la chiave giusta deve comunque ricevere l’indicazione di quale oggetto usare su di essa. OpenConnect non vuole un file .key copiato in quella situazione; vuole un URI PKCS#11 che nomini il certificato e, quando la ricerca automatica non riesce a completare il lavoro, la chiave privata accanto. La parte scomoda è che un URI sintatticamente valido non dimostra nulla. Deve nominare la registrazione di cui il gateway si fida già, non semplicemente un oggetto che la carta è disposta ad aprire.

Cosa vuole il client invece di una chiave esportata

L’opzione -c di solito accetta un percorso di file, ma quando il valore viene interpretato come URI PKCS#11, OpenConnect lo tratta come un riferimento a un oggetto dentro il token e non a un file sul disco. L’opzione -k si comporta allo stesso modo per la chiave privata. Nulla viene esportato e la chiave non lascia mai la protezione offerta dalla carta. Ciò che il client chiede a voi è un nome sul quale il modulo del token, l’archivio dei certificati e la registrazione del gateway concordano.

È su quest’ultimo vincolo che si bloccano la maggior parte dei tentativi. Un URI può essere perfettamente ben formato e comunque selezionare un certificato che il gateway rifiuterà, perché validità e pertinenza sono questioni separate. Il controllo che vale la pena fare è un confronto con il record di registrazione, non la ricerca del primo oggetto che si apre per caso.

Due URI, due compiti diversi

L’URI del certificato risponde a quale identità state rivendicando. Punta a un oggetto certificato la cui chiave pubblica e riga del soggetto corrispondono al profilo account o dispositivo emesso dall’amministratore VPN. Lo stesso certificato arriva di solito con un oggetto chiave privata memorizzato accanto, ed è quella coppia che la stretta di mano TLS richiede davvero.

L’URI della chiave risponde a dove si trova il materiale privato corrispondente quando OpenConnect non riesce a dedurlo. Con solo -c impostato, il client costruisce una ricerca della chiave dalle proprietà del certificato; fornire -k sostituisce la congettura con un riferimento esplicito a un oggetto. Il PIN del token è un terzo input, non correlato: sblocca la carta per l’operazione e non identifica mai un oggetto.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Tutto in quella stringa tra virgolette sono dati. I punti e virgola separano gli attributi dell’URI e le sequenze di escape percentuali codificano caratteri che altrimenti romperebbero l’analisi, quindi l’intero argomento deve sopravvivere intatto alla shell.

Trovare l’URI che corrisponde alla vostra registrazione

GnuTLS include p11tool, che elenca ciò a cui l’utente corrente può realmente arrivare tramite p11-kit. Iniziate con p11tool --list-tokens, poi elencate gli oggetti certificato sul token che vi interessa. Aggiungete --login quando gli oggetti compaiono solo dopo un PIN, e confrontate soggetto ed emittente con il record di registrazione invece di scegliere ciò che appare per primo.

Se il token non compare affatto, il problema sta sotto OpenConnect: p11-kit non ha alcun modulo registrato per quel middleware, oppure il modulo è registrato per un altro account. La registrazione a livello di sistema si trova sotto /etc/pkcs11/modules, e una directory per utente può contenere la stessa cosa senza toccare la copia di sistema. Verificate che il percorso del provider nel file del modulo punti a una libreria che il software del lettore ha effettivamente installato.

Quando copiate l’URI dall’elenco, tenete le virgolette attorno. I punti e virgola senza virgolette troncano l’argomento al primo attributo e il client segnala allora un oggetto che non riesce a trovare.

Quando la ricerca automatica della chiave si arrende

OpenConnect può derivare una ricerca della chiave dall’URI del certificato, ma la corrispondenza esatta che esegue dipende dalla versione, e la gestione del tipo di oggetto e dell’etichetta è cambiata nel tempo. Il consiglio di accorciare l’URI finché non funziona descrive un vecchio espediente, non un requisito. Se la ricerca derivata fallisce, nominate la chiave esplicitamente con -k invece di trasformare l’URI del certificato in qualcosa di più vago.

Confermate che la chiave esista e sia visibile con p11tool --list-keys prima di dare la colpa al client. Poi verificate che l’oggetto sia contrassegnato come utilizzabile per la firma o la decifratura, perché una chiave generata con attributi sbagliati non può completare una stretta di mano, per quanto l’URI sia corretto. Non trasferite un valore pkcs11-id serializzato da un profilo OpenVPN a un’opzione OpenConnect; i due client usano formati di identificatore diversi anche quando parlano con la stessa carta.

Se l’URI si risolve e il PIN viene accettato ma l’autenticazione fallisce ancora, smettete di regolare l’URI. Leggete l’errore del gateway stesso, perché il fallimento successivo è a monte del token.

Errori che sembrano solo problemi di URI

Un gateway che parla un altro protocollo fallirà allo stesso modo sia che il vostro URI sia corretto sia che non lo sia. OpenConnect ha sostituito il vecchio client vpnc per una ragione, e il supporto delle carte non rende compatibile un protocollo di gateway incompatibile. Confermate il protocollo atteso del server e la disposizione dell’autenticazione prima di spendere un’altra ora sugli attributi dell’oggetto.

Anche la convalida dell’identità del server è uno strato separato. Il client verifica il certificato del gateway rispetto al proprio archivio di fiducia, e quel controllo viene eseguito dopo che la carta ha già fatto la sua parte. I permessi del lettore e un servizio pcscd fermo producono lo stesso sintomo esterno, un token illeggibile, con una correzione molto più semplice.

Lavorate dall’oggetto verso l’esterno: p11tool vede il token, vede il certificato e la chiave, OpenConnect accetta l’URI, e solo allora chiedete se il gateway accetta l’identità. Ogni passo ha il proprio messaggio di errore, e ciascuno costa meno da provare del successivo.