Hokker PKCS#11 URI hat OpenConnect nedich foar in token?

In chipkaart dy’t de goede kaai al hat, moat noch altyd ferteld krije hokker objekt derop brûkt wurde moat. OpenConnect wol yn dy situaasje gjin kopiaerre .key-bestân; it wol in PKCS#11 URI dy’t it sertifikaat neamt en, as it automatyske sykjen it wurk net ôfmeitsje kin, de partikuliere kaai derneist. It ûnhandige is dat in sintaktysk jildige URI neat bewiist. Hy moat de registraasje neame dy’t de poarte al fertrout, net samar in objekt dat de kaart ree is om te iepenjen.

Wat de klant wol ynstee fan in útfierde kaai

De -c-opsje nimt normaal in bestânspaad, mar as de wearde as PKCS#11 URI parse wurdt, behannelt OpenConnect it as in ferwizing nei in objekt binnen it token ynstee fan nei in bestân op skiif. De -k-opsje docht itselde foar de partikuliere kaai. Neat wurdt útfierd, en de kaai ferlit nea de beskerming dy’t de kaart biedt. Wat de klant fan jo nedich hat, is in namme dêr’t de tokenmodule, it sertifikaatargyf en de registraasje fan de poarte it oer iens binne.

Op dy lêste beheining strâne de measte besykjen. In URI kin folslein goed foarme wêze en dochs in sertifikaat kieze dat de poarte ôfwize sil, om’t jildigens en relevânsje aparte fragen binne. De kontrôle dy’t de muoite wurdich is, is in ferliking mei it registraasjerekord, net in syktocht nei it earste objekt dat tafallich iepengiet.

Twa URI’s, twa ferskillende taken

De sertifikaat-URI beantwurdet hokker identiteit jo opeaskje. Hy wiist nei in sertifikaatobjekt wêrfan’t de iepenbiere kaai en de ûnderwerprige oerienkomme mei it akkount- of apparaatprofyl dat de VPN-administrator útjûn hat. Deselde sertifikaat komt meastentiids mei in partikulier-kaaiobjekt dat derneist bewarre is, en krekt dat pear hat de TLS-hânskrassing nedich.

De kaai-URI beantwurdet wêr’t it oerienkommende partikuliere materiaal wennet as OpenConnect it net ôfliede kin. Mei allinnich -c ynsteld, bout de klant in kaaisyktocht út ’e eigenskippen fan it sertifikaat; it jaan fan -k ferfangt it rieden troch in eksplisite objektferwizing. De PIN fan it token is in tredde, ûnferbûn ynfier: hy ûntslút de kaart foar de hanneling en identifisearret nea in objekt.

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

Alles yn dy sitearre tekenrige is data. De puntkomma’s skiede URI-eigenskippen en de persintaazje-ûntwykings kodearje tekens dy’t oars it parsen brekke soene, dus it hiele argumint moat ûnskeind troch de shell komme.

De URI fine dy’t by jo registraasje past

GnuTLS leveret p11tool, dat listet wat de hjoeddeiske brûker fia p11-kit wier berikke kin. Begjin mei p11tool --list-tokens, list dan de sertifikaatobjekten op it token dat jo oanbelanget. Foegje --login ta as de objekten pas nei in PIN ferskine, en ferlykje it ûnderwerp en de útjouwer mei it registraasjerekord ynstee fan te kiezen wat as earste ferskynt.

As it token hielendal net ferskynt, sit it probleem ûnder OpenConnect: p11-kit hat gjin module registrearre foar dat middleware, of de module is registrearre foar in oar akkount. Systeembrede registraasje wennet ûnder /etc/pkcs11/modules, en in map per brûker kin itselde hâlde sûnder de systeemkopy oan te reitsjen. Kontrolearje dat it leveransierspaad yn it modulebestân nei in bibleteek wiist dy’t de software fan ’e lêzer wier ynstallearre hat.

As jo de URI út ’e list kopyearje, hâld dan de sitaten derom hinne. Puntkomma’s sûnder sitaten snije it argumint by it earste eigenskip ôf en de klant rapportearret dan in objekt dat er net fine kin.

As de automatyske kaaisyktocht it opjout

OpenConnect kin in kaaisyktocht ôfliede út ’e sertifikaat-URI, mar de krekte oerienkomst dy’t er docht hinget fan ’e ferzje ôf, en de behanneling fan objekttype en label is oer de tiid feroare. Advys om de URI koarter te meitsjen oant er wurket, beskriuwt in âlde omwei, gjin eask. As de ôfliede syktocht mislearret, neam de kaai dan eksplisyt mei -k ynstee fan ’e sertifikaat-URI yn wat ûndúdlikers te feroarjen.

Kontrolearje dat de kaai bestiet en sichtber is mei p11tool --list-keys foardat jo de klant de skuld jouwe. Kontrolearje dan dat it objekt markearre is as brûkber foar ûndertekenjen of ûntsifering, om’t in kaai mei ferkearde eigenskippen in hânskrassing net ôfmeitsje kin, hoe krekt de URI ek is. Ferplantet gjin serialisearre pkcs11-id-wearde út in OpenVPN-profyl yn in OpenConnect-opsje; de beide klanten brûke ferskillende identifikaasjeformaten sels as se mei deselde kaart prate.

As de URI oplost en de PIN akseptearre wurdt mar de autentikaasje dochs mislearret, stop dan mei it bystellen fan ’e URI. Lês de flater fan ’e poarte sels, om’t de folgjende mislearring boppe it token sit.

Flaters dy’t allinnich op URI-problemen lykje

In poarte dy’t in oar protokol sprekt, sil identyk mislearje oft jo URI no goed of ferkeard is. OpenConnect ferfong de âlde vpnc-klant om in reden, en kaartstipe makket in ynkompatibel poarteprotokol net kompatibel. Befêstigje it ferwachte protokol fan ’e tsjinner en de autentikaasje-opset foardat jo noch in oere oan objekteigenskippen besteegje.

It falidearjen fan ’e identiteit fan ’e tsjinner is ek in aparte laach. De klant ferifiearret it poartesertifikaat tsjin syn fertrouwensargyf, en dy kontrôle rint neidat de kaart har part al dien hat. Lêzerpermissys en in stoppe pcscd-tsjinst leverje itselde utere symptoom, in ûnlêsber token, mei in folle ienfâldiger oplossing.

Wurkje fan it objekt nei bûten: sjocht p11tool it token, sjocht er it sertifikaat en de kaai, akseptearret OpenConnect de URI, en freegje dan pas oft de poarte de identiteit akseptearret. Eltse stap hat syn eigen flaterberjocht, en elk is goedkeaper te testen as de folgjende.