Zein PKCS#11 URI behar du OpenConneck token baterako?

Gako zuzena jada duen txartel adimentsuak hala ere jakin behar du zein objektu erabili bertan. OpenConnek ez du .key fitxategi kopiatu bat nahi egoera horretan; PKCS#11 URI bat nahi du, ziurtagiria izendatzen duena eta, bilaketa automatikoak lana bukatu ezin duenean, ondoan dagoen gako pribatua. Deserosoa da sintaktikoki baliozko URI batek ezer frogatzen ez duela. Atebideak jada fidatzen duen erregistroa izendatu behar du, ez txartelak irekitzeko prest dagoen objektu huts bat.

Zer nahi du bezeroak esportatutako gako baten ordez

-c aukerak fitxategi-bide bat hartzen du normalean, baina balioa PKCS#11 URI gisa analizatzen denean, OpenConnek tokenaren barruko objektu baterako erreferentzia gisa tratatzen du, ez diskoan dagoen fitxategi baterako. -k aukerak berdin jokatzen du gako pribatuarekin. Ezer ez da esportatzen eta gakoak ez du inoiz txartelak ematen duen babesa uzten. Bezeroak zuregandik behar duena tokenaren modulua, ziurtagirien biltegia eta atebidearen erregistroa ados dauden izen bat da.

Azken murrizketa horretan trabatzen dira saiakera gehienak. URI bat erabat ondo osatuta egon daiteke eta, hala ere, atebideak baztertuko duen ziurtagiri bat hautatu, baliozkotasuna eta garrantzia galdera bereiziak baitira. Merezi duen egiaztapena erregistro-fitxarekin alderatzea da, ez ustekabean irekitzen den lehen objektua bilatzea.

Bi URI, bi lan desberdin

Ziurtagiriaren URIak erantzuten du zein identitate aldarrikatzen ari zaren. VPN administratzaileak jaulkitako kontu edo gailuaren profilarekin bat datozen gako publikoa eta subjektu-lerroa dituen ziurtagiri-objektu bati seinalatzen dio. Ziurtagiri hori bera ondoan gordetako gako pribatuaren objektu batekin etorri ohi da, eta bikote hori da TLS esku-emateak benetan behar duena.

Gakoaren URIak erantzuten du non dagoen dagokion material pribatua OpenConnek ondorioztatu ezin duenean. -c bakarrik ezarrita, bezeroak gako-bilaketa bat eraikitzen du ziurtagiriaren propietateetatik; -k emateak susmoa objektu-erreferentzia esplizitu batekin ordezkatzen du. Tokenaren PINa hirugarren sarrera da, erlaziorik gabea: eragiketarako txartela desblokeatzen du eta inoiz ez du objektu bat identifikatzen.

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

Komatxo arteko kate horretako guztia datua da. Puntu eta komek URIaren atributuak bereizten dituzte eta ehuneko-ihesbideek analisia bestela hautsiko luketen karaktereak kodetzen dituzte, beraz argumentu osoak shell-a osorik gainditu behar du.

Zure erregistroarekin bat datorren URIa aurkitzea

GnuTLSek p11tool dakar, uneko erabiltzaileak p11-kiten bidez benetan zer lor dezakeen zerrendatzen duena. Hasi p11tool --list-tokens-ekin, gero zerrendatu interesatzen zaizun tokeneko ziurtagiri-objektuak. Gehitu --login objektuak PIN baten ondoren soilik agertzen badira, eta alderatu subjektua eta igorlea erregistro-fitxarekin, lehenengo agertzen dena hautatu beharrean.

Tokena batere agertzen ez bada, arazoa OpenConnetik behera dago: p11-kitek ez du middleware horretarako modulurik erregistratuta, edo modulua beste kontu baterako dago erregistratuta. Sistemako erregistroa /etc/pkcs11/modules azpian dago, eta erabiltzaile bakoitzeko direktorio batek gauza bera gorde dezake sistema-kopia ukitu gabe. Egiaztatu modulu-fitxategiko hornitzailearen bideak benetan instalatu zuen liburutegi bati seinalatzen diola.

URIa zerrendatik kopiatzen duzunean, mantendu inguruko komatxoak. Komatxorik gabeko puntu eta komek argumentua lehen atributuan mozten dute eta bezeroak orduan aurkitzen ez duen objektu baten berri ematen du.

Gako-bilaketa automatikoak etsitzen duenean

OpenConnek gako-bilaketa bat erator dezake ziurtagiriaren URItik, baina egiten duen bat-etortze zehatza bertsioaren araberakoa da, eta objektu-motaren eta etiketaren tratamendua aldatu egin da denborarekin. URia funtzionatzen duen arte laburtzeko aholkuak beste irtenbide zahar bat deskribatzen du, ez baldintza bat. Eratorritako bilaketak huts egiten badu, izenda ezazu gakoa modu esplizituan -k-rekin, ziurtagiriaren URIa zerbait lausoago bihurtu beharrean.

Egiaztatu gakoa badagoela eta p11tool --list-keys-ekin ikus daitekeela bezeroa erruduntzatu aurretik. Gero egiaztatu objektua sinatzeko edo deszifratzeko erabilgarri gisa markatuta dagoela, atributu okerrekin sortutako gako batek ezin baitu esku-ematerik burutu, URia zein zuzena den edozein dela ere. Ez ezazu pkcs11-id balio serializaturik OpenVPN profil batetik OpenConnect aukera batera eraman; bi bezeroek identifikatzaile-formatu desberdinak erabiltzen dituzte txartel berarekin hitz egiten dutenean ere.

URIa ebazten bada eta PINa onartzen bada baina autentifikazioak huts egiten jarraitzen badu, utzi URIa doitzen. Irakurri atebidearen beraren errorea, hurrengo hutsegitea tokenaren gainetik baitago.

URI arazoak baino ez diruditen hutsegiteak

Beste protokolo bat hitz egiten duen atebide batek berdin huts egingo du zure URIa zuzena zein okerra den. OpenConnek vpnc bezero zaharra ordezkatu zuen arrazoi batengatik, eta txartel-laguntzak ez du atebide-protokolo bateraezina bateragarri egiten. Egiaztatu zerbitzariak espero duen protokoloa eta autentifikazioaren antolamendua, objektu-atributuetan ordu bat gehiago gastatu aurretik.

Zerbitzariaren identitatearen balidazioa ere geruza bereizia da. Bezeroak atebidearen ziurtagiria egiaztatzen du bere konfiantza-biltegiaren aurka, eta egiaztapen hori txartelak bere zatia egin ondoren exekutatzen da. Irakurgailuaren baimenek eta gelditutako pcscd zerbitzuak kanpoko sintoma bera sortzen dute, token irakurgaitza, baina konponbidea askoz sinpleagoa da.

Lan egin objektutik kanpora: p11tool-ek tokena ikusten du, ziurtagiria eta gakoa ikusten ditu, OpenConnek URia onartzen du, eta orduan bakarrik galdetu atebideak identitatea onartzen duen. Urrats bakoitzak bere errore-mezua du, eta bakoitza hurrengoa baino merkeagoa da probatzeko.