Watter PKCS#11-URI het OpenConnect vir ’n token nodig?

’n Slimkaart wat reeds die regte sleutel bevat, moet steeds vertel word watter objek daarop gebruik moet word. OpenConnect wil in daardie situasie nie ’n gekopieerde .key-lêer hê nie; dit wil ’n PKCS#11-URI hê wat die sertifikaat benoem en, wanneer die outomatiese soektog die taak nie kan voltooi nie, die private sleutel daarlangs. Die ongemaklike deel is dat ’n sintakties korrekte URI niks bewys nie. Dit moet die registrasie benoem wat die poort reeds vertrou, nie bloot ’n objek wat die kaart bereid is om oop te maak nie.

Wat die kliënt eerder as ’n uitgevoerde sleutel wil hê

Die -c-opsie neem gewoonlik ’n lêerpad, maar wanneer die waarde as ’n PKCS#11-URI ontleed, behandel OpenConnect dit as ’n verwysing na ’n objek binne die token eerder as na ’n lêer op skyf. Die -k-opsie werk dieselfde vir die private sleutel. Niks word uitgevoer nie, en die sleutel verlaat nooit die beskerming wat die kaart bied nie. Wat die kliënt van jou nodig het, is ’n naam waaroor die tokenmodule, die sertifikaatstoor en die poortregistrasie dit eens is.

Daardie laaste vereiste is waar die meeste pogings vasloop. ’n URI kan heeltemal goed gevorm wees en steeds ’n sertifikaat kies wat die poort sal verwerp, want geldigheid en relevansie is aparte vrae. Die kontrolering wat die moeite werd is, is ’n vergelyking met die registrasierekord, nie ’n soektog na die eerste objek wat toevallig oopmaak nie.

Twee URI's, twee verskillende take

Die sertifikaat-URI beantwoord watter identiteit jy opeis. Dit wys na ’n sertifikaatobjek waarvan die publieke sleutel en subjeklyn ooreenstem met die rekening- of toestelprofiel wat die VPN-administrateur uitgereik het. Dieselfde sertifikaat kom gewoonlik saam met ’n private sleutelobjek wat daarlangs gestoor is, en dié paar is wat die TLS-handdruk eintlik nodig het.

Die sleutel-URI beantwoord waar die ooreenstemmende private materiaal woon wanneer OpenConnect dit nie kan aflei nie. Met net -c gestel, bou die kliënt ’n sleutelsoektog uit die sertifikaat se eienskappe; as jy -k verskaf, vervang dit die raaiwerk met ’n eksplisiete objekverwysing. Die token se PIN is ’n derde, onverwante inset: dit ontsluit die kaart vir die bewerking, en dit identifiseer nooit ’n objek nie.

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

Alles in daardie aangehaalde string is data. Die kommapunte skei URI-eienskappe en die persentontwykings kodeer karakters wat andersins die ontleding sou breek, so die hele argument moet ongeskonde deur die skel kom.

Vind die URI wat by jou registrasie pas

GnuTLS lewer p11tool, wat lys wat die huidige gebruiker werklik deur p11-kit kan bereik. Begin met p11tool --list-tokens en lys dan die sertifikaatobjekte op die token waaroor jy gee. Voeg --login by wanneer die objekte eers ná ’n PIN verskyn, en vergelyk die subjek en uitgewer met die registrasierekord eerder as om te kies wat eerste verskyn.

As die token glad nie verskyn nie, sit die probleem onder OpenConnect: p11-kit het geen module vir daardie middelware geregistreer nie, of die module is vir ’n ander rekening geregistreer. Stelselwye registrasie woon onder /etc/pkcs11/modules, en ’n gids per gebruiker kan dieselfde ding hou sonder om die stelselkopie te raak. Kontroleer dat die verskafferpad in die modulelêer na ’n biblioteek wys wat die leser se sagteware werklik geïnstalleer het.

Wanneer jy die URI uit die lys kopieer, hou die aanhalingstekens daarom. Onaangehaalde kommapunte sny die argument by die eerste eienskap af en die kliënt rapporteer dan ’n objek wat hy nie kan vind nie.

Wanneer die outomatiese sleutelsoektog opgee

OpenConnect kan ’n sleutelsoektog uit die sertifikaat-URI aflei, maar die presiese passing wat dit doen hang van die weergawe af, en die hantering van objektipe en etiket het oor tyd verander. Raad wat sê jy moet die URI verkort tot dit werk, beskryf ’n ou noodoplossing, nie ’n vereiste nie. As die afgeleide soektog misluk, noem die sleutel uitdruklik met -k in plaas daarvan om die sertifikaat-URI in iets vaers te verander.

Bevestig dat die sleutel bestaan en sigbaar is met p11tool --list-keys voordat jy die kliënt blameer. Kontroleer dan dat die objek gemerk is as bruikbaar vir ondertekening of ontsyptering, want ’n sleutel wat met verkeerde eienskappe geskep is, kan nie ’n handdruk voltooi nie, hoe korrek die URI ook al is. Moenie ’n geserialiseerde pkcs11-id-waarde uit ’n OpenVPN-profiel in ’n OpenConnect-opsie oorplant nie; die twee kliënte gebruik verskillende identifiseerderformate selfs wanneer hulle met dieselfde kaart praat.

As die URI oplos en die PIN aanvaar word maar verifikasie steeds misluk, hou op om die URI te verfyn. Lees die poort se eie fout, want die volgende mislukking is stroomop van die token.

Mislukkings wat net soos URI-probleme lyk

’n Poort wat ’n ander protokol praat, sal identies misluk of jou URI reg of verkeerd is. OpenConnect het die ou vpnc-kliënt vir ’n rede vervang, en kaartondersteuning maak ’n onversoenbare poortprotokol nie versoenbaar nie. Bevestig die bediener se verwagte protokol en verifikasiereëling voordat jy nog ’n uur aan objekeienskappe bestee.

Bedieneridentiteitskontrole is ook ’n aparte laag. Die kliënt verifieer die poortsertifikaat teen sy vertrouensstoor, en daardie kontrole loop nadat die kaart reeds sy deel gedoen het. Lesertoestemmings en ’n gestopte pcscd-diens lewer dieselfde uiterlike simptoom, ’n onleesbare token, met ’n veel eenvoudiger regstelling.

Werk van die objek af na buite: sien p11tool die token, sien dit die sertifikaat en sleutel, aanvaar OpenConnect die URI, en vra eers dan of die poort die identiteit aanvaar. Elke stap het sy eie foutboodskap, en elke een is goedkoper om te toets as die een daarna.