Hvilken PKCS#11 URI trenger OpenConnect for et token?

Et smartkort som allerede har den riktige nøkkelen, må likevel få vite hvilket objekt på det som skal brukes. OpenConnect vil ikke ha en kopiert .key-fil i den situasjonen; det vil ha en PKCS#11 URI som navngir sertifikatet og, når den automatiske søkingen ikke kan fullføre jobben, den private nøkkelen ved siden av. Det vanskelige er at en syntaktisk gyldig URI ikke beviser noe. Den må navngi registreringen som gatewayen allerede stoler på, ikke bare et objekt kortet er villig til å åpne.

Hva klienten vil ha i stedet for en eksportert nøkkel

Alternativet -c tar normalt en filsti, men når verdien parses som en PKCS#11 URI, behandler OpenConnect den som en referanse til et objekt inne i tokenet i stedet for til en fil på disken. Alternativet -k oppfører seg på samme måte for den private nøkkelen. Ingenting eksporteres, og nøkkelen forlater aldri beskyttelsen kortet gir. Det klienten trenger fra deg, er et navn som tokenmodulen, sertifikatlagret og registreringen i gatewayen er enige om.

Det er ved den siste begrensningen de fleste forsøkene stopper. En URI kan være fullstendig velformet og likevel velge et sertifikat som gatewayen vil avvise, fordi gyldighet og relevans er separate spørsmål. Kontrollen som er verdt å gjøre, er en sammenligning med registreringsposten, ikke en leting etter det første objektet som tilfeldigvis åpnes.

To URI-er, to forskjellige jobber

Sertifikatets URI svarer på hvilken identitet du gjør krav på. Den peker på et sertifikatobjekt der den offentlige nøkkelen og subjektlinjen samsvarer med konto- eller enhetsprofilen som VPN-administratoren har utstedt. Det samme sertifikatet kommer vanligvis med et objekt for den private nøkkelen lagret ved siden av, og det paret er det TLS-håndtrykket faktisk trenger.

Nøkkelens URI svarer på hvor det samsvarende private materialet bor når OpenConnect ikke kan utlede det. Med bare -c satt bygger klienten et nøkkelsøk fra sertifikatets egenskaper; å oppgi -k erstatter gjettingen med en eksplisitt objektreferanse. Tokenets PIN er en tredje, uavhengig inndata: den låser opp kortet for operasjonen, og den identifiserer aldri et 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. Semikolonene skiller URI-egenskaper, og prosent-escapene koder tegn som ellers ville bryte parsingen, så hele argumentet må overleve skallet intakt.

Finne URI-en som passer til registreringen din

GnuTLS leverer p11tool, som viser hva den gjeldende brukeren faktisk kan nå gjennom p11-kit. Begynn med p11tool --list-tokens, og list deretter sertifikatobjektene på tokenet du bryr deg om. Legg til --login når objektene bare vises etter en PIN, og sammenlign subjekt og utsteder med registreringsposten i stedet for å velge det som vises først.

Hvis tokenet ikke vises i det hele tatt, ligger problemet under OpenConnect: p11-kit har ingen modul registrert for den mellomvaren, eller modulen er registrert for en annen konto. Systemomfattende registrering ligger under /etc/pkcs11/modules, og en mappe per bruker kan inneholde det samme uten å røre systemkopien. Kontroller at leverandørstien i modulfilen peker på et bibliotek som leserens programvare faktisk installerte.

Når du kopierer URI-en ut av listen, behold anførselstegnene rundt den. Semikolon uten anførselstegn kutter argumentet ved den første egenskapen, og klienten rapporterer da et objekt den ikke finner.

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

OpenConnect kan utlede et nøkkelsøk fra sertifikatets URI, men den nøyaktige matchingen den gjør, avhenger av versjonen, og håndteringen av objekttype og etikett har endret seg over tid. Rådet om å forkorte URI-en til den virker, beskriver en gammel omvei, ikke et krav. Hvis det utledede søket mislykkes, navngi nøkkelen eksplisitt med -k i stedet for å redigere sertifikatets URI til noe mer vagt.

Bekreft at nøkkelen finnes og er synlig med p11tool --list-keys før du klandrer klienten. Kontroller deretter at objektet er merket som brukbart for signering eller dekryptering, fordi en nøkkel generert med feil egenskaper ikke kan fullføre et håndtrykk, uansett hvor korrekt URI-en er. Ikke flytt en serialisert pkcs11-id-verdi fra en OpenVPN-profil over i et OpenConnect-alternativ; de to klientene bruker forskjellige identifikatorformater selv når de snakker med samme kort.

Hvis URI-en løses opp og PIN-en godtas, men autentiseringen fortsatt mislykkes, slutt å justere URI-en. Les gatewayens egen feil, fordi den neste feilen ligger over tokenet.

Feil som bare ser ut som URI-problemer

En gateway som snakker en annen protokoll, vil feile identisk uansett om URI-en din er riktig eller ikke. OpenConnect erstattet den gamle vpnc-klienten av en grunn, og kortstøtte gjør ikke en inkompatibel gatewayprotokoll kompatibel. Bekreft serverens forventede protokoll og autentiseringsoppsettet før du bruker enda en time på objektegenskaper.

Validering av serveridentitet er også et eget lag. Klienten verifiserer gatewayens sertifikat mot sitt tillitslager, og den kontrollen kjøres etter at kortet allerede har gjort sin del. Lesertillatelser og en stoppet pcscd-tjeneste gir det samme ytre symptomet, et uleselig token, med en mye enklere løsning.

Arbeid utover fra objektet: ser p11tool tokenet, ser det sertifikatet og nøkkelen, godtar OpenConnect URI-en, og først da spør du om gatewayen godtar identiteten. Hvert trinn har sin egen feilmelding, og hvert trinn er billigere å teste enn det neste.