Správné heslo VPN nenahradí chybějící certifikát

Přihlašovací údaje jsou správné, profil se naimportuje čistě a připojení stejně selže dřív, než se dokončí autentizace. Ve Windows může být hlášení chyba 798 o certifikátu, který se pro metodu EAP nepodařilo najít. Na OpenVPN klientský protokol ukazuje TLS handshake, který server nikdy neuspokojí. Obě popisují stejný chybějící objekt: klientský certifikát, který měl klient předložit.

Heslo dokazuje znalost tajemství; certifikát dokazuje držení klíče a jedno nenahrazuje druhé.

Heslo nikdy nebylo problém

Chyba 798 je selhání hledání certifikátu. Klient byl požádán o certifikát odpovídající nakonfigurované metodě autentizace, prohledal své úložiště a nenašel nic použitelného. Může to znamenat, že certifikát chybí, je přítomen bez soukromého klíče, vypršel nebo je uložen tam, kam hledání nedosáhne. Opakování hesla nemůže změnit žádnou z těchto podmínek, a proto se chyba vrací i se správnými údaji.

Přečtěte si hlášení, než začnete jednat. Odmítnutí přihlašovacích údajů, selhání hledání certifikátu a selhání TLS handshake jsou tři různá zjištění a jen jedno z nich zahrnuje heslo.

Co musí klientské úložiště obsahovat

Jde o dva objekty. Klientský certifikát musí být nainstalován pro uživatele, který spouští klienta VPN, spolu s jeho soukromým klíčem, a vydávající kořen musí být důvěryhodný. Soubor .cer obsahuje jen veřejný certifikát, takže sám o sobě nemůže nic autentizovat. Ve Správci certifikátů Windows patří identita klienta do osobního úložiště aktuálního uživatele a kořen do úložiště důvěryhodných kořenů.

Instalace identity do úložiště počítače nebo jen do úložiště kořenů nevyhoví hledání zaměřenému na osobní úložiště uživatele. Zkontrolujte úložiště, příznak soukromého klíče a data platnosti společně, potom klienta restartujte, aby úložiště znovu načetl.

Dva produkty, stejný chybějící údaj

Servery OpenVPN standardně vyžadují klientský certifikát. Přidání auth-user-pass ke klientovi odešle uživatelské jméno a heslo a TLS handshake stále žádá certifikát, takže samotné heslo nemůže připojení dokončit pod verify-client-cert require. Server lze nastavit tak, aby nevyžadoval nic, čímž se heslo stane jediným klientským údajem, a to je skutečné oslabení. Shellový skript za auth-user-pass-verify může údaje ověřovat a vyžaduje povolené spouštění skriptů, což z něj dělá riskantnější řešení než řádný autentizační backend.

Profil jen s heslem také závisí na vnucených volbách, které zase závisí na zapnutém mechanismu stahování.

Neopravujte chybějící certifikát vypnutím kontrol

Pokušení je uvolnit ověřování, aby hlášení zmizelo. Tím se odstraní kontrola, která dělala svou práci, a zůstane připojení, které už nedokazuje, co tvrdí. Pokud brána nedávno změnila svůj kořen, stáhněte znovu klientský balíček místo úpravy profilu, protože starý balíček může stále nést předchozí kořen. Pokud v editoru profilů chybí volba autentizace certifikátem, nainstalovaná verze Windows možná tuto metodu nezpřístupňuje; aktualizujte systém, místo abyste ručně upravovali XML.

Zaznamenejte, které úložiště certifikát obsahovalo, který uživatel klienta spustil a zda byl přítomen soukromý klíč. Tyto tři údaje vysvětlují téměř každý případ tohoto selhání.

Heslo bylo v pořádku. Údaj, který metoda skutečně potřebovala, byl jinde.