Kva PKCS#11 URI treng OpenConnect for eit token?

Eit smartkort som alt har den rette nøkkelen, må likevel få vita kva objekt på det som skal brukast. OpenConnect vil ikkje ha ei kopiert .key-fil i den situasjonen; det vil ha ein PKCS#11 URI som namngir sertifikatet og, når den automatiske søkinga ikkje kan fullføra jobben, den private nøkkelen ved sida av. Det vanskelege er at ein syntaktisk gyldig URI ikkje provar noko. Han må namngje registreringa som gatewayen alt stolar på, ikkje berre eit objekt kortet er viljugt til å opna.

Kva klienten vil ha i staden for ein eksportert nøkkel

Valet -c tek normalt ein filsti, men når verdien blir parsa som ein PKCS#11 URI, handsamar OpenConnect han som ei tilvising til eit objekt inne i tokenet i staden for til ei fil på disken. Valet -k gjer det same for den private nøkkelen. Ingenting blir eksportert, og nøkkelen forlét aldri vernet kortet gir. Det klienten treng frå deg, er eit namn som tokenmodulen, sertifikatarkivet og registreringa i gatewayen er samde om.

Det er ved den siste avgrensinga dei fleste forsøka stoppar. Ein URI kan vera fullstendig velforma og likevel velja eit sertifikat som gatewayen vil avvisa, fordi gyldigheit og relevans er separate spørsmål. Kontrollen som er verdt å gjera, er ein samanlikning med registreringsposten, ikkje ein leiting etter det første objektet som tilfeldigvis opnar.

To URI-ar, to ulike jobbar

URI-en til sertifikatet svarar på kva identitet du gjer krav på. Han peikar på eit sertifikatobjekt der den offentlege nøkkelen og subjektlinja samsvarar med konto- eller einingprofilen som VPN-administratoren har gjeve ut. Det same sertifikatet kjem vanlegvis med eit objekt for den private nøkkelen lagra ved sida, og det paret er det TLS-handtrykket faktisk treng.

URI-en til nøkkelen svarar på kvar det samsvarande private materialet bur når OpenConnect ikkje kan utleia det. Med berre -c sett byggjer klienten eit nøkkelsøk frå eigenskapane til sertifikatet; å oppgje -k erstattar gissinga med ei eksplisitt objekttilvising. PIN-en til tokenet er ei tredje, urelatert inndata: han låser opp kortet for operasjonen, og han identifiserer aldri eit objekt.

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

Alt i den siterte strengen er data. Semikolona skil URI-eigenskapar, og prosent-escapane kodar teikn som elles ville bryta parseringa, så heile argumentet må overleva skalet intakt.

Finna URI-en som passar til registreringa di

GnuTLS leverer p11tool, som viser kva den gjeldande brukaren faktisk kan nå gjennom p11-kit. Byrja med p11tool --list-tokens, og list deretter sertifikatobjekta på tokenet du bryr deg om. Legg til --login når objekta berre blir viste etter ein PIN, og samanlikn subjekt og utgivar med registreringsposten i staden for å velja det som blir vist først.

Viss tokenet ikkje blir vist i det heile, ligg problemet under OpenConnect: p11-kit har ingen modul registrert for den mellomvara, eller modulen er registrert for ein annan konto. Systemomfattande registrering ligg under /etc/pkcs11/modules, og ei mappe per brukar kan innehalda det same utan å røra systemkopien. Kontroller at leverandørstien i modulfila peikar på eit bibliotek som programvara til lesaren faktisk installerte.

Når du kopierer URI-en ut av lista, hald på hermeteikna rundt han. Semikolon utan hermeteikn kuttar argumentet ved den første eigenskapen, og klienten rapporterer då eit objekt han ikkje finn.

Når det automatiske nøkkelsøket gir opp

OpenConnect kan utleia eit nøkkelsøk frå URI-en til sertifikatet, men den nøyaktige matchinga han gjer, avheng av versjonen, og handsaminga av objekttype og etikett har endra seg over tid. Rådet om å forkorta URI-en til han verkar, skildrar ein gammal omveg, ikkje eit krav. Viss det utleidde søket mislukkast, namngje nøkkelen eksplisitt med -k i staden for å redigera URI-en til sertifikatet til noko meir vagt.

Stadfest at nøkkelen finst og er synleg med p11tool --list-keys før du klandrar klienten. Kontroller deretter at objektet er merkt som brukande for signering eller dekryptering, fordi ein nøkkel generert med feil eigenskapar ikkje kan fullføra eit handtrykk, uansett kor korrekt URI-en er. Ikkje flytt ein serialisert pkcs11-id-verdi frå ein OpenVPN-profil over i eit OpenConnect-val; dei to klientane brukar ulike identifikatorformat sjølv når dei snakkar med same kort.

Viss URI-en blir løyst opp og PIN-en blir godteken, men autentiseringa framleis mislukkast, slutt å justera URI-en. Les feilen til gatewayen sjølv, fordi den neste feilen ligg over tokenet.

Feil som berre ser ut som URI-problem

Ein gateway som snakkar ein annan protokoll, vil mislukkast identisk uansett om URI-en din er rett eller ikkje. OpenConnect erstatta den gamle vpnc-klienten av ein grunn, og kortstøtte gjer ikkje ein inkompatibel gatewayprotokoll kompatibel. Stadfest den forventa protokollen til tenaren og autentiseringsoppsettet før du brukar endå ein time på objekteigenskapar.

Validering av tenaridentitet er òg eit eige lag. Klienten verifiserer sertifikatet til gatewayen mot tillitslageret sitt, og den kontrollen køyrer etter at kortet alt har gjort sin del. Lesartillatingar og ein stoppa pcscd-teneste gir det same ytre symptomet, eit uleseleg token, med ei mykje enklare løysing.

Arbeid utover frå objektet: ser p11tool tokenet, ser det sertifikatet og nøkkelen, godtek OpenConnect URI-en, og først då spør du om gatewayen godtek identiteten. Kvart steg har si eiga feilmelding, og kvart steg er billegare å testa enn det neste.