Prečo OpenVPN stále žiada súbor súkromného kľúča, aj keď máte token
Profil pravdepodobne token nikdy neuviedol. Oddeľte knižnicu poskytovateľa od serializovanej identity certifikátu a potom testujte z procesu, ktorý nadväzuje spojenie.
Vložíte token, nástroj samotného dodávateľa ho vidí, a klient VPN napriek tomu žiada súbor súkromného kľúča. Táto výzva nie je dôkazom, že token nie je podporovaný. Zvyčajne znamená, že profil klientovi nikdy nepovedal, aby token použil, a tak sa vrátil k položkám certifikátu a kľúča, ktoré očakáva predvolene.
Predtým, než sa tento návrat zastaví, musia byť správne dve samostatné hodnoty: poskytovateľ, ktorý token sprístupňuje, a identita certifikátu v ňom. Zadávajú sa rôznymi voľbami a ľahko sa zamieňajú.
Klient žiada súbor, pretože to profil určuje
Predvolený profil očakáva súbor certifikátu a súbor súkromného kľúča alebo jeden balík PKCS#12. Keď tieto vstupy chýbajú, klient nemá čo načítať a správa sa takmer ako pri chýbajúcom súbore, preto sa príznak číta ako pokazená cesta, nie ako chýbajúci mechanizmus. Cesta PKCS#11 tieto vstupy nahrádza, namiesto toho, aby ich dopĺňala, takže profil, ktorý stále uvádza súbor kľúča, bude súbor ďalej používať. Odstráňte súborové vstupy zámerne a nechajte token dodať obe polovice.
Voľba poskytovateľa označuje knižnicu middlewaru, nie zariadenie a nie certifikát. Či zabalený klient dokáže túto knižnicu načítať, závisí od toho, ako bol zostavený, vrátane voliteľnej podpory p11-kit, ktorú niektoré zostavenia zapínajú a iné vynechávajú. Všeobecný návod vám nepovie, aké usporiadanie má váš balík.
Serializovaná identita je iná hodnota
Identita certifikátu je dlhý serializovaný reťazec, ktorý vytvára proces zisťovania, a nie je to cesta ku knižnici, PIN tokenu ani názov účtu VPN. Často obsahuje znaky, ktoré treba uzavrieť do úvodzoviek, a hodnota bez úvodzoviek môže byť skrátená alebo nesprávne prečítaná bez jasnej chyby. Použite vlastnú voľbu klienta zisťovanie identity, aby ste vypísali, čo token sprístupňuje, a potom zamýšľanú položku presne skopírujte. Výber prvého objektu v zozname je spôsob, akým zariadenie napokon predloží nesprávny certifikát.
Výstup zisťovania odpovedá aj na predchádzajúcu otázku: či je token cez tohto poskytovateľa vôbec viditeľný. Ak nič nevypisuje, problém je nad klientom VPN a patrí middlewaru.
Proces, ktorý sa pripája, musí na token dosiahnuť
Operácia s tokenom, ktorá funguje v relácii vašej plochy, nič nedokazuje o systémovej službe. Služba môže bežať ako iný používateľ, v inom mennom priestore pripojenia, s cestou k modulom, ktorá vynecháva knižnicu poskytovateľa, alebo bez oprávnenia otvoriť uzol zariadenia. Zistite, ktorý proces spojenie skutočne drží, a testujte z tohto kontextu.
Zaobchádzanie s PIN si zaslúži vlastné rozhodnutie. Referenčná implementácia ponúka vyrovnávaciu pamäť PIN a chránenú cestu overovania a obe existujú preto, aby si operátor mohol vybrať pracovný postup namiesto toho, aby ho vymýšľal. Nepremieňajte požiadavku bez dozoru na PIN v otvorenom texte v zdieľanom profile, pretože to vymieňa ochranu tokenu za pohodlie. Tam, kde token zakazuje export kľúča, podpisovanie prebieha v zariadení a PIN je jediným lokálnym tajomstvom. Zaobchádzajte s ním s opatrnosťou, ktorú to vyžaduje.
Čo token nenahrádza
Token overuje klienta podľa nasadenej politiky a nenahrádza kontroly klienta voči serveru. Úspešne vybraný certifikát nie je povolením prijať neočakávaný certifikát brány a obe overenia chránia opačné smery.
Zápis sa stále musí uskutočniť u vydavateľa a brána stále musí identitu autorizovať.
Pre prijatie oddeľte fázy: poskytovateľ sa načíta, zamýšľaný certifikát sa nájde, súkromný kľúč sa použije s lokálnym oprávnením, VPN sa overí a operácia s prostriedkom uspeje. Zastavte sa na prvej fáze, ktorá zlyhá, namiesto prechádzania hesiel a preinštalovania kryptografického zásobníka.
Zaznamenajte verzie, vlastníctvo modulov, zvolený verejný identifikátor a vyčistené chyby a PIN-y a balíky prihlasovacích údajov nechajte mimo tohto záznamu.