Ispravna VPN lozinka ne može zamijeniti certifikat koji nedostaje

Vjerodajnice su ispravne, profil se čisto uvozi, a veza i dalje pada prije nego što se autentifikacija završi. Na Windowsu poruka može biti greška 798, o certifikatu koji nije pronađen za EAP metodu. Na OpenVPN-u klijentski dnevnik pokazuje TLS rukovanje koje nikada ne zadovolji poslužitelj. Oba opisuju isti objekt koji nedostaje: klijentski certifikat koji je klijent trebao predstaviti.

Lozinka dokazuje znanje tajne; certifikat dokazuje posjedovanje ključa, i jedno ne zamjenjuje drugo.

Lozinka nikada nije bila problem

Greška 798 je neuspjelo traženje certifikata. Od klijenta je zatražen certifikat koji odgovara konfiguriranoj metodi autentifikacije, pretražio je svoje spremište i nije našao ništa upotrebljivo. To može značiti da certifikat nedostaje, da postoji bez privatnog ključa, da je istekao ili da je pohranjen tamo gdje traženje ne doseže. Ponovni pokušaj lozinke ne može promijeniti nijedan od tih uvjeta, zato se greška vraća i s ispravnim vjerodajnicama.

Pročitajte poruku prije nego što postupite. Odbijanje vjerodajnica, neuspjelo traženje certifikata i neuspjelo TLS rukovanje tri su različita nalaza, a samo jedan uključuje lozinku.

Što klijentsko spremište mora sadržavati

Uključena su dva objekta. Klijentski certifikat mora biti instaliran za korisnika koji pokreće VPN klijent, zajedno sa svojim privatnim ključem, a korijen koji ga izdaje mora biti pouzdan. Datoteka .cer sadrži samo javni certifikat, pa sama po sebi ne može ništa autentificirati. U Windows upravitelju certifikatima identitet klijenta pripada osobnom spremištu trenutačnog korisnika, a korijen spremištu pouzdanih korijena.

Instaliranje identiteta u spremište računala, ili samo u spremište korijena, ne zadovoljava traženje usmjereno na korisnikovo osobno spremište. Provjerite spremište, oznaku privatnog ključa i datume valjanosti zajedno, zatim ponovno pokrenite klijent da bi ponovno pročitao spremište.

Dva proizvoda, ista vjerodajnica koja nedostaje

OpenVPN poslužitelji u pravilu zahtijevaju klijentski certifikat. Dodavanje auth-user-pass klijentu šalje korisničko ime i lozinku, a TLS rukovanje i dalje traži certifikat, pa samo lozinka ne može dovršiti vezu pod verify-client-cert require. Poslužitelj se može postaviti da ne zahtijeva ništa, što lozinku čini jedinom klijentskom vjerodajnicom i predstavlja stvarno slabljenje. Shell skripta iza auth-user-pass-verify može validirati vjerodajnice, a zahtijeva omogućeno izvršavanje skripti, što je čini rizičnijim rješenjem od ispravnog pozadinskog sustava autentifikacije.

Profil koji se oslanja samo na lozinku zavisi i od guranih opcija, koje opet zavise od toga da je mehanizam povlačenja omogućen.

Ne popravljajte certifikat koji nedostaje isključivanjem provjera

Kušnja je ublažiti provjeru da poruka nestane. Time se uklanja kontrola koja je radila svoj posao i ostaje veza koja više ne dokazuje ono što tvrdi. Ako je pristupnik nedavno promijenio svoj korijen, ponovno preuzmite klijentski paket umjesto uređivanja profila, jer stari paket može još nositi prethodni korijen. Ako opcija autentifikacije certifikatom nedostaje u uređivaču profila, instalirana Windows verzija možda ne izlaže tu metodu; ažurirajte sustav umjesto ručnog uređivanja XML-a.

Zabilježite koje je spremište držalo certifikat, koji je korisnik pokrenuo klijent i je li privatni ključ bio prisutan. Ta tri objašnjavaju gotovo svaki slučaj ovog neuspjeha.

Lozinka je bila ispravna. Vjerodajnica koja je metodi zapravo trebala bila je negdje drugdje.