Poverilnice so pravilne, profil se uvozi čisto in povezava kljub temu spodleti, preden se preverjanje pristnosti konča. V Windowsu je sporočilo lahko napaka 798, o potrdilu, ki ga za metodo EAP ni bilo mogoče najti. Na OpenVPN dnevnik odjemalca kaže rokovanje TLS, ki strežniku nikoli ne ustreže. Oba opisujeta isti manjkajoči predmet: odjemalsko potrdilo, ki bi ga odjemalec moral predložiti.

Geslo dokazuje poznavanje skrivnosti; potrdilo dokazuje posedovanje ključa, in eno ne nadomesti drugega.

Geslo nikoli ni bilo težava

Napaka 798 je neuspešno iskanje potrdila. Odjemalec je bil pozvan, naj poišče potrdilo, ki ustreza nastavljeni metodi preverjanja pristnosti, pregledal je svojo shrambo in ni našel ničesar uporabnega. To lahko pomeni, da potrdila ni, da je prisotno brez zasebnega ključa, da je poteklo ali da je shranjeno tam, kamor iskanje ne seže. Ponovni vnos gesla ne more spremeniti nobenega od teh pogojev, zato se napaka vrne tudi s pravilnimi podatki.

Preberite sporočilo, preden ukrepate. Zavrnitev poverilnic, neuspešno iskanje potrdila in neuspešno rokovanje TLS so tri različne ugotovitve, le ena od njih pa vključuje geslo.

Kaj mora vsebovati shramba odjemalca

Vpletena sta dva predmeta. Odjemalsko potrdilo mora biti nameščeno za uporabnika, ki izvaja odjemalca VPN, skupaj z njegovim zasebnim ključem, izdajateljski koren pa mora biti zaupanja vreden. Datoteka .cer vsebuje le javno potrdilo, zato sama ne more overiti ničesar. V upravitelju potrdil Windows identiteta odjemalca spada v osebno shrambo trenutnega uporabnika, koren pa v shrambo zaupanja vrednih korenov.

Namestitev identitete v shrambo računalnika ali le v shrambo korenov ne zadosti iskanju, usmerjenemu v uporabnikovo osebno shrambo. Preverite shrambo, oznako zasebnega ključa in datume veljavnosti skupaj, nato znova zaženite odjemalca, da shrambo znova prebere.

Dva izdelka, ista manjkajoča poverilnica

Strežniki OpenVPN privzeto zahtevajo odjemalsko potrdilo. Dodajanje auth-user-pass odjemalcu pošlje uporabniško ime in geslo, rokovanje TLS pa še vedno zahteva potrdilo, zato samo geslo ne more dokončati povezave pod verify-client-cert require. Strežnik je mogoče nastaviti, da ne zahteva ničesar, kar geslo naredi edino odjemalsko poverilnico in je resnično oslabitev. Shell skript za auth-user-pass-verify lahko preverja poverilnice, in zahteva omogočeno izvajanje skriptov, kar ga naredi bolj tvegano zasnovo kot ustrezna avtentikacijska zaledna storitev.

Profil samo z geslom je odvisen tudi od potisnjenih možnosti, te pa od tega, da je mehanizem vlečenja omogočen.

Manjkajočega potrdila ne popravljajte z izklopom preverjanj

Skušnjava je omiliti preverjanje, da sporočilo izgine. To odstrani nadzor, ki je opravljal svoje delo, in pusti povezavo, ki ne dokazuje več tega, kar trdi. Če je prehod nedavno zamenjal svoj koren, znova prenesite odjemalski paket, namesto da bi urejali profil, ker lahko stari paket še vedno nosi prejšnji koren. Če v urejevalniku profilov ni možnosti preverjanja pristnosti s potrdilom, nameščena različica Windowsa te metode morda ne izpostavlja; posodobite sistem, namesto da bi ročno urejali XML.

Zabeležite, katera shramba je vsebovala potrdilo, kateri uporabnik je zagnal odjemalca in ali je bil zasebni ključ prisoten. Ti trije pojasnijo skoraj vsak primer te napake.

Geslo je bilo v redu. Poverilnica, ki jo je metoda zares potrebovala, je bila drugje.

Sorodni članki