Pareiza VPN parole neaizstāj trūkstošu sertifikātu

Akreditācijas dati ir pareizi, profils tiek importēts tīri, un savienojums tomēr neizdodas pirms autentifikācijas pabeigšanas. Windows vidē ziņojums var būt 798 kļūda par sertifikātu, kas netika atrasts EAP metodei. OpenVPN gadījumā klienta žurnāls rāda TLS rokasspiedienu, kas nekad neapmierina serveri. Abi apraksta to pašu trūkstošo objektu: klienta sertifikātu, kuru klientam bija jāuzrāda.

Parole pierāda zināšanas par noslēpumu; sertifikāts pierāda atslēgas īpašumtiesības, un viens neaizstāj otru.

Parole nekad nebija problēma

798 kļūda ir sertifikāta meklēšanas neveiksme. Klientam tika pieprasīts sertifikāts, kas atbilst konfigurētajai autentifikācijas metodei, tas pārlūkoja savu krātuvi un neatrada neko izmantojamu. Tas var nozīmēt, ka sertifikāts trūkst, tas ir bez privātās atslēgas, ir beidzies vai glabājas vietā, kur meklēšana neaizsniedzas. Paroles atkārtota ievade nevar mainīt nevienu no šiem nosacījumiem, tāpēc kļūda atgriežas arī ar pareiziem datiem.

Izlasiet ziņojumu pirms rīkošanās. Akreditācijas datu noraidīšana, sertifikāta meklēšanas neveiksme un TLS rokasspiediena neveiksme ir trīs dažādi atklājumi, un tikai viens no tiem attiecas uz paroli.

Kas jāsatur klienta krātuvē

Iesaistīti divi objekti. Klienta sertifikāts jāinstalē lietotājam, kurš palaiž VPN klientu, kopā ar tā privāto atslēgu, un izdevējsaknei jābūt uzticamai. .cer fails satur tikai publisko sertifikātu, tāpēc tas vien pats neko nevar autentificēt. Windows sertifikātu pārvaldniekā klienta identitāte pieder pašreizējā lietotāja personīgajai krātuvei, bet sakne — uzticamo sakņu krātuvei.

Identitātes instalēšana datora krātuvē vai tikai sakņu krātuvē neapmierina meklēšanu, kas vērsta uz lietotāja personīgo krātuvi. Pārbaudiet krātuvi, privātās atslēgas karodziņu un derīguma datumus kopā, pēc tam restartējiet klientu, lai tas krātuvi nolasītu no jauna.

Divi produkti, viens un tas pats trūkstošais akreditācijas datums

OpenVPN serveri pēc noklusējuma pieprasa klienta sertifikātu. Pievienojot auth-user-pass klientam, tiek nosūtīts lietotājvārds un parole, un TLS rokasspiediens joprojām pieprasa sertifikātu, tāpēc tikai parole nevar pabeigt savienojumu saskaņā ar verify-client-cert require. Serveri var iestatīt neprasīt neko, un tas paroli padara par vienīgajiem klienta datiem un ir reāls stipruma samazinājums. Shell skripts aiz auth-user-pass-verify var validēt datus, un tam nepieciešama iespējota skriptu izpilde, kas to padara par riskantāku risinājumu nekā pienācīgs autentifikācijas backend.

Profils, kas balstīts tikai uz paroli, arī ir atkarīgs no piespiestajām opcijām, kuras savukārt ir atkarīgas no vilkšanas mehānisma iespējošanas.

Nelabojiet trūkstošu sertifikātu, izslēdzot pārbaudes

Kārdinājums ir mīkstināt verifikāciju, lai ziņojums pazustu. Tas noņem kontroli, kas veica savu darbu, un atstāj savienojumu, kas vairs nepierāda to, ko apgalvo. Ja vārteja nesen nomainīja savu sakni, lejupielādējiet klienta pakotni no jauna, nevis rediģējiet profilu, jo vecajā pakotnē joprojām var būt iepriekšējā sakne. Ja profila redaktorā trūkst sertifikāta autentifikācijas opcijas, iespējams, instalētā Windows versija šo metodi neparāda; atjauniniet sistēmu, nevis rediģējiet XML ar roku.

Pierakstiet, kurā krātuvē bija sertifikāts, kurš lietotājs palaida klientu un vai privātā atslēga bija klāt. Šie trīs izskaidro gandrīz katru šīs neveiksmes gadījumu.

Parole bija laba. Datums, kas metodei patiešām bija vajadzīgs, atradās citur.