Millist PKCS#11 URI-t vajab OpenConnect tokeni jaoks?

Nutikaart, mis juba hoiab õiget võtit, peab ikkagi teada saama, millist objekti sellel kasutada. OpenConnect ei taha selles olukorras kopeeritud .key-faili; ta tahab PKCS#11 URI-t, mis nimetab sertifikaadi ja, kui automaatne otsing ei suuda tööd lõpetada, kõrval oleva privaatvõtme. Ebamugav osa on see, et süntaktiliselt korrektne URI ei tõesta midagi. See peab nimetama registreeringu, mida lüüs juba usaldab, mitte lihtsalt objekti, mille kaart on valmis avama.

Mida klient tahab eksporditud võtme asemel

Valik -c võtab tavaliselt failitee, kuid kui väärtus parsitakse PKCS#11 URI-na, käsitleb OpenConnect seda viitena tokeni sees olevale objektile, mitte kettal olevale failile. Valik -k käitub privaatvõtme puhul samamoodi. Midagi ei ekspordita ja võti ei lahku kunagi kaitse alt, mille kaart pakub. See, mida klient sinult vajab, on nimi, millega nõustuvad tokeni moodul, sertifikaatide hoidla ja lüüsi registreering.

Just viimase piirangu juures takerduvad enamik katseid. URI võib olla täiesti hästi vormistatud ja ikkagi valida sertifikaadi, mille lüüs tagasi lükkab, sest kehtivus ja asjakohasus on eraldi küsimused. Kontroll, mida tasub teha, on võrdlus registreeringu kirjega, mitte esimese juhuslikult avaneva objekti otsimine.

Kaks URI-t, kaks erinevat tööd

Sertifikaadi URI vastab sellele, millist identiteeti sa väidad. See osutab sertifikaadi objektile, mille avalik võti ja subjekti rida vastavad VPN-administraatori välja antud konto või seadme profiilile. Sama sertifikaat tuleb tavaliselt kaasa kõrval hoitava privaatvõtme objektiga ja just seda paari TLS-kätlus tegelikult vajab.

Võtme URI vastab sellele, kus asub vastav privaatmaterjal siis, kui OpenConnect ei suuda seda tuletada. Kui ainult -c on seatud, ehitab klient sertifikaadi omadustest võtmeotsingu; -k andmine asendab oletuse selgesõnalise objektiviitega. Tokeni PIN on kolmas, mitteseotud sisend: see avab kaardi toimingu jaoks ega identifitseeri kunagi objekti.

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

Kõik selles jutumärkides stringis on andmed. Semikoolonid eraldavad URI atribuute ja protsendiescaped kodeerivad märke, mis muidu parsija katki teeksid, seega peab kogu argument kestma shellist puutumatult.

Registreeringule vastava URI leidmine

GnuTLS-iga tuleb kaasas p11tool, mis loetleb, mida praegune kasutaja p11-kiti kaudu tegelikult kätte saab. Alusta käsuga p11tool --list-tokens, seejärel loetle sertifikaadi objektid tokenil, mis sind huvitab. Lisa --login, kui objektid ilmuvad alles pärast PIN-i, ja võrdle subjekti ja väljaandjat registreeringu kirjega, selle asemel et valida see, mis ilmub esimesena.

Kui token ei ilmu üldse, on probleem OpenConnectist allpool: p11-kitis pole selle vahetarkvara jaoks registreeritud moodulit või on moodul registreeritud teise konto jaoks. Süsteemitase registreering asub kausta /etc/pkcs11/modules all ja kasutajapõhine kataloog võib sisaldada sama, puutumata süsteemikoopiat. Kontrolli, et moodulifailis olev pakkuja tee osutab teegile, mille lugeja tarkvara tegelikult paigaldas.

Kui kopeerid URI loendist, hoia selle ümber jutumärgid. Jutumärkideta semikoolonid lõikavad argumendi esimese atribuudi juures ära ja klient teatab siis objektist, mida ta ei leia.

Kui automaatne võtmeotsing alla annab

OpenConnect suudab sertifikaadi URI-st tuletada võtmeotsingu, kuid täpne sobitamine, mida ta teeb, sõltub versioonist ning objektitüübi ja sildi käsitlemine on aja jooksul muutunud. Nõuanne lühendada URI-t, kuni see töötab, kirjeldab vana ajutist lahendust, mitte nõuet. Kui tuletatud otsing ebaõnnestub, nimeta võti selgesõnaliselt -k-ga, selle asemel et muuta sertifikaadi URI ebamäärasemaks.

Kinnita, et võti on olemas ja nähtav käsuga p11tool --list-keys, enne kui klienti süüdistad. Seejärel kontrolli, et objekt on märgitud allkirjastamiseks või dekrüpteerimiseks kasutatavaks, sest valede atribuutidega loodud võti ei suuda kätlust lõpetada, ükskõik kui korrektne URI on. Ära siirda serialiseeritud pkcs11-id väärtust OpenVPN-i profiilist OpenConnecti valikusse; kaks klienti kasutavad erinevaid identifikaatoriformaate isegi siis, kui nad räägivad sama kaardiga.

Kui URI laheneb ja PIN võetakse vastu, aga autentimine ikka ebaõnnestub, lõpeta URI häälestamine. Loe lüüsi enda viga, sest järgmine tõrge on tokenist kõrgemal.

Tõrked, mis ainult näivad URI probleemidena

Lüüs, mis räägib teist protokolli, ebaõnnestub ühtemoodi, olenemata sellest, kas sinu URI on õige või vale. OpenConnect vahetas vana vpnc kliendi põhjusega välja ja kaarditugi ei muuda ühildumatut lüüsiprotokolli ühilduvaks. Kinnita serveri eeldatav protokoll ja autentimise korraldus, enne kui kulutad veel tunni objektiatribuutidele.

Serveri identiteedi valideerimine on samuti eraldi kiht. Klient kontrollib lüüsi sertifikaati oma usaldushoidla vastu ja see kontroll toimub pärast seda, kui kaart on oma osa juba teinud. Lugeja õigused ja peatatud pcscd teenus tekitavad sama välise sümptomi, loetamatu tokeni, kuid parandus on palju lihtsam.

Tööta objektist väljapoole: kas p11tool näeb tokenit, kas ta näeb sertifikaati ja võtit, kas OpenConnect võtab URI vastu, ja alles siis küsi, kas lüüs võtab identiteedi vastu. Igal sammul on oma veateade ja igaüht on odavam testida kui järgmist.