Hvilken PKCS#11 URI har OpenConnect brug for til et token?

Et smartkort, der allerede har den rigtige nøgle, skal stadig have at vide, hvilket objekt på det der skal bruges. OpenConnect vil ikke have en kopieret .key-fil i den situation; det vil have en PKCS#11 URI, der navngiver certifikatet og, når den automatiske søgning ikke kan gøre arbejdet færdigt, den private nøgle ved siden af. Det besværlige er, at en syntaktisk gyldig URI ikke beviser noget. Den skal navngive den tilmelding, som gatewayen allerede stoler på, ikke blot et objekt, som kortet er villigt til at åbne.

Hvad klienten vil have i stedet for en eksporteret nøgle

Tilvalget -c tager normalt en filsti, men når værdien parses som en PKCS#11 URI, behandler OpenConnect den som en reference til et objekt inde i tokenet i stedet for til en fil på disken. Tilvalget -k opfører sig på samme måde for den private nøgle. Intet bliver eksporteret, og nøglen forlader aldrig den beskyttelse, kortet giver. Det, klienten har brug for fra dig, er et navn, som tokenmodulet, certifikatlageret og tilmeldingen i gatewayen er enige om.

Det er ved den sidste begrænsning, at de fleste forsøg går i stå. En URI kan være fuldstændig velformet og alligevel vælge et certifikat, som gatewayen vil afvise, fordi gyldighed og relevans er adskilte spørgsmål. Den kontrol, der er værd at lave, er en sammenligning med tilmeldingsposten, ikke en søgning efter det første objekt, der tilfældigvis åbner.

To URI'er, to forskellige opgaver

Certifikatets URI besvarer, hvilken identitet du gør krav på. Den peger på et certifikatobjekt, hvis offentlige nøgle og subjektlinje matcher den konto- eller enhedsprofil, som VPN-administratoren har udstedt. Det samme certifikat kommer normalt med et objekt til den private nøgle gemt ved siden af, og det par er, hvad TLS-håndtrykket faktisk har brug for.

Nøglens URI besvarer, hvor det matchende private materiale bor, når OpenConnect ikke kan udlede det. Med kun -c sat bygger klienten en nøglesøgning ud fra certifikatets egenskaber; angives -k, erstattes gætteriet af en eksplicit objektreference. Tokenets PIN er et tredje, uafhængigt input: det låser kortet op til handlingen, og det identificerer aldrig et objekt.

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

Alt i den citerede streng er data. Semikolonnerne adskiller URI-egenskaber, og procent-escapene koder tegn, der ellers ville ødelægge parsingen, så hele argumentet skal overleve shellen intakt.

Find den URI, der passer til din tilmelding

GnuTLS leverer p11tool, som viser, hvad den aktuelle bruger faktisk kan nå gennem p11-kit. Begynd med p11tool --list-tokens, og vis derefter certifikatobjekterne på det token, du er interesseret i. Tilføj --login, når objekterne først vises efter en PIN, og sammenlign subjekt og udsteder med tilmeldingsposten i stedet for at vælge det, der vises først.

Hvis tokenet slet ikke vises, ligger problemet under OpenConnect: p11-kit har ikke noget modul registreret til den middleware, eller modulet er registreret til en anden konto. Systemdækkende registrering ligger under /etc/pkcs11/modules, og en mappe per bruger kan indeholde det samme uden at røre systemkopien. Kontroller, at udbyderstien i modulfilen peger på et bibliotek, som læserens software faktisk har installeret.

Når du kopierer URI'en ud af listen, så behold anførselstegnene omkring den. Semikolonner uden anførselstegn afkorter argumentet ved den første egenskab, og klienten rapporterer derefter et objekt, den ikke kan finde.

Når den automatiske nøglesøgning giver op

OpenConnect kan udlede en nøglesøgning fra certifikatets URI, men den præcise matchning, den udfører, afhænger af versionen, og håndteringen af objekttype og label er ændret over tid. Råd, der siger, at du skal forkorte URI'en, indtil den virker, beskriver en gammel omvej, ikke et krav. Hvis den udledte søgning fejler, så navngiv nøglen eksplicit med -k i stedet for at redigere certifikatets URI til noget mere vagt.

Bekræft, at nøglen findes og er synlig med p11tool --list-keys, før du bebrejder klienten. Kontroller derefter, at objektet er markeret som brugbart til signering eller dekryptering, fordi en nøgle, der er genereret med forkerte egenskaber, ikke kan fuldføre et håndtryk, uanset hvor korrekt URI'en er. Flyt ikke en serialiseret pkcs11-id-værdi fra en OpenVPN-profil over i et OpenConnect-tilvalg; de to klienter bruger forskellige identifikatorformater, selv når de taler med det samme kort.

Hvis URI'en opløses, og PIN-koden accepteres, men godkendelsen stadig fejler, så hold op med at finjustere URI'en. Læs gatewayens egen fejl, for den næste fejl ligger oven for tokenet.

Fejl, der kun ligner URI-problemer

En gateway, der taler en anden protokol, vil fejle identisk, uanset om din URI er rigtig eller forkert. OpenConnect erstattede den gamle vpnc-klient af en grund, og kortunderstøttelse gør ikke en inkompatibel gatewayprotokol kompatibel. Bekræft serverens forventede protokol og godkendelsesopstilling, før du bruger endnu en time på objektegenskaber.

Validering af serveridentitet er også et separat lag. Klienten verificerer gatewayens certifikat mod sit tillidslager, og den kontrol kører, efter at kortet allerede har gjort sin del. Læsertilladelser og en stoppet pcscd-tjeneste giver det samme ydre symptom, et ulæseligt token, med en meget enklere løsning.

Arbejd udad fra objektet: ser p11tool tokenet, ser det certifikatet og nøglen, accepterer OpenConnect URI'en, og spørg først derefter, om gatewayen accepterer identiteten. Hvert trin har sin egen fejlmeddelelse, og hvert trin er billigere at teste end det næste.