Një fjalëkalim VPN i saktë nuk mund të zëvendësojë një certifikatë që mungon

Kredencialet janë të sakta, profili importohet pastër dhe lidhja vazhdon të dështojë përpara se vërtetimi të përfundojë. Në Windows mesazhi mund të jetë gabimi 798, për një certifikatë që nuk u gjet për metodën EAP. Në OpenVPN regjistri i klientit tregon një shtrëngim duarsh TLS që nuk e kënaq kurrë serverin. Të dyja përshkruajnë të njëjtin objekt që mungon: një certifikatë klienti që klienti duhej të paraqiste.

Një fjalëkalim provon njohjen e një sekreti; një certifikatë provon zotërimin e një çelësi, dhe njëra nuk zëvendëson tjetrën.

Fjalëkalimi nuk ishte kurrë problemi

Gabimi 798 është një dështim i kërkimit të certifikatës. Klientit iu kërkua një certifikatë që përputhet me metodën e vërtetimit të konfiguruar, ai kërkoi në ruajtësin e tij dhe nuk gjeti asgjë të përdorshme. Kjo mund të nënkuptojë se certifikata mungon, është e pranishme pa çelësin privat, ka skaduar ose është ruajtur atje ku kërkimi nuk arrin. Riprovimi i fjalëkalimit nuk mund të ndryshojë asnjë nga këto kushte, prandaj gabimi kthehet edhe me kredenciale të sakta.

Lexojeni mesazhin përpara se të veproni. Refuzimi i kredencialeve, dështimi i kërkimit të certifikatës dhe dështimi i shtrëngimit të duarve TLS janë tre gjetje të ndryshme, dhe vetëm njëra përfshin fjalëkalimin.

Çfarë duhet të përmbajë ruajtësi i klientit

Dy objekte janë të përfshira. Certifikata e klientit duhet të instalohet për përdoruesin që ekzekuton klientin VPN, bashkë me çelësin e saj privat, dhe rrënja lëshuese duhet të jetë e besuar. Një skedar .cer përmban vetëm certifikatën publike, kështu që vetëm nuk mund të vërtetojë asgjë. Në menaxherin e certifikatave të Windows, identiteti i klientit i përket ruajtësit personal të përdoruesit aktual, dhe rrënja ruajtësit të rrënjëve të besuara.

Instalimi i identitetit në ruajtësin e makinës, ose vetëm në ruajtësin e rrënjëve, nuk plotëson një kërkim të drejtuar nga ruajtësi personal i përdoruesit. Kontrolloni së bashku ruajtësin, shenjën e çelësit privat dhe datat e vlefshmërisë, më pas rinisni klientin që ta lexojë përsëri ruajtësin.

Dy produkte, e njëjta kredencial që mungon

Serverat OpenVPN kërkojnë si parazgjedhje një certifikatë klienti. Shtimi i auth-user-pass te një klient dërgon një emër përdoruesi dhe një fjalëkalim, dhe shtrëngimi i duarve TLS vazhdon të kërkojë një certifikatë, kështu që vetëm një fjalëkalim nuk mund ta përfundojë lidhjen nën verify-client-cert require. Serveri mund të konfigurohet të mos kërkojë asgjë, gjë që e bën fjalëkalimin kredencialin e vetëm të klientit dhe përbën një dobësim real. Një skript shell pas auth-user-pass-verify mund të vërtetojë kredencialet, dhe kërkon që ekzekutimi i skripteve të jetë i aktivizuar, gjë që e bën një dizajn më të rrezikshëm sesa një backend i duhur vërtetimi.

Një profil i bazuar vetëm në fjalëkalim varet gjithashtu nga opsione të shtyra, të cilat nga ana e tyre varen nga aktivizimi i mekanizmit të tërheqjes.

Mos e rregulloni një certifikatë që mungon duke çaktivizuar kontrollet

Tundimi është të lehtësohet verifikimi që mesazhi të zhduket. Kjo heq kontrollin që po bënte punën e vet dhe lë një lidhje që nuk provon më atë që pretendon. Nëse porta ka ndryshuar së fundmi rrënjën e saj, shkarkoni përsëri paketën e klientit në vend që të modifikoni profilin, sepse paketa e vjetër mund të mbajë ende rrënjën e mëparshme. Nëse opsioni i vërtetimit me certifikatë mungon në redaktuesin e profileve, versioni i Windows i instaluar mund të mos e ekspozojë atë metodë; përditësoni sistemin në vend që të modifikoni XML me dorë.

Shënoni cili ruajtës përmbante certifikatën, cili përdorues ekzekutoi klientin dhe nëse çelësi privat ishte i pranishëm. Këto tre shpjegojnë pothuajse çdo rast të këtij dështimi.

Fjalëkalimi ishte në rregull. Kredenciali që metoda me të vërtetë i duhej ishte diku tjetër.