Cili PKCS#11 URI i nevojitet OpenConnect për një token?

Një kartë inteligjente që tashmë mban çelësin e duhur duhet gjithsesi të marrë udhëzimin se cili objekt në të duhet përdorur. OpenConnect në atë situatë nuk dëshiron një skedar .key të kopjuar; dëshiron një PKCS#11 URI që emërton certifikatën dhe, kur kërkimi automatik nuk mund ta përfundojë punën, çelësin privat pranë saj. Pjesa e vështirë është se një URI sintaksisht i vlefshëm nuk provon asgjë. Ai duhet të emërtojë regjistrimin të cilin porta e beson tashmë, jo thjesht një objekt që karta është e gatshme të hapë.

Çfarë dëshiron klienti në vend të një çelësi të eksportuar

Opsioni -c zakonisht merr një shteg skedari, por kur vlera analizohet si PKCS#11 URI, OpenConnect e trajton si referencë për një objekt brenda tokenit dhe jo për një skedar në disk. Opsioni -k sillet në të njëjtën mënyrë për çelësin privat. Asgjë nuk eksportohet dhe çelësi nuk e lë kurrë mbrojtjen që ofron karta. Ajo që klienti kërkon nga ju është një emër për të cilin moduli i tokenit, depoja e certifikatave dhe regjistrimi në portë bien dakord.

Është pikërisht në këtë kufizim të fundit që ngecin shumica e përpjekjeve. Një URI mund të jetë krejt i mirëformuar dhe gjithsesi të zgjedhë një certifikatë që porta do ta refuzojë, sepse vlefshmëria dhe rëndësia janë pyetje të ndara. Kontrolli që ia vlen të bëhet është një krahasim me rekordin e regjistrimit, jo një kërkim për objektin e parë që hapet rastësisht.

Dy URI, dy punë të ndryshme

URI i certifikatës përgjigjet se çfarë identiteti po pretendoni. Ai tregon një objekt certifikate, çelësi publik dhe rreshti i subjektit i të cilit përputhen me profilin e llogarisë ose të pajisjes që lëshoi administratori i VPN. E njëjta certifikatë zakonisht vjen me një objekt çelësi privat të ruajtur pranë, dhe ky çift është ai që shtrëngimi i duarve TLS ka nevojë në të vërtetë.

URI i çelësit përgjigjet se ku ndodhet materiali privat përkatës kur OpenConnect nuk mund ta nxjerrë. Me vetëm -c të vendosur, klienti ndërton një kërkim çelësi nga vetitë e certifikatës; dhënia e -k zëvendëson hamendjen me një referencë të qartë objekti. PIN-i i tokenit është hyrja e tretë, e palidhur: zhbllokon kartën për operacionin dhe nuk identifikon kurrë një objekt.

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

Gjithçka në atë varg të cituar janë të dhëna. Pikat dhe presjet ndajnë atributet e URI-së dhe shpëtimet për qind kodojnë karaktere që përndryshe do të prisnin analizën, prandaj i gjithë argumenti duhet të kalojë i paprekur nëpër shell.

Gjetja e URI-së që përputhet me regjistrimin tuaj

GnuTLS sjell p11tool, i cili liston atë që përdoruesi aktual mund të arrijë vërtet përmes p11-kit. Filloni me p11tool --list-tokens, më pas listoni objektet e certifikatave në tokenin që ju intereson. Shtoni --login kur objektet shfaqen vetëm pas një PIN, dhe krahasoni subjektin dhe lëshuesin me rekordin e regjistrimit në vend që të zgjidhni atë që shfaqet i pari.

Nëse tokeni nuk shfaqet fare, problemi qëndron poshtë OpenConnect: p11-kit nuk ka asnjë modul të regjistruar për atë middleware, ose moduli është regjistruar për një llogari tjetër. Regjistrimi në nivel sistemi ndodhet nën /etc/pkcs11/modules, dhe një drejtori për çdo përdorues mund të mbajë të njëjtën gjë pa prekur kopjen e sistemit. Kontrolloni që shtegu i ofruesit në skedarin e modulit të tregojë një bibliotekë që softueri i lexuesit ka instaluar vërtet.

Kur kopjoni URI-në nga lista, mbani thonjëzat përreth. Pikat dhe presjet pa thonjëza e shkurtojnë argumentin në atributin e parë dhe klienti raporton më pas një objekt që nuk arrin ta gjejë.

Kur kërkimi automatik i çelësit dorëzohet

OpenConnect mund të nxjerrë një kërkim çelësi nga URI i certifikatës, por përputhja e saktë që kryen varet nga versioni, dhe trajtimi i llojit të objektit e i etiketës ka ndryshuar me kohën. Këshilla për ta shkurtuar URI-në derisa të funksionojë përshkruan një anashkalim të vjetër, jo një kërkesë. Nëse kërkimi i nxjerrë dështon, emërtoni çelësin në mënyrë të qartë me -k në vend që ta shndërroni URI-në e certifikatës në diçka më të paqartë.

Përpara se të fajësoni klientin, konfirmoni se çelësi ekziston dhe duket me p11tool --list-keys. Më pas kontrolloni se objekti është shënuar si i përdorshëm për nënshkrim ose dekriptim, sepse një çelës i krijuar me atribute të gabuara nuk mund të përfundojë një shtrëngim duarsh, sado i saktë të jetë URI. Mos e transferoni një vlerë pkcs11-id të serializuar nga një profil OpenVPN në një opsion OpenConnect; dy klientët përdorin formate identifikuesi të ndryshme edhe kur flasin me të njëjtën kartë.

Nëse URI zgjidhet dhe PIN-i pranohet por vërtetimi vazhdon të dështojë, ndaloni rregullimin e URI-së. Lexoni gabimin e vetë portës, sepse dështimi tjetër ndodhet mbi tokenin.

Dështime që vetëm duken si probleme URI

Një portë që flet një protokoll tjetër do të dështojë njësoj, pavarësisht nëse URI-ja juaj është e saktë apo jo. OpenConnect zëvendësoi klientin e vjetër vpnc për një arsye, dhe mbështetja e kartave nuk e bën të përputhshëm një protokoll porte të papërputhshëm. Konfirmoni protokollin e pritur të serverit dhe rregullimin e vërtetimit përpara se të shpenzoni edhe një orë për atributet e objektit.

Vërtetimi i identitetit të serverit është gjithashtu një shtresë më vete. Klienti verifikon certifikatën e portës kundrejt depos së besimit, dhe ai kontroll ekzekutohet pasi karta tashmë ka bërë pjesën e vet. Lejet e lexuesit dhe një shërbim pcscd i ndalur prodhojnë të njëjtin simptomë të jashtme, një token të palexueshëm, me një rregullim shumë më të thjeshtë.

Punoni nga objekti drejt jashtë: a e sheh p11tool tokenin, a e sheh certifikatën dhe çelësin, a e pranon OpenConnect URI-në, dhe vetëm atëherë pyesni nëse porta e pranon identitetin. Çdo hap ka mesazhin e vet të gabimit, dhe secili është më i lirë për t'u provuar sesa ai pasardhësi.