Proč se OpenVPN stále ptá na soubor soukromého klíče, i když máte token

Zapojíte token, nástroj samotného výrobce ho vidí, a klient VPN přesto žádá soubor soukromého klíče. Tato výzva není důkazem, že token není podporován. Obvykle znamená, že profil klientovi vůbec neřekl, aby token použil, a tak se vrátil k položkám certifikátu a klíče, které očekává ve výchozím nastavení.

Než se tento návrat zastaví, musí být správné dvě samostatné hodnoty: poskytovatel, který token zpřístupňuje, a identita certifikátu uvnitř něj. Zadávají se různými volbami a snadno se zamění.

Klient žádá soubor, protože to profil říká

Výchozí profil očekává soubor certifikátu a soubor soukromého klíče, nebo jeden balík PKCS#12. Když tyto položky chybí, klient nemá co načíst a chová se téměř jako při chybějícím souboru, a proto se příznak čte jako rozbitá cesta, nikoli jako chybějící mechanismus. Cesta PKCS#11 tyto položky nahrazuje, místo aby je doplňovala, takže profil, který stále uvádí soubor klíče, bude soubor dál používat. Odstraňte souborové položky záměrně a nechte token dodat obě poloviny.

Volba poskytovatele označuje knihovnu middlewaru, ne zařízení a ne certifikát. Zda zabalený klient dokáže tuto knihovnu načíst, závisí na tom, jak byl sestaven, včetně volitelné podpory p11-kit, kterou některá sestavení zapínají a jiná vynechávají. Obecný návod vám neřekne, jaké uspořádání má váš balíček.

Serializovaná identita je jiná hodnota

Identita certifikátu je dlouhý serializovaný řetězec, který vytváří proces zjišťování, a není to cesta ke knihovně, PIN tokenu ani název účtu VPN. Často obsahuje znaky, které je třeba uzavřít do uvozovek, a hodnota bez uvozovek může být zkrácena nebo špatně přečtena bez jasné chyby. Pomocí vlastní volby klienta zjišťování identity vypište, co token zpřístupňuje, a potom zamýšlenou položku přesně zkopírujte. Výběrem prvního objektu v seznamu zařízení nakonec představí nesprávný certifikát.

Výstup zjišťování také odpovídá na předchozí otázku: zda je token přes tohoto poskytovatele vůbec viditelný. Pokud nic nevypisuje, problém je výše než klient VPN a patří middlewaru.

Proces, který se připojuje, musí na token dosáhnout

Operace s tokenem, která funguje v relaci vaší plochy, nic nedokazuje o systémové službě. Služba může běžet jako jiný uživatel, v jiném jmenném prostoru připojení, s cestou k modulům, která vynechává knihovnu poskytovatele, nebo bez oprávnění otevřít uzel zařízení. Zjistěte, který proces spojení skutečně drží, a testujte z tohoto kontextu.

Práce s PIN si zaslouží vlastní rozhodnutí. Referenční implementace nabízí mezipaměť PIN a chráněnou cestu ověřování a obojí existuje proto, aby si operátor mohl vybrat pracovní postup, místo aby jej vymýšlel. Nepřevádějte požadavek bez dozoru na PIN v otevřeném textu ve sdíleném profilu, protože tím vyměňujete ochranu tokenu za pohodlí. Tam, kde token zakazuje export klíče, probíhá podepisování v zařízení a PIN je jediné místní tajemství. Zacházejte s ním s péčí, kterou to vyžaduje.

Co token nenahrazuje

Token ověřuje klienta podle nasazené politiky a nenahrazuje kontroly klienta vůči serveru. Úspěšně vybraný certifikát není svolením přijmout neočekávaný certifikát brány a obě ověření chrání opačné směry.

Zápis se stále musí uskutečnit u vydavatele a brána stále musí identitu autorizovat.

Pro přijetí oddělte fáze: poskytovatel se načte, zamýšlený certifikát se najde, soukromý klíč se použije s místním oprávněním, VPN se ověří a operace s prostředkem uspěje. Zastavte se u první fáze, která selže, místo abyste procházeli hesla a přeinstalovávali kryptografický stack.

Zaznamenejte verze, vlastnictví modulů, zvolený veřejný identifikátor a vyčištěné chyby a PIN a balíky pověření nechte mimo tento záznam.