OpenConnect inahitaji PKCS#11 URI ipi kwa tokeni?

Kadi janja ambayo tayari ina ufunguo sahihi bado inapaswa kuambiwa ni kitu kipi juu yake kitumike. OpenConnect katika hali hiyo haitaki faili ya .key iliyonakiliwa; inataka PKCS#11 URI inayotaja cheti na, wakati utafutaji wa kiotomatiki hauwezi kumaliza kazi, ufunguo wa faragha ulio kando yake. Sehemu ngumu ni kwamba URI halali kwa sintaksia haithibitishi chochote. Inapaswa kutaja usajili ambao lango linaamini tayari, si tu kitu ambacho kadi iko tayari kufungua.

Mteja anataka nini badala ya ufunguo uliosafirishwa

Chaguo -c kawaida huchukua njia ya faili, lakini wakati thamani inachanganuliwa kama PKCS#11 URI, OpenConnect inaichukulia kama rejeleo la kitu ndani ya tokeni na si la faili kwenye diski. Chaguo -k hufanya hivyo hivyo kwa ufunguo wa faragha. Hakuna kinachosafirishwa, na ufunguo hauachi kamwe ulinzi unaotolewa na kadi. Kile mteja anahitaji kutoka kwako ni jina ambalo moduli ya tokeni, hifadhi ya vyeti na usajili wa lango wanakubaliana juu yake.

Ni kwenye kizuizi hiki cha mwisho ambapo majaribio mengi yanakwama. URI inaweza kuwa imeundwa vizuri kabisa na bado ichague cheti ambacho lango litakataa, kwa sababu uhalali na umuhimu ni maswali tofauti. Ukaguzi unaostahili kufanywa ni ulinganisho na rekodi ya usajili, si utafutaji wa kitu cha kwanza kinachofunguka kwa bahati.

URI mbili, kazi mbili tofauti

URI ya cheti hujibu ni utambulisho upi unaodai. Inaelekeza kwenye kitu cha cheti ambacho ufunguo wake wa umma na mstari wa mada vinalingana na wasifu wa akaunti au kifaa uliotolewa na msimamizi wa VPN. Cheti hicho hicho kawaida huja na kitu cha ufunguo wa faragha kilichohifadhiwa kando yake, na jozi hilo ndilo linalohitajika kwa kupeana mkono kwa TLS.

URI ya ufunguo hujibu ni wapi nyenzo za faragha zinazolingana zinaishi wakati OpenConnect haiwezi kuzikisia. Kwa -c pekee iliyowekwa, mteja hujenga utafutaji wa ufunguo kutoka kwa sifa za cheti; kutoa -k hubadilisha kukisia na rejeleo dhahiri la kitu. PIN ya tokeni ni ingizo la tatu, lisilohusiana: hufungua kadi kwa ajili ya operesheni, na haitambui kitu kamwe.

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

Kila kitu katika mfuatano huo uliodondolewa ni data. Nukta na koma hutenganisha sifa za URI na misimbo ya asilimia husimba herufi ambazo vinginevyo zingevunja uchanganuzi, kwa hivyo hoja yote lazima ipite kwenye ganda ikiwa nzima.

Kutafuta URI inayolingana na usajili wako

GnuTLS huja na p11tool, ambayo huorodhesha kile mtumiaji wa sasa anaweza kufikia kwa hakika kupitia p11-kit. Anza na p11tool --list-tokens, kisha orodhesha vitu vya cheti kwenye tokeni inayokuhusu. Ongeza --login wakati vitu vinaonekana tu baada ya PIN, na linganisha mada na mtoaji na rekodi ya usajili badala ya kuchagua kinachoonekana kwanza.

Ikiwa tokeni haionekani kabisa, tatizo liko chini ya OpenConnect: p11-kit haina moduli iliyosajiliwa kwa programu hiyo ya kati, au moduli imesajiliwa kwa akaunti nyingine. Usajili wa ngazi ya mfumo upo chini ya /etc/pkcs11/modules, na saraka ya kila mtumiaji inaweza kuwa na kitu kile kile bila kugusa nakala ya mfumo. Angalia kwamba njia ya mtoa huduma katika faili ya moduli inaelekeza kwenye maktaba ambayo programu ya msomaji imesakinisha kwa hakika.

Unaponakili URI kutoka kwenye orodha, baki na alama za nukuu kuzunguka. Nukta na koma zisizo na nukuu hukata hoja kwenye sifa ya kwanza na mteja huripoti kitu ambacho hawezi kukipata.

Wakati utafutaji wa kiotomatiki wa ufunguo unakata tamaa

OpenConnect inaweza kupata utafutaji wa ufunguo kutoka URI ya cheti, lakini ulinganifu kamili unaofanya hutegemea toleo, na utunzaji wa aina ya kitu na lebo umebadilika kwa muda. Ushauri wa kufupisha URI hadi ifanye kazi unaelezea mbinu ya zamani, si sharti. Ikiwa utafutaji uliopatikana unashindikana, taja ufunguo kwa uwazi kwa -k badala ya kubadilisha URI ya cheti kuwa kitu kisichoeleweka zaidi.

Thibitisha kwamba ufunguo upo na unaonekana kwa p11tool --list-keys kabla ya kumlaumu mteja. Kisha angalia kwamba kitu kimetiwa alama kuwa kinatumika kwa sahihi au usimbuaji, kwa sababu ufunguo uliozalishwa na sifa zisizo sahihi hauwezi kumaliza kupeana mkono, hata URI iwe sahihi kiasi gani. Usihamishe thamani ya pkcs11-id iliyofuatana kutoka wasifu wa OpenVPN kwenda kwenye chaguo la OpenConnect; wateja wawili hutumia miundo tofauti ya kitambulisho hata wanapozungumza na kadi moja.

Ikiwa URI inatatuliwa na PIN inakubaliwa lakini uthibitishaji bado unashindikana, acha kurekebisha URI. Soma hitilafu ya lango yenyewe, kwa sababu kushindwa kunakofuata kuko juu ya tokeni.

Kushindwa kunakoonekana kama matatizo ya URI pekee

Lango linalozungumza itifaki nyingine litashindwa vivyo hivyo ikiwa URI yako ni sahihi au si sahihi. OpenConnect ilibadilisha mteja wa zamani wa vpnc kwa sababu, na msaada wa kadi haufanyi itifaki ya lango isiyolingana kuwa inayolingana. Thibitisha itifaki inayotarajiwa ya seva na mpangilio wa uthibitishaji kabla ya kutumia saa nyingine kwenye sifa za kitu.

Uthibitishaji wa utambulisho wa seva pia ni tabaka tofauti. Mteja huthibitisha cheti cha lango dhidi ya hifadhi yake ya uaminifu, na ukaguzi huo hufanyika baada ya kadi kufanya sehemu yake tayari. Ruhusa za msomaji na huduma ya pcscd iliyosimama huzalisha dalili hiyo hiyo ya nje, tokeni isiyosomeka, pamoja na marekebisho rahisi zaidi.

Fanya kazi kutoka kwenye kitu kuelekea nje: p11tool inaona tokeni, inaona cheti na ufunguo, OpenConnect inakubali URI, na ndipo tu uulize ikiwa lango linakubali utambulisho. Kila hatua ina ujumbe wake wa hitilafu, na kila moja ni rahisi kujaribu kuliko inayofuata.