Kādu PKCS#11 URI OpenConnect vajag tokenam?

Viedkartei, kurā jau ir pareizā atslēga, tomēr jāpasaka, kuru objektu tajā izmantot. OpenConnect šādā situācijā negrib nokopētu .key failu; tas grib PKCS#11 URI, kas nosauc sertifikātu, un, kad automātiskā meklēšana nevar pabeigt darbu, arī blakus esošo privāto atslēgu. Neērtā daļa ir tā, ka sintaktiski derīgs URI neko nepierāda. Tam jānosauc reģistrācija, kurai vārteja jau uzticas, nevis tikai objekts, kuru karte ir gatava atvērt.

Ko klients grib eksportētas atslēgas vietā

-c opcija parasti ņem faila ceļu, bet, kad vērtība tiek parsēta kā PKCS#11 URI, OpenConnect to uzskata par atsauci uz objektu tokena iekšienē, nevis uz failu diskā. -k opcija privātajai atslēgai darbojas tāpat. Nekas netiek eksportēts, un atslēga nekad neatstāj kartes sniegto aizsardzību. Tas, ko klients no jums vajag, ir vārds, par kuru vienojas tokena modulis, sertifikātu krātuve un vārtejas reģistrācija.

Tieši pie šā pēdējā ierobežojuma apstājas lielākā daļa mēģinājumu. URI var būt pilnīgi pareizi veidots un tomēr izvēlēties sertifikātu, kuru vārteja noraidīs, jo derīgums un atbilstība ir atsevišķi jautājumi. Pārbaude, kas ir tā vērta, ir salīdzināšana ar reģistrācijas ierakstu, nevis pirmā nejauši atveramā objekta meklēšana.

Divi URI, divi dažādi darbi

Sertifikāta URI atbild, kādu identitāti jūs apgalvojat. Tas norāda uz sertifikāta objektu, kura publiskā atslēga un subjekta rinda atbilst VPN administratora izdotajam konta vai ierīces profilam. Šis pats sertifikāts parasti nāk ar blakus saglabātu privātās atslēgas objektu, un tieši šis pāris TLS rokasspiedienam ir vajadzīgs.

Atslēgas URI atbild, kur atrodas atbilstošais privātais materiāls, kad OpenConnect to nevar secināt. Ar iestatītu tikai -c klients veido atslēgas meklēšanu no sertifikāta īpašībām; norādot -k, minējums tiek aizstāts ar skaidru objekta atsauci. Tokena PIN ir trešā, nesaistītā ievade: tas atslēdz karti darbībai un nekad neidentificē objektu.

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

Viss šajā pēdiņās ievietotajā virknē ir dati. Semikoli atdala URI atribūtus, un procentu aizbēgšana kodē rakstzīmes, kas citādi salauztu parsēšanu, tāpēc visam argumentam ir nebojātam jāiztur čaula.

Atrast URI, kas atbilst jūsu reģistrācijai

GnuTLS piegādā p11tool, kas uzskaita, ko pašreizējais lietotājs patiešām var sasniegt caur p11-kit. Sāciet ar p11tool --list-tokens, pēc tam uzskaitiet sertifikāta objektus tokenā, kas jūs interesē. Pievienojiet --login, ja objekti parādās tikai pēc PIN, un salīdziniet subjektu un izdevēju ar reģistrācijas ierakstu, nevis izvēlieties pirmo parādījušos.

Ja tokens vispār neparādās, problēma ir zem OpenConnect: p11-kit nav reģistrēta moduļa šai starpprogrammatūrai, vai modulis ir reģistrēts citam kontam. Sistēmas līmeņa reģistrācija atrodas /etc/pkcs11/modules, un lietotāja katalogs var saturēt to pašu, neaizskarot sistēmas kopiju. Pārbaudiet, vai moduļa failā norādītais pakalpojumu sniedzēja ceļš rāda uz bibliotēku, ko lasītāja programmatūra patiešām instalēja.

Kad kopējat URI no saraksta, saglabājiet pēdiņas ap to. Semikoli bez pēdiņām nogriež argumentu pie pirmā atribūta, un klients pēc tam ziņo par objektu, kuru nevar atrast.

Kad automātiskā atslēgas meklēšana padodas

OpenConnect var atvasināt atslēgas meklēšanu no sertifikāta URI, bet precīzā saskaņošana, ko tas veic, ir atkarīga no versijas, un objekta tipa un etiķetes apstrāde laika gaitā ir mainījusies. Padoms saīsināt URI, līdz tas strādā, apraksta vecu apiešanas ceļu, nevis prasību. Ja atvasinātā meklēšana neizdodas, nosauciet atslēgu skaidri ar -k, nevis pārveidojiet sertifikāta URI kaut kā neskaidrākā.

Pirms vainojat klientu, pārliecinieties, ka atslēga pastāv un ir redzama ar p11tool --list-keys. Pēc tam pārbaudiet, vai objekts ir atzīmēts kā izmantojams parakstīšanai vai atšifrēšanai, jo atslēga, kas ģenerēta ar nepareiziem atribūtiem, nevar pabeigt rokasspiedienu, lai cik pareizs būtu URI. Nepārnesiet serializētu pkcs11-id vērtību no OpenVPN profila uz OpenConnect opciju; abi klienti izmanto dažādus identifikatora formātus, pat ja tie runā ar vienu un to pašu karti.

Ja URI atrisinās un PIN tiek pieņemts, bet autentifikācija joprojām neizdodas, pārtrauciet URI pielāgošanu. Lasiet pašas vārtejas kļūdu, jo nākamā neveiksme ir virs tokena.

Neveiksmes, kas tikai izskatās pēc URI problēmām

Vārteja, kas runā citā protokolā, neizdosies vienādi neatkarīgi no tā, vai jūsu URI ir pareizs vai nepareizs. OpenConnect aizstāja veco vpnc klientu iemesla dēļ, un karšu atbalsts nepadara nesaderīgu vārtejas protokolu saderīgu. Apstipriniet servera gaidīto protokolu un autentifikācijas izkārtojumu, pirms tērējat vēl stundu objekta atribūtiem.

Servera identitātes validācija arī ir atsevišķs slānis. Klients pārbauda vārtejas sertifikātu pret savu uzticības krātuvi, un šī pārbaude notiek pēc tam, kad karte jau ir izdarījusi savu daļu. Lasītāja atļaujas un apturēts pcscd pakalpojums rada to pašu ārējo simptomu, nelasāmu tokenu, ar daudz vienkāršāku labojumu.

Strādājiet no objekta uz āru: vai p11tool redz tokenu, vai tas redz sertifikātu un atslēgu, vai OpenConnect pieņem URI, un tikai tad jautājiet, vai vārteja pieņem identitāti. Katram solim ir savs kļūdas ziņojums, un katru ir lētāk pārbaudīt nekā nākamo.