Kokio PKCS#11 URI reikia OpenConnect žetonui?

Išmanioji kortelė, kurioje jau yra teisingas raktas, vis tiek turi sužinoti, kurį objektą joje naudoti. OpenConnect tokioje situacijoje nenori nukopijuoto .key failo; jam reikia PKCS#11 URI, įvardijančio sertifikatą, o kai automatinė paieška negali baigti darbo, ir šalia esantį privatų raktą. Nepatogumas tas, kad sintaksiškai teisingas URI nieko neįrodo. Jis turi įvardyti tą registraciją, kuria vartai jau pasitiki, o ne vien objektą, kurį kortelė sutinka atverti.

Ko klientas nori vietoj eksportuoto rakto

-c parinktis paprastai priima failo kelią, bet kai reikšmė analizuojama kaip PKCS#11 URI, OpenConnect ją traktuoja kaip nuorodą į objektą žetono viduje, o ne į failą diske. -k parinktis elgiasi taip pat su privačiu raktu. Niekas neeksportuojama, ir raktas niekada nepalieka kortelės teikiamos apsaugos. Klientui iš jūsų reikia vardo, dėl kurio sutartų žetono modulis, sertifikatų saugykla ir vartų registracija.

Būtent ties šiuo paskutiniu apribojimu sustoja dauguma bandymų. URI gali būti visiškai taisyklingai sudarytas ir vis tiek pasirinkti sertifikatą, kurį vartai atmes, nes galiojimas ir aktualumas yra atskiri klausimai. Verta atlikti patikrą – palyginimą su registracijos įrašu, o ne pirmo atsitiktinai atsiveriančio objekto paiešką.

Du URI, du skirtingi darbai

Sertifikato URI atsako, kokią tapatybę jūs teigiate. Jis nurodo sertifikato objektą, kurio viešasis raktas ir subjekto eilutė atitinka VPN administratoriaus išduotą paskyros ar įrenginio profilį. Tas pats sertifikatas paprastai ateina su šalia saugomu privataus rakto objektu, ir būtent šios poros TLS rankos paspaudimui iš tikrųjų reikia.

Rakto URI atsako, kur yra atitinkama privati medžiaga, kai OpenConnect negali jos nustatyti. Nustačius tik -c, klientas iš sertifikato savybių sukuria rakto paiešką; nurodžius -k spėjimas pakeičiamas aiškia objekto nuoroda. Žetono PIN yra trečia, nesusijusi įvestis: ji atrakina kortelę operacijai ir niekada nenustato objekto.

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

Viskas toje kabutėse esančioje eilutėje yra duomenys. Kabliataškiai skiria URI atributus, o procentiniai escape'ai užkoduoja simbolius, kurie kitaip sugadintų analizę, todėl visas argumentas turi nepažeistas praeiti pro apvalkalą.

Rasti jūsų registraciją atitinkantį URI

GnuTLS pateikia p11tool, kuris išvardija, ką dabartinis naudotojas tikrai gali pasiekti per p11-kit. Pradėkite nuo p11tool --list-tokens, tada išvardykite dominančio žetono sertifikato objektus. Pridėkite --login, kai objektai atsiranda tik po PIN, ir palyginkite subjektą bei išdavėją su registracijos įrašu, o ne rinkitės pirmo pasirodžiusio.

Jei žetonas visai neatsiranda, problema yra žemiau OpenConnect: p11-kit neturi užregistruoto modulio tai tarpinei programinei įrangai, arba modulis užregistruotas kitai paskyrai. Sisteminė registracija yra /etc/pkcs11/modules, o kiekvieno naudotojo katalogas gali laikyti tą patį neliesdamas sistemos kopijos. Patikrinkite, ar modulio faile esantis tiekėjo kelias nurodo biblioteką, kurią skaitytuvo programinė įranga tikrai įdiegė.

Kai kopijuojate URI iš sąrašo, palikite kabutes aplink jį. Kabučių neturinčios kabliataškiai nukerta argumentą ties pirmuoju atributu, ir klientas tada praneša apie objektą, kurio neranda.

Kai automatinė rakto paieška pasiduoda

OpenConnect gali išvesti rakto paiešką iš sertifikato URI, bet tiksli atitiktis, kurią jis atlieka, priklauso nuo versijos, o objekto tipo ir žymės apdorojimas laikui bėgant keitėsi. Patarimas trumpinti URI, kol jis pradės veikti, apibūdina seną apėjimą, o ne reikalavimą. Jei išvesta paieška nepavyksta, įvardykite raktą aiškiai su -k, o ne paverskite sertifikato URI kuo nors neaiškesniu.

Prieš kaltindami klientą patvirtinkite, kad raktas egzistuoja ir matomas su p11tool --list-keys. Tada patikrinkite, ar objektas pažymėtas kaip tinkamas parašui ar iššifravimui, nes raktas, sukurtas su neteisingais atributais, negali užbaigti rankos paspaudimo, kad ir koks teisingas būtų URI. Neperkelkite serializuotos pkcs11-id reikšmės iš OpenVPN profilio į OpenConnect parinktį; abu klientai naudoja skirtingus identifikatoriaus formatus, net kai kalba su ta pačia kortele.

Jei URI išsprendžiamas ir PIN priimamas, bet autentifikavimas vis tiek nepavyksta, nustokite derinti URI. Perskaitykite paties vartų klaidą, nes kita nesėkmė yra aukščiau žetono.

Nesėkmės, kurios tik atrodo kaip URI problemos

Vartai, kalbantys kitu protokolu, nepavyks vienodai, nesvarbu, ar jūsų URI teisingas, ar ne. OpenConnect pakeitė seną vpnc klientą dėl priežasties, o kortelių palaikymas nepadaro nesuderinamo vartų protokolo suderinamu. Patvirtinkite laukiamą serverio protokolą ir autentifikavimo išdėstymą, prieš išleisdami dar valandą objekto atributams.

Serverio tapatybės tikrinimas taip pat atskiras sluoksnis. Klientas tikrina vartų sertifikatą savo pasitikėjimo saugykloje, ir ši patikra vykdoma po to, kai kortelė jau atliko savo dalį. Skaitytuvo teisės ir sustabdyta pcscd paslauga sukuria tą patį išorinį simptomą, neperskaitomą žetoną, tačiau su daug paprastesniu sprendimu.

Dirbkite nuo objekto į išorę: ar p11tool mato žetoną, ar mato sertifikatą ir raktą, ar OpenConnect priima URI, ir tik tada klauskite, ar vartai priima tapatybę. Kiekvienas žingsnis turi savo klaidos pranešimą, ir kiekvieną pigiau patikrinti nei kitą.