Certificat de client auto-semnat? Serverul VPN îl refuză în continuare
Un certificat de client trebuie să se înlănțuie la CA în care serverul are încredere, iar unul auto-semnat nu va face niciodată asta. Iată ce poate face un CSR și ce trebuie să cereți.
Operatorul trimite o adresă și un nume de utilizator, iar clientul cere un fișier CA, un certificat și o cheie. Generarea acestor trei local pare următorul pas evident. Rezultatul este un certificat în care crede doar propria mașină. Încrederea serverului este ancorată într-o CA pe care nu o controlați, așa că strângerea de mână se termină înainte de a începe.
Încrederea trăiește pe server, nu în profilul dumneavoastră
Autentificarea prin certificat este o comparație. Clientul prezintă un certificat; gateway-ul verifică dacă a fost semnat de una dintre CA din configurația sa.
Profilul dumneavoastră indică fișierul CA pe care clientul trebuie să îl folosească pentru a verifica serverul. Nu poate indica o CA pe care serverul trebuie să o folosească pentru a vă verifica. Acea jumătate a configurației nu este a dumneavoastră.
Un certificat făcut de dumneavoastră eșuează această comparație chiar și când este tehnic perfect. Are o semnătură validă, un subiect și date, dar emitentul este o CA de care gateway-ul nu a auzit niciodată. Eroarea apare în timpul strângerii de mână, după ce serverul a cerut deja un certificat. Nimic din profilul clientului nu poate schimba răspunsul.
De ce un certificat auto-semnat nu îl poate înlocui
Un certificat auto-semnat este semnat cu propria cheie. Semnătura se verifică împotriva aceluiași fișier, ceea ce îl face autoconsistent și inutil ca acreditare pentru gateway-ul altcuiva.
Gateway-ul nu întreabă dacă certificatul este coerent intern. Întreabă dacă un emitent de încredere l-a semnat.
De aceea mesajele de eroare sunt confuze. Clientul poate raporta o eroare de verificare care sună ca o problemă a serverului, în timp ce serverul înregistrează un emitent necunoscut. Ambele descriu aceeași nepotrivire din capete opuse.
Calea CSR păstrează cheia dumneavoastră privată
Puteți face în continuare cea mai mare parte a muncii local. Generați o pereche de chei, construiți o cerere de semnare a certificatului în jurul jumătății publice și trimiteți cererea operatorului. Doar cererea părăsește mașina dumneavoastră. Jumătatea privată rămâne acolo unde ați generat-o.
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"
Operatorul semnează cererea cu CA sa și returnează un certificat. Cheia dumneavoastră privată nu a călătorit niciodată, iar rezultatul se înlănțuie la ancora în care gateway-ul are încredere.
Serviciile gestionate sar adesea peste CSR și emit întregul pachet. Este un schimb rezonabil când același furnizor termină deja tunelul și deține CA. Custodia cheii nu se îmbunătățește păstrând-o, deoarece furnizorul poate bate una nouă în orice moment.
Pachetele se importă, nu se instalează
Pachetele furnizorilor cu nume care sună a securitate sunt adesea profiluri OpenVPN. Conțin configurație și uneori certificate și nu instalează nimic. Importați fișierul într-un client care vorbește protocolul, iar conexiunea este configurată.
Regula de manipulare decurge din conținut. Dacă profilul încorporează o cheie privată, este o acreditare și merită aceeași grijă ca o parolă: fără e-mail, fără depozit, fără folder de descărcări partajat. Când operatorul livrează ca.crt, client.crt și client.key separat, păstrați-le împreună cu permisiuni restrictive și îndreptați profilul spre ele.
Adăugați verificările pe care operatorul le-ar fi putut omite
Un profil generat de router uneori nu are verificarea partenerului. remote-cert-tls server cere ca certificatul partenerului să poarte scopul de autentificare a serverului, astfel încât un certificat de client să nu poată fi redat ca server. Acea singură linie este o schimbare mică cu o justificare clară.
verify-x509-name merge mai departe când operatorul poate indica subiectul sau SAN-ul așteptat. Ambele sunt mici completări la un profil și ambele sunt de apărat. Inspectați ce ați primit înainte de a-l importa.
openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt
Setările de verificare nu sunt o reparație pentru un lanț rupt. Dacă emitentul este greșit, răspunsul este un certificat de la CA corectă, nu un steag care oprește verificarea. Oprirea verificării transformă o eroare de autentificare într-una nedetectată.
Cereți un singur pachet: certificatul autorității în format PEM, un certificat de client semnat de acea autoritate, o cheie pe care ați generat-o sau care a ajuns printr-un canal în care aveți încredere, și numele exact al serverului pe care certificatul trebuie să îl prezinte. Notați data de expirare în același mesaj, pentru că un certificat expirat arată ca o defecțiune de rețea luni mai târziu.