Kāpēc OpenVPN joprojām pieprasa privātās atslēgas failu, kad ir tokens

Jūs ievietojat tokenu, pakalpojumu sniedzēja paša rīks to redz, bet VPN klients joprojām pieprasa privātās atslēgas failu. Šis pieprasījums nav pierādījums, ka tokens netiek atbalstīts. Parasti tas nozīmē, ka profils nekad nav teicis klientam lietot tokenu, tāpēc tas atgriezās pie sertifikāta un atslēgas ievadēm, ko gaida pēc noklusējuma.

Divām atsevišķām vērtībām jābūt pareizām, lai šī atkāpšanās apstātos: pakalpojumu sniedzējam, kas atklāj tokenu, un sertifikāta identitātei tajā. Tās tiek nodotas ar dažādām opcijām, un tās ir viegli sajaukt.

Klients pieprasa failu, jo profils tā nosaka

Noklusējuma profils gaida sertifikāta failu un privātās atslēgas failu vai vienu PKCS#12 pakotni. Ja šo ievadu nav, klientam nav ko ielādēt un tas uzvedas gandrīz kā trūkstoša faila gadījumā, tāpēc simptoms tiek lasīts kā salauzts ceļš, nevis trūkstošs mehānisms. PKCS#11 ceļš šīs ievades aizstāj, nevis papildina, tāpēc profils, kas joprojām norāda atslēgas failu, turpinās izmantot failu. Apzināti noņemiet failu ievades un ļaujiet tokenam nodrošināt abas puses.

Pakalpojumu sniedzēja opcija nosauc starpprogrammatūras bibliotēku, nevis ierīci un nevis sertifikātu. Tas, vai iepakots klients var ielādēt šo bibliotēku, ir atkarīgs no tā, kā tas tika būvēts, tostarp no neobligātā p11-kit atbalsta, ko dažas būves ieslēdz, bet citas izlaiž. Vispārīga apmācība nevar pateikt, kāds izkārtojums ir jūsu pakotnei.

Serializētā identitāte ir cita vērtība

Sertifikāta identitāte ir gara serializēta virkne, ko rada atklāšanas process, un tā nav bibliotēkas ceļš, ne tokena PIN, ne VPN konta nosaukums. Tajā bieži ir rakstzīmes, kurām nepieciešamas pēdiņas, un vērtība bez pēdiņām var tikt apgriezta vai nepareizi nolasīta bez skaidras kļūdas. Izmantojiet paša klienta opciju identitātes atklāšana, lai uzskaitītu, ko atklāj tokens, pēc tam precīzi nokopējiet vajadzīgo ierakstu. Pirmā saraksta objekta izvēle ir veids, kā ierīce galu galā uzrāda nepareizo sertifikātu.

Atklāšanas izvade atbild arī uz iepriekšējo jautājumu: vai tokens vispār ir redzams caur šo pakalpojumu sniedzēju. Ja tā neko neuzskaita, problēma ir augstāk par VPN klientu un pieder starpprogrammatūrai.

Procesam, kas izveido savienojumu, jāsasniedz tokens

Tokena darbība, kas darbojas jūsu darbvirsmas sesijā, neko nepierāda par sistēmas pakalpojumu. Pakalpojums var darboties kā cits lietotājs, citā montāžas nosaukumtelpā, ar moduļu ceļu, kas izlaiž pakalpojumu sniedzēja bibliotēku, vai bez atļaujas atvērt ierīces mezglu. Nosakiet, kurš process faktiski tur savienojumu, un pārbaudiet no šī konteksta.

PIN apstrāde ir pelnījusi atsevišķu lēmumu. Atsauces ieviešana piedāvā PIN kešatmiņu un aizsargātu autentifikācijas ceļu, un abi pastāv tāpēc, lai operators varētu izvēlēties darbplūsmu, nevis to izgudrot. Nepārvērsiet uzraudzības neprasošu prasību par vienkārša teksta PIN koplietotā profilā, jo tas apmaina tokena aizsardzību pret ērtībām. Kur tokens aizliedz atslēgas eksportu, parakstīšana notiek ierīcē, un PIN ir vienīgais vietējais noslēpums. Izturieties pret to ar pienācīgu rūpību.

Ko tokens neaizstāj

Tokens autentificē klientu saskaņā ar izvietoto politiku, un tas neaizstāj klienta pārbaudes serverī. Veiksmīgi izvēlēts sertifikāts nav atļauja pieņemt negaidītu vārtejas sertifikātu, un abas pārbaudes aizsargā pretējus virzienus.

Reģistrācijai joprojām jānotiek pie izdevēja, un vārtejai joprojām jāautorizē identitāte.

Pieņemšanai atdaliet posmus: pakalpojumu sniedzējs ielādējas, tiek atrasts paredzētais sertifikāts, privātā atslēga tiek izmantota ar vietēju autorizāciju, VPN autentificējas, un resursa darbība izdodas. Apstājieties pirmajā posmā, kas neizdodas, nevis pārlūkojiet paroles un pārinstalējiet kriptogrāfijas steku.

Reģistrējiet versijas, moduļu īpašumtiesības, izvēlēto publisko identifikatoru un attīrītas kļūdas, un atstājiet PIN un akreditācijas datu pakotnes ārpus šī ieraksta.