Zašto OpenVPN i dalje traži datoteku privatnog ključa uz token

Umetnete token, dobavljačev vlastiti alat ga vidi, a VPN klijent i dalje traži datoteku privatnog ključa. Taj upit nije dokaz da token nije podržan. Obično znači da profil nikada nije rekao klijentu da koristi token, pa se vratio na unose certifikata i ključa koje očekuje prema zadanim postavkama.

Dvije odvojene vrijednosti moraju biti ispravne prije nego što se taj povratak zaustavi: dobavljač koji izlaže token i identitet certifikata unutar njega. One se zadaju različitim opcijama i lako ih je zamijeniti.

Klijent traži datoteku jer profil tako nalaže

Zadani profil očekuje datoteku certifikata i datoteku privatnog ključa ili jedan PKCS#12 paket. Kad ti unosi nedostaju, klijent nema što učitati i ponaša se gotovo kao kod nedostajuće datoteke, zbog čega se simptom čita kao pokvarena putanja, a ne kao nedostajući mehanizam. Putanja PKCS#11 zamjenjuje te unose umjesto da ih dopunjuje, pa će profil koji i dalje navodi datoteku ključa nastaviti koristiti tu datoteku. Namjerno uklonite datotečne unose i pustite tokenu da osigura obje polovine.

Opcija dobavljača imenuje biblioteku međusloja, a ne uređaj i ne certifikat. Može li pakirani klijent učitati tu biblioteku zavisi od toga kako je izgrađen, uključujući neobaveznu podršku za p11-kit koju neke gradnje uključuju, a druge izostavljaju. Opći vodič ne može vam reći kakav raspored ima vaš paket.

Serijalizirani identitet je druga vrijednost

Identitet certifikata je dugačak serijalizirani niz koji proizvodi proces otkrivanja i nije putanja biblioteke, PIN tokena ni naziv VPN računa. Često sadrži znakove koje treba staviti pod navodnike, a vrijednost bez navodnika može biti skraćena ili pogrešno pročitana bez jasne greške. Upotrijebite klijentovu vlastitu opciju otkrivanje identiteta da biste izlistali što token izlaže, zatim točno kopirajte željeni unos. Odabir prvog objekta na popisu način je na koji uređaj na kraju predstavi pogrešan certifikat.

Rezultat otkrivanja odgovara i na prethodno pitanje: je li token uopće vidljiv kroz tog dobavljača. Ako ništa ne izlistava, problem je iznad VPN klijenta i pripada međusloju.

Proces koji se povezuje mora doći do tokena

Radnja s tokenom koja uspijeva u vašoj radnoj sesiji ne dokazuje ništa o sistemskoj usluzi. Usluga može raditi kao drugi korisnik, u drugom montažnom imenskom prostoru, s putanjom modula koja izostavlja biblioteku dobavljača ili bez dopuštenja za otvaranje čvora uređaja. Utvrdite koji proces zapravo drži vezu i testirajte iz tog konteksta.

Rukovanje PIN-om zaslužuje zasebnu odluku. Referentna implementacija nudi keš PIN-a i zaštićenu putanju provjere autentičnosti, a oboje postoji kako bi operater mogao odabrati tijek rada umjesto da ga izmišlja. Ne pretvarajte zahtjev bez nadzora u PIN u čistom tekstu unutar zajedničkog profila, jer to zaštitu tokena mijenja za udobnost. Gdje token zabranjuje izvoz ključa, potpisivanje se događa na uređaju i PIN je jedina lokalna tajna. Tretirajte ga s pažnjom koju to podrazumijeva.

Što token ne zamjenjuje

Token provjerava autentičnost klijenta u okviru primijenjene politike i ne zamjenjuje klijentove provjere na poslužitelju. Uspješno odabran certifikat nije dopuštenje za prihvaćanje neočekivanog certifikata pristupnika, a te dvije provjere štite suprotne smjerove.

Upis se i dalje mora dogoditi kod izdavatelja, a pristupnik i dalje mora ovlastiti identitet.

Za prihvaćanje razdvojite faze: dobavljač se učitava, traženi certifikat je pronađen, privatni ključ se koristi s lokalnim ovlaštenjem, VPN provjerava autentičnost i radnja s resursom uspijeva. Zaustavite se na prvoj fazi koja ne uspije umjesto da kružite kroz zaporke i ponovno instalirate kriptografski sloj.

Bilježite verzije, vlasništvo modula, odabrani javni identifikator i očišćene greške, a PIN-ove i pakete vjerodajnica ostavite izvan tog zapisa.