Ktorý PKCS#11 URI potrebuje OpenConnect pre token?

Čipová karta, ktorá už obsahuje správny kľúč, musí napriek tomu dostať pokyn, ktorý objekt na nej použiť. OpenConnect v takej situácii nechce skopírovaný súbor .key; chce PKCS#11 URI, ktorý pomenúva certifikát a, keď automatické hľadanie nemôže prácu dokončiť, súkromný kľúč vedľa neho. Nepríjemné je, že syntakticky platný URI nič nedokazuje. Musí pomenovať registráciu, ktorej brána už dôveruje, nie len objekt, ktorý je karta ochotná otvoriť.

Čo klient chce namiesto exportovaného kľúča

Voľba -c zvyčajne prijíma cestu k súboru, ale keď sa hodnota analyzuje ako PKCS#11 URI, OpenConnect ju považuje za odkaz na objekt vnútri tokenu, nie na súbor na disku. Voľba -k sa pri súkromnom kľúči správa rovnako. Nič sa neexportuje a kľúč nikdy neopustí ochranu, ktorú karta poskytuje. Klient od vás potrebuje meno, na ktorom sa zhodnú modul tokenu, úložisko certifikátov a registrácia v bráne.

Práve na tomto poslednom obmedzení zlyhá väčšina pokusov. URI môže byť úplne dobre vytvorený a napriek tomu vybrať certifikát, ktorý brána odmietne, pretože platnosť a relevantnosť sú oddelené otázky. Kontrola, ktorá stojí za to, je porovnanie so záznamom registrácie, nie hľadanie prvého objektu, ktorý sa náhodou otvorí.

Dva URI, dve rôzne úlohy

URI certifikátu odpovedá, ktorú identitu si nárokujete. Ukazuje na objekt certifikátu, ktorého verejný kľúč a riadok subjektu zodpovedajú profilu účtu alebo zariadenia, ktorý vydal správca VPN. Ten istý certifikát zvyčajne prichádza s objektom súkromného kľúča uloženým vedľa neho, a práve túto dvojicu TLS handshake skutočne potrebuje.

URI kľúča odpovedá, kde sa nachádza príslušný súkromný materiál, keď ho OpenConnect nedokáže odvodiť. Pri nastavenom iba -c klient zostaví hľadanie kľúča z vlastností certifikátu; uvedenie -k nahradí hádanie výslovným odkazom na objekt. PIN tokenu je tretí, nesúvisiaci vstup: odomyká kartu pre operáciu a nikdy neidentifikuje objekt.

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

Všetko v tom citovanom reťazci sú dáta. Bodkočiarky oddeľujú atribúty URI a percentuálne eskapy kódujú znaky, ktoré by inak rozbili analýzu, preto musí celý argument prejsť shellom neporušený.

Nájdenie URI, ktorý zodpovedá vašej registrácii

GnuTLS dodáva p11tool, ktorý vypisuje, k čomu sa aktuálny používateľ naozaj dostane cez p11-kit. Začnite s p11tool --list-tokens a potom vypíšte objekty certifikátov na tokene, ktorý vás zaujíma. Pridajte --login, keď sa objekty zjavia až po PIN, a porovnajte subjekt a vydavateľa so záznamom registrácie, namiesto toho, aby ste vybrali to, čo sa zjaví prvé.

Ak sa token vôbec neobjaví, problém je pod OpenConnect: p11-kit nemá zaregistrovaný modul pre ten middleware alebo je modul zaregistrovaný pre iný účet. Systémová registrácia je v /etc/pkcs11/modules a používateľský adresár môže obsahovať to isté bez toho, aby sa dotkol systémovej kópie. Skontrolujte, či cesta poskytovateľa v súbore modulu ukazuje na knižnicu, ktorú softvér čítačky skutočne nainštaloval.

Keď URI kopírujete z výpisu, ponechajte okolo neho úvodzovky. Bodkočiarky bez úvodzoviek skrátia argument pri prvom atribúte a klient potom hlási objekt, ktorý nedokáže nájsť.

Keď automatické hľadanie kľúča vzdá

OpenConnect dokáže odvodiť hľadanie kľúča z URI certifikátu, ale presné párovanie, ktoré vykonáva, závisí od verzie a zaobchádzanie s typom objektu a štítkom sa časom menilo. Rada skracovať URI, kým nefunguje, opisuje starý obchvat, nie požiadavku. Ak odvodené hľadanie zlyhá, pomenujte kľúč výslovne pomocou -k, namiesto toho, aby ste URI certifikátu premenili na niečo nejasnejšie.

Predtým, než obviníte klienta, potvrďte, že kľúč existuje a je viditeľný pomocou p11tool --list-keys. Potom skontrolujte, či je objekt označený ako použiteľný na podpis alebo dešifrovanie, pretože kľúč vytvorený s nesprávnymi atribútmi nemôže dokončiť handshake, nech je URI akokoľvek správny. Nepresúvajte serializovanú hodnotu pkcs11-id z profilu OpenVPN do voľby OpenConnect; oba klienty používajú rôzne formáty identifikátora, aj keď hovoria s tou istou kartou.

Ak sa URI vyrieši a PIN je prijatý, ale autentifikácia stále zlyháva, prestaňte URI ladit. Prečítajte si chybu samotnej brány, pretože ďalšie zlyhanie je nad tokenom.

Zlyhania, ktoré len vyzerajú ako problémy s URI

Brána, ktorá hovorí iným protokolom, zlyhá rovnako, či je váš URI správny alebo nie. OpenConnect nahradil starý klient vpnc z nejakého dôvodu a podpora kariet neurobí nekompatibilný protokol brány kompatibilným. Potvrďte očakávaný protokol servera a usporiadanie autentifikácie, skôr než strávite ďalšiu hodinu atribútmi objektu.

Overovanie identity servera je tiež samostatná vrstva. Klient overuje certifikát brány voči svojmu úložisku dôvery a táto kontrola prebieha po tom, čo karta už urobila svoju časť. Práva čítačky a zastavená služba pcscd vytvárajú rovnaký vonkajší príznak, nečitateľný token, s oveľa jednoduchšou opravou.

Pracujte od objektu von: vidí p11tool token, vidí certifikát a kľúč, prijíma OpenConnect URI, a až potom sa pýtajte, či brána prijíma identitu. Každý krok má vlastnú chybovú správu a každý je lacnejší na testovanie než ten nasledujúci.