Pametna kartica, ki že vsebuje pravi ključ, mora vseeno izvedeti, kateri predmet na njej uporabiti. OpenConnect v takšni situaciji noče kopirane datoteke .key; želi PKCS#11 URI, ki poimenuje potrdilo in, ko samodejno iskanje ne more dokončati dela, zasebni ključ ob njem. Nerodno je, da sintaktično veljaven URI ne dokazuje ničesar. Poimenovati mora vpis, ki mu prehod že zaupa, ne le predmeta, ki ga je kartica pripravljena odpreti.

Kaj želi odjemalec namesto izvoženega ključa

Možnost -c običajno sprejme pot do datoteke, a ko se vrednost razčleni kot PKCS#11 URI, jo OpenConnect obravnava kot sklic na predmet znotraj žetona in ne na datoteko na disku. Možnost -k se za zasebni ključ obnaša enako. Nič ni izvoženo in ključ nikoli ne zapusti zaščite, ki jo ponuja kartica. Odjemalec od vas potrebuje ime, s katerim se strinjajo modul žetona, shramba potrdil in vpis v prehodu.

Prav na tej zadnji omejitvi se ustavi večina poskusov. URI je lahko povsem dobro oblikovan in vseeno izbere potrdilo, ki ga bo prehod zavrnil, ker sta veljavnost in ustreznost ločeni vprašanji. Preverjanje, ki se splača, je primerjava z zapisom vpisa, ne iskanje prvega predmeta, ki se slučajno odpre.

Dva URI, dve različni nalogi

URI potrdila odgovarja, katero identiteto uveljavljate. Kaže na predmet potrdila, katerega javni ključ in vrstica subjekta se ujemata s profilom računa ali naprave, ki ga je izdal skrbnik VPN. Isto potrdilo običajno pride s predmetom zasebnega ključa, shranjenim ob njem, in prav ta par potrebuje rokovanje TLS.

URI ključa odgovarja, kje je ustrezno zasebno gradivo, ko ga OpenConnect ne more ugotoviti. Ob samo nastavljenem -c odjemalec zgradi iskanje ključa iz lastnosti potrdila; navedba -k nadomesti ugibanje z izrecnim sklicem na predmet. PIN žetona je tretji, nepovezan vnos: odklene kartico za operacijo in nikoli ne identificira predmeta.

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

Vse v tem citiranem nizu so podatki. Podpičja ločujejo atribute URI, odstotni pobegi pa kodirajo znake, ki bi sicer pokvarili razčlenjevanje, zato mora celoten argument nepoškodovan priti skozi lupino.

Iskanje URI, ki ustreza vašemu vpisu

GnuTLS prinaša p11tool, ki našteje, do česa lahko trenutni uporabnik v resnici doseže prek p11-kit. Začnite s p11tool --list-tokens, nato naštejte predmete potrdil na žetonu, ki vas zanima. Dodajte --login, ko se predmeti pojavijo šele po PIN, in primerjajte subjekt in izdajatelja z zapisom vpisa, namesto da izberete tisto, kar se pojavi prvo.

Če se žeton sploh ne pojavi, je težava pod OpenConnect: p11-kit nima registriranega modula za to vmesno programsko opremo ali pa je modul registriran za drug račun. Sistemska registracija je v /etc/pkcs11/modules, uporabniška mapa pa lahko vsebuje isto, ne da bi se dotaknila sistemske kopije. Preverite, ali pot ponudnika v datoteki modula kaže na knjižnico, ki jo je programska oprema bralnika resnično namestila.

Ko URI kopirate s seznama, obdržite narekovaje okoli njega. Podpičja brez narekovajev odrežejo argument pri prvem atributu in odjemalec nato poroča o predmetu, ki ga ne more najti.

Ko samodejno iskanje ključa obupa

OpenConnect lahko iz URI potrdila izpelje iskanje ključa, a natančno ujemanje, ki ga izvede, je odvisno od različice, obravnava vrste predmeta in oznake pa se je s časom spreminjala. Nasvet, naj skrajšate URI, dokler ne deluje, opisuje staro obhodno pot, ne zahteve. Če izpeljano iskanje ne uspe, ključ izrecno poimenujte z -k, namesto da bi URI potrdila spremenili v nekaj bolj nejasnega.

Preden krivite odjemalca, potrdite, da ključ obstaja in je viden s p11tool --list-keys. Nato preverite, ali je predmet označen kot uporaben za podpis ali dešifriranje, ker ključ, ustvarjen z napačnimi atributi, ne more dokončati rokovanja, ne glede na to, kako pravilen je URI. Ne prenašajte serializirane vrednosti pkcs11-id iz profila OpenVPN v možnost OpenConnect; odjemalca uporabljata različne oblike identifikatorja, tudi ko govorita z isto kartico.

Če se URI razreši in je PIN sprejet, avtentikacija pa še vedno ne uspe, prenehajte z uglaševanjem URI. Preberite napako samega prehoda, ker je naslednja napaka nad žetonom.

Napake, ki so le videti kot težave z URI

Prehod, ki govori drug protokol, bo odpovedal enako, ne glede na to, ali je vaš URI pravilen ali ne. OpenConnect je stari odjemalec vpnc zamenjal z razlogom, podpora kartic pa ne naredi nezdružljivega protokola prehoda združljivega. Potrdite pričakovani protokol strežnika in ureditev avtentikacije, preden porabite še eno uro za atribute predmeta.

Preverjanje identitete strežnika je tudi ločena plast. Odjemalec preveri potrdilo prehoda glede na svojo shrambo zaupanja, in to preverjanje se izvede, potem ko je kartica svoj del že opravila. Dovoljenja bralnika in ustavljena storitev pcscd dajo enak zunanji simptom, neberljiv žeton, z veliko preprostejšo rešitvijo.

Delajte od predmeta navzven: ali p11tool vidi žeton, ali vidi potrdilo in ključ, ali OpenConnect sprejme URI, in šele nato vprašajte, ali prehod sprejme identiteto. Vsak korak ima svoje sporočilo o napaki in vsak je ceneje preizkusiti kot naslednjega.

Sorodni članki