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

Umetnete token, provajderov sopstveni 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 sertifikata i ključa koje očekuje po difoltu.

Dve odvojene vrednosti moraju biti ispravne pre nego što se taj povratak zaustavi: provajder koji izlaže token i identitet sertifikata unutar njega. One se zadaju različitim opcijama i lako ih je zameniti.

Klijent traži datoteku jer profil tako nalaže

Difolt profil očekuje datoteku sertifikata i datoteku privatnog ključa, ili jedan PKCS#12 paket. Kad ti unosi nedostaju, klijent nema šta da učita i ponaša se skoro kao kod datoteke koja nedostaje, zbog čega se simptom čita kao pokvarena putanja, a ne kao mehanizam koji nedostaje. Putanja PKCS#11 zamenjuje te unose umesto da ih dopunjuje, pa će profil koji i dalje navodi datoteku ključa nastaviti da koristi tu datoteku. Namerno uklonite datotečne unose i pustite tokenu da obezbedi obe polovine.

Opcija provajdera imenuje biblioteku međusloja, a ne uređaj i ne sertifikat. Da li pakovani klijent može da učita 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šti vodič ne može da vam kaže kakav raspored ima vaš paket.

Serijalizovani identitet je druga vrednost

Identitet sertifikata je dugačak serijalizovani niz koji proizvodi proces otkrivanja i nije putanja biblioteke, PIN tokena ni naziv VPN naloga. Često sadrži znakove koje treba staviti pod navodnike, a vrednost bez navodnika može biti skraćena ili pogrešno pročitana bez jasne greške. Upotrebite klijentovu sopstvenu opciju otkrivanje identiteta da izlistate šta token izlaže, zatim tačno kopirajte željeni unos. Biranje prvog objekta na listi je način na koji uređaj na kraju predstavi pogrešan sertifikat.

Rezultat otkrivanja odgovara i na prethodno pitanje: da li je token uopšte vidljiv kroz tog provajdera. Ako ništa ne izlistava, problem je iznad VPN klijenta i pripada međusloju.

Proces koji se povezuje mora da dođe do tokena

Operacija sa tokenom koja uspeva u vašoj radnoj sesiji ne dokazuje ništa o sistemskoj usluzi. Usluga može da radi kao drugi korisnik, u drugom montažnom imenskom prostoru, sa putanjom modula koja izostavlja biblioteku provajdera ili bez dozvole 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 provere autentičnosti, a oboje postoji kako bi operater mogao da izabere tok rada umesto da ga izmisli. Ne pretvarajte zahtev bez nadzora u PIN u čistom tekstu unutar zajedničkog profila, jer to menja zaštitu tokena za udobnost. Tamo gde token zabranjuje izvoz ključa, potpisivanje se dešava na uređaju i PIN je jedina lokalna tajna. Tretirajte ga s pažnjom koju to podrazumeva.

Šta token ne zamenjuje

Token proverava autentičnost klijenta u okviru primenjene politike i ne zamenjuje klijentove provere na serveru. Uspešno izabran sertifikat nije dozvola za prihvatanje neočekivanog sertifikata pristupnika, a te dve provere štite suprotne smerove.

Upis i dalje mora da se dogodi kod izdavaoca, a pristupnik i dalje mora da ovlasti identitet.

Za prihvatanje razdvojite faze: provajder se učitava, traženi sertifikat je pronađen, privatni ključ se koristi s lokalnim ovlašćenjem, VPN proverava autentičnost i operacija sa resursom uspeva. Zaustavite se na prvoj fazi koja ne uspe umesto da kružite kroz lozinke i ponovo instalirate kriptografski sloj.

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