Aling PKCS#11 URI ang kailangan ng OpenConnect para sa token?

Ang smart card na may tamang susi na ay kailangan pa ring sabihan kung aling object dito ang gagamitin. Sa ganoong sitwasyon, hindi gusto ng OpenConnect ang kinopyang .key file; gusto nito ang PKCS#11 URI na nagpapangalan sa sertipiko at, kapag hindi matapos ng awtomatikong paghahanap ang gawain, ang pribadong susi sa tabi nito. Ang mahirap ay hindi nagpapatunay ang isang URI na wasto sa sintaks. Kailangan nitong pangalanan ang enrollment na pinagkakatiwalaan na ng gateway, hindi lang isang object na handang buksan ng card.

Ano ang gusto ng kliyente sa halip na na-export na susi

Karaniwang tumatanggap ang -c option ng path ng file, pero kapag ang halaga ay na-parse bilang PKCS#11 URI, itinuturing ito ng OpenConnect na reference sa isang object sa loob ng token at hindi sa file sa disk. Ganoon din ang -k option para sa pribadong susi. Walang na-e-export, at hindi kailanman iniiwan ng susi ang proteksyong ibinibigay ng card. Ang kailangan ng kliyente mula sa iyo ay pangalan na sinasang-ayunan ng token module, ng imbakan ng sertipiko at ng enrollment sa gateway.

Sa huling paghihigpit na ito natigil ang karamihan ng pagtatangka. Maaaring perpektong nabuo ang isang URI at pumili pa rin ng sertipikong tatanggihan ng gateway, dahil magkaibang tanong ang bisa at kaugnayan. Ang pagsusuring sulit gawin ay paghahambing sa talaan ng enrollment, hindi paghahanap sa unang object na bukas nang nagkataon.

Dalawang URI, dalawang magkaibang gawain

Sinasagot ng URI ng sertipiko kung aling pagkakakilanlan ang inaangkin mo. Itinuturo nito ang object ng sertipiko na ang pampublikong susi at linya ng paksa ay tumutugma sa profile ng account o device na inilabas ng administrator ng VPN. Ang parehong sertipiko ay karaniwang dumarating kasama ang object ng pribadong susi na nakaimbak sa tabi nito, at ang pares na iyon ang talagang kailangan ng TLS handshake.

Sinasagot ng URI ng susi kung saan naroroon ang katumbas na pribadong materyal kapag hindi ito mahinuha ng OpenConnect. Kapag -c lang ang nakatakda, bumubuo ang kliyente ng paghahanap ng susi mula sa mga katangian ng sertipiko; ang pagbibigay ng -k ay pumapalit sa haka-haka ng tahasang reference sa object. Ang PIN ng token ay ikatlo, walang kaugnayang input: binubuksan nito ang card para sa operasyon, at hindi kailanman tinutukoy ang isang object.

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

Lahat ng nasa siniping string na iyon ay data. Hinihiwalay ng mga semicolon ang mga katangian ng URI at ine-encode ng mga percent escape ang mga character na kung hindi ay sisira sa pag-parse, kaya ang buong argumento ay dapat na lumabas nang buo sa shell.

Paghahanap ng URI na tumutugma sa iyong enrollment

May kasamang p11tool ang GnuTLS, na naglilista ng aktuwal na naaabot ng kasalukuyang user sa pamamagitan ng p11-kit. Magsimula sa p11tool --list-tokens, pagkatapos ilista ang mga object ng sertipiko sa token na pinagkakainteresan mo. Idagdag ang --login kapag lumalabas lang ang mga object pagkatapos ng PIN, at ihambing ang paksa at issuer sa talaan ng enrollment sa halip na piliin ang unang lumabas.

Kung hindi lumabas ang token, nasa ilalim ng OpenConnect ang problema: walang nakarehistrong module ang p11-kit para sa middleware na iyon, o nakarehistro ang module para sa ibang account. Ang rehistrasyon sa buong sistema ay nasa ilalim ng /etc/pkcs11/modules, at maaaring maglaman ng parehong bagay ang direktoryo ng bawat user nang hindi hinahawakan ang kopya ng sistema. Tiyakin na ang path ng provider sa module file ay tumuturo sa library na aktuwal na ininstol ng software ng reader.

Kapag kinopya mo ang URI mula sa listahan, panatilihin ang mga quote sa paligid nito. Pinuputol ng mga semicolon na walang quote ang argumento sa unang katangian at pagkatapos ay iniuulat ng kliyente ang object na hindi nito mahanap.

Kapag sumuko ang awtomatikong paghahanap ng susi

Maaaring kunin ng OpenConnect ang paghahanap ng susi mula sa URI ng sertipiko, pero nakadepende sa bersyon ang eksaktong pagtutugma na ginagawa nito, at nagbago sa paglipas ng panahon ang paghawak sa uri ng object at label. Ang payong paikliin ang URI hanggang gumana ay naglalarawan ng lumang paraan ng pag-iwas, hindi ng pangangailangan. Kung mabigo ang hinangong paghahanap, pangalanan ang susi nang tahasan gamit ang -k sa halip na gawing mas malabo ang URI ng sertipiko.

Tiyakin na umiiral at nakikita ang susi gamit ang p11tool --list-keys bago sisihin ang kliyente. Pagkatapos, tingnan kung ang object ay minarkahan bilang magagamit para sa pagpirma o pag-decrypt, dahil ang susing nabuo sa maling katangian ay hindi makakumpleto ng handshake, gaano man katama ang URI. Huwag ilipat ang serialized na halaga ng pkcs11-id mula sa profile ng OpenVPN patungo sa option ng OpenConnect; magkaiba ang format ng identifier ng dalawang kliyente kahit kausap nila ang parehong card.

Kung nalutas ang URI at tinanggap ang PIN pero nabigo pa rin ang authentication, itigil ang pag-tune ng URI. Basahin ang error ng gateway mismo, dahil ang susunod na kabiguan ay nasa itaas ng token.

Mga kabiguang mukhang problema lamang sa URI

Ang gateway na nagsasalita ng ibang protocol ay mabibigo nang pareho kung tama o mali ang iyong URI. Pinalitan ng OpenConnect ang lumang vpnc client dahil sa dahilan, at hindi ginagawang compatible ng suporta sa card ang isang incompatible na protocol ng gateway. Tiyakin ang inaasahang protocol ng server at ang pagkakaayos ng authentication bago gumastos ng isa pang oras sa mga katangian ng object.

Ang pagpapatunay ng pagkakakilanlan ng server ay hiwalay ding layer. Bineberipika ng kliyente ang sertipiko ng gateway laban sa sarili nitong imbakan ng tiwala, at ang pagsusuring iyon ay tumatakbo pagkatapos magawa ng card ang bahagi nito. Ang mga pahintulot ng reader at ang nakatigil na serbisyong pcscd ay gumagawa ng parehong panlabas na sintomas, isang token na hindi mabasa, na may mas simpleng lunas.

Magtrabaho mula sa object pakanlabas: nakikita ba ng p11tool ang token, nakikita ba nito ang sertipiko at susi, tinatanggap ba ng OpenConnect ang URI, at saka lang itanong kung tinatanggap ng gateway ang pagkakakilanlan. May sariling mensahe ng error ang bawat hakbang, at mas mura ang bawat isang subukan kaysa sa susunod.