Certifikatë klienti e vetë-nënshkruar? Serveri VPN ende e refuzon

Operatori dërgon një adresë dhe një emër përdoruesi, dhe klienti kërkon një skedar CA, një certifikatë dhe një çelës. Generimi i këtyre të treve lokalisht duket hapi tjetër i dukshëm. Rezultati është një certifikatë në të cilën beson vetëm makina juaj. Besimi i serverit është i ankoruar në një CA që ju nuk e kontrolloni, prandaj shtrëngimi i duarve mbaron para se të fillojë.

Besimi jeton në server, jo në profilin tuaj

Vërtetimi me certifikatë është një krahasim. Klienti paraqet një certifikatë; porta kontrollon nëse është nënshkruar nga një nga CA-të në konfigurimin e saj.

Profili juaj emërton skedarin CA që klienti duhet të përdorë për të verifikuar serverin. Ai nuk mund të emërtojë një CA që serveri duhet të përdorë për t'ju verifikuar ju. Ajo gjysmë e konfigurimit nuk është e jotja.

Një certifikatë e bërë vetë dështon në këtë krahasim edhe kur është teknikisht perfekte. Ka një nënshkrim të vlefshëm, një subjekt dhe data, por lëshuesi është një CA për të cilën porta nuk ka dëgjuar kurrë. Gabimi shfaqet gjatë shtrëngimit të duarve, pasi serveri ka kërkuar tashmë një certifikatë. Asgjë në profilin e klientit nuk mund ta ndryshojë përgjigjen.

Pse një certifikatë e vetë-nënshkruar nuk mund ta zëvendësojë

Një certifikatë e vetë-nënshkruar nënshkruhet me çelësin e saj. Nënshkrimi verifikohet kundrejt të njëjtit skedar, gjë që e bën atë vetëkonsistente dhe të pavlefshme si kredencial për portën e dikujt tjetër.

Porta nuk pyet nëse certifikata është e brendshme konsistente. Pyet nëse një lëshues i besuar e ka nënshkruar.

Kjo është arsyeja pse mesazhet e gabimit janë konfuze. Klienti mund të raportojë një dështim verifikimi që tingëllon si problem i serverit, ndërsa serveri regjistron një lëshues të panjohur. Të dy përshkruajnë të njëjtën mospërputhje nga skaje të kundërta.

Rruga e CSR ruan çelësin tuaj privat

Ju ende mund të bëni pjesën më të madhe të punës lokalisht. Gjeneroni një palë çelësash, ndërtoni një kërkesë për nënshkrim certifikate rreth gjysmës publike dhe dërgojeni atë kërkesë te operatori. Vetëm kërkesa largohet nga makina juaj. Gjysma private mbetet atje ku e gjeneruat.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Operatori nënshkruan kërkesën me CA-në e tij dhe kthen një certifikatë. Çelësi juaj privat nuk udhëtoi kurrë, dhe rezultati zinxhirohet te ankori që porta i beson.

Shërbimet e menaxhuara shpesh e anashkalojnë CSR-në dhe lëshojnë të gjithë paketën. Ky është një shkëmbim i arsyeshëm kur i njëjti ofrues e përfundon tunelin dhe mban CA-në. Ruajtja e çelësit nuk përmirësohet duke e mbajtur, sepse ofruesi mund të krijojë një të ri në çdo moment.

Paketat importohen, nuk instalohen

Paketat e furnitorëve me emra që tingëllojnë sigurie janë shpesh profile OpenVPN. Përmbajnë konfigurim dhe ndonjëherë certifikata, dhe nuk instalojnë asgjë. Importoni skedarin në një klient që flet protokollin, dhe lidhja konfigurohet.

Rregulli i trajtimit rrjedh nga përmbajtja. Nëse profili përfshin një çelës privat, është kredencial dhe meriton të njëjtin kujdes si një fjalëkalim: pa email, pa depo, pa dosje shkarkimesh të përbashkët. Kur operatori jep ca.crt, client.crt dhe client.key veçmas, ruajini së bashku me leje kufizuese dhe drejtojeni profilin drejt tyre.

Shtoni kontrollet që operatori mund t'i ketë anashkaluar

Një profil i gjeneruar nga ruteri ndonjëherë nuk ka verifikim të palës tjetër. remote-cert-tls server kërkon që certifikata e palës tjetër të mbajë qëllimin e vërtetimit të serverit, kështu që një certifikatë klienti nuk mund të riprodhohet si server. Ajo rresht i vetëm është një ndryshim i vogël me justifikim të qartë.

verify-x509-name shkon më tej kur operatori mund të emërtojë subjektin ose SAN-in e pritur. Të dyja janë shtesa të vogla në një profil, dhe të dyja janë të mbrojtishme. Inspektoni atë që keni marrë përpara se ta importoni.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Cilësimet e verifikimit nuk janë riparim i një zinxhiri të thyer. Nëse lëshuesi është i gabuar, përgjigjja është një certifikatë nga CA e saktë, jo një flamur që fik kontrollin. Fikja e verifikimit e kthen një dështim vërtetimi në një të pazbuluar.

Kërkoni një paketë të vetme: certifikatën e autoritetit si PEM, një certifikatë klienti të nënshkruar nga ai autoritet, një çelës që ju e keni gjeneruar ose që ka ardhur përmes një kanali që ju besoni, dhe emrin e saktë të serverit që certifikata duhet të paraqesë. Shënoni datën e skadimit në të njëjtin mesazh, sepse një certifikatë e skaduar duket si defekt rrjeti muaj më vonë.