Ce URI PKCS#11 are nevoie OpenConnect pentru un token?

Un card inteligent care conţine deja cheia corectă trebuie totuşi înştiinţat ce obiect de pe el să folosească. OpenConnect nu vrea un fişier .key copiat în această situaţie; vrea un URI PKCS#11 care numeşte certificatul şi, când căutarea automată nu poate termina treaba, cheia privată de lângă el. Partea incomodă este că un URI sintactic valid nu dovedeşte nimic. Trebuie să numească înregistrarea în care gateway-ul are deja încredere, nu doar un obiect pe care cardul este dispus să îl deschidă.

Ce vrea clientul în locul unei chei exportate

Opţiunea -c ia de obicei o cale de fişier, dar când valoarea este interpretată ca URI PKCS#11, OpenConnect o tratează ca referinţă la un obiect din interiorul tokenului, nu la un fişier de pe disc. Opţiunea -k se comportă la fel pentru cheia privată. Nimic nu este exportat, iar cheia nu părăseşte niciodată protecţia oferită de card. Ce are nevoie clientul de la dumneavoastră este un nume asupra căruia modulul tokenului, magazinul de certificate şi înregistrarea din gateway sunt de acord.

La această ultimă constrângere se blochează majoritatea încercărilor. Un URI poate fi perfect bine format şi totuşi să selecteze un certificat pe care gateway-ul îl va respinge, pentru că validitatea şi relevanţa sunt întrebări separate. Verificarea care merită făcută este o comparaţie cu înregistrarea din evidenţă, nu o căutare a primului obiect care se deschide din întâmplare.

Două URI, două sarcini diferite

URI-ul certificatului răspunde la ce identitate revendicaţi. Indică un obiect de certificat a cărui cheie publică şi linie de subiect corespund profilului de cont sau de dispozitiv emis de administratorul VPN. Acelaşi certificat vine de obicei cu un obiect de cheie privată stocat alături, iar acea pereche este ceea ce are nevoie de fapt strângerea de mână TLS.

URI-ul cheii răspunde la unde se află materialul privat corespunzător când OpenConnect nu îl poate deduce. Cu doar -c setat, clientul construieşte o căutare a cheii din proprietăţile certificatului; furnizarea lui -k înlocuieşte presupunerea cu o referinţă explicită la obiect. PIN-ul tokenului este a treia intrare, fără legătură: deblochează cardul pentru operaţiune şi nu identifică niciodată un obiect.

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

Tot ce se află în acel şir între ghilimele sunt date. Punctele şi virgulele separă atributele URI, iar secvenţele de escape procentuale codifică caractere care altfel ar rupe analiza, aşa că întregul argument trebuie să treacă intact prin shell.

Găsirea URI-ului care corespunde înregistrării dumneavoastră

GnuTLS livrează p11tool, care listează la ce poate ajunge efectiv utilizatorul curent prin p11-kit. Începeţi cu p11tool --list-tokens, apoi listaţi obiectele de certificat de pe tokenul care vă interesează. Adăugaţi --login când obiectele apar doar după un PIN şi comparaţi subiectul şi emitentul cu înregistrarea din evidenţă, în loc să alegeţi ce apare primul.

Dacă tokenul nu apare deloc, problema se află sub OpenConnect: p11-kit nu are niciun modul înregistrat pentru acel middleware, sau modulul este înregistrat pentru alt cont. Înregistrarea la nivel de sistem se află sub /etc/pkcs11/modules, iar un director pentru fiecare utilizator poate conţine acelaşi lucru fără să atingă copia de sistem. Verificaţi că calea furnizorului din fişierul modulului indică o bibliotecă pe care software-ul cititorului a instalat-o efectiv.

Când copiaţi URI-ul din listă, păstraţi ghilimelele din jur. Punctele şi virgulele fără ghilimele trunchiază argumentul la primul atribut, iar clientul raportează apoi un obiect pe care nu îl poate găsi.

Când căutarea automată a cheii renunţă

OpenConnect poate deriva o căutare a cheii din URI-ul certificatului, dar potrivirea exactă pe care o face depinde de versiune, iar tratarea tipului de obiect şi a etichetei s-a schimbat în timp. Sfatul de a scurta URI-ul până funcţionează descrie un ocol vechi, nu o cerinţă. Dacă căutarea derivată eşuează, numiţi cheia explicit cu -k în loc să transformaţi URI-ul certificatului în ceva mai vag.

Confirmaţi că cheia există şi este vizibilă cu p11tool --list-keys înainte de a da vina pe client. Apoi verificaţi că obiectul este marcat ca utilizabil pentru semnare sau decriptare, fiindcă o cheie generată cu atribute greşite nu poate finaliza o strângere de mână, oricât de corect ar fi URI-ul. Nu transferaţi o valoare pkcs11-id serializată dintr-un profil OpenVPN într-o opţiune OpenConnect; cei doi clienţi folosesc formate diferite de identificator chiar şi când vorbesc cu acelaşi card.

Dacă URI-ul se rezolvă şi PIN-ul este acceptat, dar autentificarea tot eşuează, opriţi reglarea URI-ului. Citiţi eroarea gateway-ului însuşi, pentru că următorul eşec este deasupra tokenului.

Eşecuri care doar par probleme de URI

Un gateway care vorbeşte alt protocol va eşua la fel, indiferent dacă URI-ul dumneavoastră este corect sau nu. OpenConnect a înlocuit vechiul client vpnc dintr-un motiv, iar suportul pentru carduri nu face compatibil un protocol de gateway incompatibil. Confirmaţi protocolul aşteptat al serverului şi aranjamentul de autentificare înainte de a mai petrece o oră pe atributele obiectului.

Validarea identităţii serverului este şi ea un strat separat. Clientul verifică certificatul gateway-ului faţă de magazinul său de încredere, iar verificarea rulează după ce cardul şi-a făcut deja partea. Permisiunile cititorului şi un serviciu pcscd oprit produc acelaşi simptom exterior, un token ilizibil, cu o remediere mult mai simplă.

Lucraţi de la obiect spre exterior: vede p11tool tokenul, vede certificatul şi cheia, acceptă OpenConnect URI-ul, şi abia apoi întrebaţi dacă gateway-ul acceptă identitatea. Fiecare pas are propriul mesaj de eroare, iar fiecare este mai ieftin de testat decât următorul.