Jaký PKCS#11 URI OpenConnect pro token potřebuje?

Čipová karta, která už správný klíč obsahuje, musí stejně dostat pokyn, který objekt na ní použít. OpenConnect v takové situaci nechce zkopírovaný soubor .key; chce PKCS#11 URI, který pojmenuje certifikát a, když automatické hledání nemůže práci dokončit, soukromý klíč vedle něj. Nepříjemné je, že syntakticky platný URI nic nedokazuje. Musí pojmenovat zápis, kterému brána už důvěřuje, ne jen objekt, který je karta ochotna otevřít.

Co klient chce místo exportovaného klíče

Volba -c obvykle přijímá cestu k souboru, ale když se hodnota analyzuje jako PKCS#11 URI, OpenConnect ji považuje za odkaz na objekt uvnitř tokenu, nikoli na soubor na disku. Volba -k se u soukromého klíče chová stejně. Nic se neexportuje a klíč nikdy neopustí ochranu, kterou karta poskytuje. Co klient od vás potřebuje, je jméno, na kterém se shodnou modul tokenu, úložiště certifikátů a zápis v bráně.

Právě na posledním omezení většina pokusů ztroskotá. URI může být naprosto dobře vytvořený a přesto vybrat certifikát, který brána odmítne, protože platnost a relevance jsou oddělené otázky. Kontrola, která stojí za to, je srovnání se záznamem zápisu, ne hledání prvního objektu, který se náhodou otevře.

Dva URI, dvě různé úlohy

URI certifikátu odpovídá na to, kterou identitu si nárokujete. Ukazuje na objekt certifikátu, jehož veřejný klíč a řádek subjektu odpovídají profilu účtu nebo zařízení, který vydal správce VPN. Tentýž certifikát obvykle přichází s objektem soukromého klíče uloženým vedle něj, a právě tuto dvojici TLS handshake skutečně potřebuje.

URI klíče odpovídá na to, kde odpovídající soukromý materiál žije, když ho OpenConnect nedokáže odvodit. Při pouhém -c klient sestaví hledání klíče z vlastností certifikátu; zadání -k nahradí hádání výslovným odkazem na objekt. PIN tokenu je třetí, nesouvisející vstup: odemyká kartu pro operaci a nikdy neidentifikuje objekt.

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

Všechno v tom citovaném řetězci jsou data. Středníky oddělují atributy URI a procentní escapy kódují znaky, které by jinak rozbily analýzu, takže celý argument musí ve shellu přežít neporušený.

Nalezení URI, který odpovídá vašemu zápisu

GnuTLS dodává p11tool, který vypisuje, k čemu aktuální uživatel skutečně dosáhne přes p11-kit. Začněte s p11tool --list-tokens a potom vypište objekty certifikátů na tokenu, který vás zajímá. Přidejte --login, když se objekty objeví až po PIN, a porovnejte subjekt a vydavatele se záznamem zápisu, místo abyste vybrali to, co se objeví první.

Pokud se token vůbec neobjeví, problém je pod OpenConnect: p11-kit nemá pro tento middleware zaregistrovaný modul, nebo je modul zaregistrovaný pro jiný účet. Systémová registrace žije v /etc/pkcs11/modules a uživatelský adresář může držet totéž, aniž by se dotkl systémové kopie. Zkontrolujte, že cesta poskytovatele v souboru modulu ukazuje na knihovnu, kterou software čtečky skutečně nainstaloval.

Když URI kopírujete z výpisu, ponechte kolem něj uvozovky. Neocitované středníky zkrátí argument na prvním atributu a klient pak hlásí objekt, který nemůže najít.

Když automatické hledání klíče vzdá

OpenConnect umí odvodit hledání klíče z URI certifikátu, ale přesné párování, které provádí, závisí na verzi a zacházení s typem objektu a popiskem se časem měnilo. Rada zkracovat URI, dokud nefunguje, popisuje starý obchvat, ne požadavek. Pokud odvozené hledání selže, pojmenujte klíč výslovně pomocí -k, místo abyste URI certifikátu upravovali na něco vágnějšího.

Než obviníte klienta, potvrďte, že klíč existuje a je viditelný pomocí p11tool --list-keys. Potom zkontrolujte, že objekt je označen jako použitelný pro podpis nebo dešifrování, protože klíč vytvořený se špatnými atributy nemůže dokončit handshake, ať je URI jakkoli správný. Nepřesouvejte serializovanou hodnotu pkcs11-id z profilu OpenVPN do volby OpenConnect; oba klienti používají různé formáty identifikátorů, i když mluví se stejnou kartou.

Pokud se URI vyřeší a PIN je přijat, ale ověření přesto selhává, přestaňte URI ladit. Přečtěte si vlastní chybu brány, protože další selhání je nad tokenem.

Selhání, která jen vypadají jako problémy s URI

Brána, která mluví jiným protokolem, selže stejně, ať je váš URI správný, nebo špatný. OpenConnect nahradil starý klient vpnc z nějakého důvodu a podpora karet neudělá nekompatibilní protokol brány kompatibilním. Potvrďte očekávaný protokol serveru a uspořádání ověřování, než strávíte další hodinu atributy objektu.

Ověřování identity serveru je také samostatná vrstva. Klient ověřuje certifikát brány proti svému úložišti důvěry a tato kontrola proběhne poté, co karta už udělala svou část. Oprávnění čtečky a zastavená služba pcscd dávají stejný vnější příznak, nečitelný token, s mnohem jednodušší opravou.

Postupujte od objektu ven: vidí p11tool token, vidí certifikát a klíč, přijímá OpenConnect URI, a teprve potom se ptejte, zda brána přijímá identitu. Každý krok má vlastní chybovou zprávu a každý je levnější na testování než ten následující.