Kian PKCS#11 URI OpenConnect bezonas por ĵetono?

Saĝa karto, kiu jam tenas la ĝustan ŝlosilon, tamen devas esti informita, kiun objekton sur ĝi uzi. OpenConnect en tiu situacio ne volas kopiitan .key-dosieron; ĝi volas PKCS#11 URI, kiu nomas la atestilon kaj, kiam la aŭtomata serĉo ne povas fini la taskon, la privatan ŝlosilon apude. La malkomforta parto estas, ke sintakse valida URI pruvas nenion. Ĝi devas nomi la registriĝon, kiun la pordego jam fidas, ne nur objekton, kiun la karto pretas malfermi.

Kion la kliento volas anstataŭ eksportita ŝlosilo

La opcio -c kutime prenas dosiervojon, sed kiam la valoro analiziĝas kiel PKCS#11 URI, OpenConnect traktas ĝin kiel referencon al objekto ene de la ĵetono, ne al dosiero sur la disko. La opcio -k kondutas same por la privata ŝlosilo. Nenio estas eksportata, kaj la ŝlosilo neniam forlasas la protekton, kiun la karto provizas. Kion la kliento bezonas de vi, estas nomo, pri kiu konsentas la ĵetona modulo, la atestila konservejo kaj la pordega registriĝo.

Ĝuste ĉe tiu lasta limigo plej multaj provoj haltas. URI povas esti tute bone formita kaj tamen elekti atestilon, kiun la pordego malakceptos, ĉar valideco kaj rilateco estas apartaj demandoj. La kontrolo inda je farado estas komparo kun la registriĝa rikordo, ne serĉo de la unua objekto, kiu hazarde malfermiĝas.

Du URI, du malsamaj taskoj

La atestila URI respondas, kiun identecon vi pretendas. Ĝi montras al atestila objekto, kies publika ŝlosilo kaj subjekta linio kongruas kun la konta aŭ aparata profilo, kiun la VPN-administranto eldonis. Tiu sama atestilo kutime venas kun privata ŝlosila objekto konservita apude, kaj tiu paro estas tio, kion la TLS-manpremo efektive bezonas.

La ŝlosila URI respondas, kie loĝas la kongrua privata materialo, kiam OpenConnect ne povas dedukti ĝin. Kun nur -c agordita, la kliento konstruas ŝlosilan serĉon el la atestilaj ecoj; provizi -k anstataŭigas konjekton per eksplicita objekta referenco. La PIN de la ĵetono estas tria, nerilata enigo: ĝi malŝlosas la karton por la operacio, kaj ĝi neniam identigas objekton.

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

Ĉio en tiu citita ĉeno estas datumoj. La punktokomoj apartigas URI-ecojn kaj la procentaj eskapoj kodas signojn, kiuj alie rompus la analizadon, do la tuta argumento devas travivi la ŝelon sendifekte.

Trovi la URI, kiu kongruas kun via registriĝo

GnuTLS liveras p11tool, kiu listigas, kion la nuna uzanto efektive povas atingi per p11-kit. Komencu per p11tool --list-tokens, poste listigu la atestilajn objektojn sur la ĵetono, kiu gravas al vi. Aldonu --login, kiam la objektoj aperas nur post PIN, kaj komparu la subjekton kaj eldonanton kun la registriĝa rikordo anstataŭ elekti tion, kio aperas unue.

Se la ĵetono tute ne aperas, la problemo kuŝas sub OpenConnect: p11-kit ne havas registritan modulon por tiu meza programaro, aŭ la modulo estas registrita por alia konto. Sistema registriĝo troviĝas sub /etc/pkcs11/modules, kaj uzanta dosierujo povas teni la samon sen tuŝi la sisteman kopion. Kontrolu, ke la provizanta vojo en la modula dosiero montras al biblioteko, kiun la programaro de la leganto efektive instalis.

Kiam vi kopias la URI el la listo, konservu la citilojn ĉirkaŭ ĝi. Nekcivitaj punktokomoj tranĉas la argumenton ĉe la unua eco, kaj la kliento tiam raportas objekton, kiun ĝi ne povas trovi.

Kiam la aŭtomata ŝlosila serĉo rezignas

OpenConnect povas derivi ŝlosilan serĉon el la atestila URI, sed la preciza kongruigo, kiun ĝi faras, dependas de la versio, kaj la traktado de objektotipo kaj etikedo ŝanĝiĝis laŭlonge de la tempo. Konsilo mallongigi la URI ĝis ĝi funkcias priskribas malnovan provizoran solvon, ne postulon. Se la derivita serĉo malsukcesas, nomu la ŝlosilon eksplicite per -k anstataŭ redakti la atestilan URI en ion pli malprecizan.

Konfirmu, ke la ŝlosilo ekzistas kaj estas videbla per p11tool --list-keys antaŭ ol kulpigi la klienton. Poste kontrolu, ke la objekto estas markita kiel uzebla por subskribo aŭ malĉifrado, ĉar ŝlosilo generita kun malĝustaj atributoj ne povas kompletigi manpremon, kiom ajn ĝusta estas la URI. Ne transplanti serialigitan pkcs11-id-valoron el OpenVPN-profilo en OpenConnect-opcion; la du klientoj uzas malsamajn identigilformatojn eĉ kiam ili parolas al la sama karto.

Se la URI solviĝas kaj la PIN akceptiĝas sed la aŭtentikigo ankoraŭ malsukcesas, ĉesu agordi la URI. Legu la eraron de la pordego mem, ĉar la sekva malsukceso estas super la ĵetono.

Malsukcesoj, kiuj nur aspektas kiel URI-problemoj

Pordego, kiu parolas alian protokolon, malsukcesos same, ĉu via URI estas ĝusta aŭ malĝusta. OpenConnect anstataŭigis la malnovan vpnc-klienton pro kialo, kaj karta subteno ne igas malkongruan pordegan protokolon kongrua. Konfirmu la atendatan protokolon de la servilo kaj la aŭtentikigan aranĝon antaŭ ol elspezi ankoraŭ horon por objektaj atributoj.

Validigo de servila identeco estas ankaŭ aparta tavolo. La kliento kontrolas la pordegan atestilon kontraŭ sia fida konservejo, kaj tiu kontrolo okazas post kiam la karto jam faris sian parton. Legantaj permesoj kaj haltigita pcscd-servo produktas la saman eksteran simptomon, nelegeblan ĵetonon, kun multe pli simpla ripari.

Laboru eksteren de la objekto: ĉu p11tool vidas la ĵetonon, ĉu ĝi vidas la atestilon kaj la ŝlosilon, ĉu OpenConnect akceptas la URI, kaj nur tiam demandu, ĉu la pordego akceptas la identecon. Ĉiu paŝo havas sian propran erarmesaĝon, kaj ĉiu estas pli malmultekosta por testi ol la sekva.