Ispravna VPN lozinka ne može zamijeniti sertifikat 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 sertifikatu koji nije pronađen za EAP metodu. Na OpenVPN-u klijentski dnevnik pokazuje TLS rukovanje koje nikada ne zadovolji server. Oba opisuju isti objekt koji nedostaje: klijentski sertifikat koji je klijent trebao predstaviti.

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

Lozinka nikada nije bila problem

Greška 798 je neuspjelo traženje sertifikata. Od klijenta je zatražen sertifikat koji odgovara konfiguriranoj metodi autentifikacije, pretražio je svoje spremište i nije našao ništa upotrebljivo. To može značiti da sertifikat 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 uslova, zato se greška vraća i sa ispravnim vjerodajnicama.

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

Šta klijentsko spremište mora sadržavati

Uključena su dva objekta. Klijentski sertifikat 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 sertifikat, pa sama po sebi ne može ništa autentificirati. U Windows upravitelju sertifikatima identitet klijenta pripada ličnom spremištu trenutnog korisnika, a korijen spremištu pouzdanih korijena.

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

Dva proizvoda, ista vjerodajnica koja nedostaje

OpenVPN serveri po pravilu zahtijevaju klijentski sertifikat. Dodavanje auth-user-pass klijentu šalje korisničko ime i lozinku, a TLS rukovanje i dalje traži sertifikat, pa samo lozinka ne može dovršiti vezu pod verify-client-cert require. Server 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 sistema 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 sertifikat 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, ponovo preuzmite klijentski paket umjesto uređivanja profila, jer stari paket može još nositi prethodni korijen. Ako opcija autentifikacije sertifikatom nedostaje u uređivaču profila, instalirana Windows verzija možda ne izlaže tu metodu; ažurirajte sistem umjesto ručnog uređivanja XML-a.

Zabilježite koje je spremište držalo sertifikat, koji je korisnik pokrenuo klijent i da li je 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.