Minkä PKCS#11 URI:n OpenConnect tarvitsee tokenille?

Älykortti, jolla on jo oikea avain, on silti kerrottava, mitä objektia siinä käytetään. OpenConnect ei halua siinä tilanteessa kopioitua .key-tiedostoa; se haluaa PKCS#11 URI:n, joka nimeää varmenteen ja, kun automaattinen haku ei voi suorittaa tehtävää loppuun, vieressä olevan yksityisen avaimen. Hankala osa on, ettei syntaktisesti kelvollinen URI todista mitään. Sen on nimettävä rekisteröinti, johon yhdyskäytävä jo luottaa, eikä vain objektia, jonka kortti on valmis avaamaan.

Mitä asiakas haluaa vientiavaimen sijaan

-c-valinta ottaa tavallisesti tiedostopolun, mutta kun arvo jäsennetään PKCS#11 URI:ksi, OpenConnect käsittelee sitä viittauksena tokenin sisällä olevaan objektiin eikä levyllä olevaan tiedostoon. -k-valinta käyttäytyy samoin yksityisen avaimen kohdalla. Mitään ei viedä, eikä avain koskaan poistu kortin tarjoamasta suojasta. Se, mitä asiakas tarvitsee sinulta, on nimi, josta tokenin moduuli, varmenteiden säilö ja yhdyskäytävän rekisteröinti ovat yhtä mieltä.

Juuri viimeisessä rajoituksessa useimmat yritykset pysähtyvät. URI voi olla täysin hyvin muodostettu ja silti valita varmenteen, jonka yhdyskäytävä hylkää, koska kelpoisuus ja oleellisuus ovat erillisiä kysymyksiä. Tarkistus, joka kannattaa tehdä, on vertailu rekisteröintitietueeseen, ei ensimmäisen sattumalta avautuvan objektin etsiminen.

Kaksi URI:ta, kaksi eri tehtävää

Varmenteen URI vastaa siihen, mitä identiteettiä väität. Se osoittaa varmenteen objektiin, jonka julkinen avain ja subjektirivi vastaavat VPN-ylläpitäjän myöntämää tili- tai laiteprofiilia. Sama varmenne tulee yleensä mukana viereen tallennetun yksityisen avaimen objektin kanssa, ja juuri sitä paria TLS-kättely todella tarvitsee.

Avaimen URI vastaa siihen, missä vastaava yksityinen materiaali sijaitsee, kun OpenConnect ei voi päätellä sitä. Kun vain -c on asetettu, asiakas rakentaa avainhaun varmenteen ominaisuuksista; -k:n antaminen korvaa arvailun nimenomaisella objektiviittauksella. Tokenin PIN on kolmas, asiaankuulumaton syöte: se avaa kortin toimintoa varten eikä koskaan tunnista objektia.

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

Kaikki tuossa lainausmerkit ympärillä olevassa merkkijonossa on dataa. Puolipisteet erottavat URI:n attribuutit ja prosenttiescapeilla koodataan merkit, jotka muuten rikkoisivat jäsennyksen, joten koko argumentin on selvittävä kuoresta ehjänä.

Rekisteröintiäsi vastaavan URI:n löytäminen

GnuTLS toimittaa p11toolin, joka luettelee, mihin nykyinen käyttäjä voi p11-kitin kautta todella päästä. Aloita komennolla p11tool --list-tokens ja luettele sitten kiinnostavan tokenin varmenneobjektit. Lisää --login, kun objektit ilmestyvät vasta PINin jälkeen, ja vertaa subjektia ja myöntäjää rekisteröintitietueeseen sen sijaan, että valitsisit ensimmäisenä näkyvän.

Jos token ei näy lainkaan, ongelma on OpenConnectin alapuolella: p11-kitissä ei ole rekisteröityä moduulia tuolle väliohjelmistolle tai moduuli on rekisteröity toiselle tilille. Järjestelmänlaajuinen rekisteröinti sijaitsee hakemistossa /etc/pkcs11/modules, ja käyttäjäkohtainen hakemisto voi sisältää saman koskematta järjestelmän kopioon. Tarkista, että moduulitiedoston tarjoajapolku osoittaa kirjastoon, jonka lukijan ohjelmisto todella asensi.

Kun kopioit URI:n luettelosta, pidä lainausmerkit sen ympärillä. Lainausmerkeittömät puolipisteet katkaisevat argumentin ensimmäiseen attribuuttiin, ja asiakas ilmoittaa silloin objektista, jota se ei löydä.

Kun automaattinen avainhaku luovuttaa

OpenConnect voi johtaa avainhaun varmenteen URI:sta, mutta tarkka sovitus, jonka se tekee, riippuu versiosta, ja objektityypin ja tunnisteen käsittely on muuttunut ajan myötä. Neuvo lyhentää URI:ta, kunnes se toimii, kuvaa vanhaa kiertotietä, ei vaatimusta. Jos johdettu haku epäonnistuu, nimeä avain nimenomaisesti -k:lla sen sijaan, että muokkaisit varmenteen URI:n epämääräisemmäksi.

Varmista, että avain on olemassa ja näkyy komennolla p11tool --list-keys, ennen kuin syytät asiakasta. Tarkista sitten, että objekti on merkitty käytettäväksi allekirjoitukseen tai salauksen purkuun, koska väärillä attribuuteilla luotu avain ei voi suorittaa kättelyä loppuun, olipa URI miten oikea tahansa. Älä siirrä serialisoitua pkcs11-id-arvoa OpenVPN-profiilista OpenConnect-valintaan; kaksi asiakasta käyttävät eri tunnistemuotoja, vaikka puhuisivat samalle kortille.

Jos URI ratkeaa ja PIN hyväksytään mutta todennus epäonnistuu silti, lopeta URI:n säätäminen. Lue yhdyskäytävän oma virhe, sillä seuraava epäonnistuminen on tokenin yläpuolella.

Epäonnistumiset, jotka vain näyttävät URI-ongelmilta

Yhdyskäytävä, joka puhuu eri protokollaa, epäonnistuu samalla tavalla riippumatta siitä, onko URI oikein vai väärin. OpenConnect korvasi vanhan vpnc-asiakkaan syystä, eikä korttituki tee yhteensopimatonta yhdyskäytäväprotokollaa yhteensopivaksi. Varmista palvelimen odotettu protokolla ja todennuksen järjestely ennen kuin käytät vielä tunnin objektin attribuutteihin.

Palvelimen identiteetin vahvistaminen on myös erillinen kerros. Asiakas tarkistaa yhdyskäytävän varmenteen luottamusvarastostaan, ja tarkistus ajetaan sen jälkeen, kun kortti on jo tehnyt osuutensa. Lukijan käyttöoikeudet ja pysäytetty pcscd-palvelu tuottavat saman ulkoisen oireen, lukukelvottoman tokenin, mutta korjaus on paljon yksinkertaisempi.

Työskentele objektista ulospäin: näkeekö p11tool tokenin, näkeekö se varmenteen ja avaimen, hyväksyykö OpenConnect URI:n, ja vasta sitten kysy, hyväksyykö yhdyskäytävä identiteetin. Jokaisella vaiheella on oma virheilmoituksensa, ja jokainen on halvempi testata kuin seuraava.