Selvsigneret klientcertifikat? VPN-serveren afviser det stadig
Et klientcertifikat skal kæde til den CA, serveren stoler på, og et selvsigneret gør det aldrig. Her er, hvad en CSR kan gøre, og hvad du skal bede om.
Operatøren sender en adresse og et brugernavn, og klienten beder om en CA-fil, et certifikat og en nøgle. At generere de tre lokalt føles som det oplagte næste skridt. Det giver et certifikat, som kun din egen maskine tror på. Serverens tillid er forankret i en CA, du ikke kontrollerer, så håndtrykket slutter, før det begynder.
Tillid bor på serveren, ikke i din profil
Certifikatgodkendelse er en sammenligning. Klienten fremviser et certifikat; gatewayen kontrollerer, om det er signeret af en af de CA'er, der står i dens konfiguration.
Din profil angiver den CA-fil, klienten skal bruge til at verificere serveren. Den kan ikke angive en CA, som serveren skal bruge til at verificere dig. Den halvdel af konfigurationen er ikke din.
Et hjemmelavet certifikat fejler denne sammenligning, selv når det er teknisk perfekt. Det har en gyldig signatur, et subjekt og datoer, men udstederen er en CA, som gatewayen aldrig har hørt om. Fejlen vises under håndtrykket, efter at serveren allerede har bedt om et certifikat. Intet i klientprofilen kan ændre svaret.
Hvorfor et selvsigneret certifikat ikke kan erstatte det
Et selvsigneret certifikat er signeret med sin egen nøgle. Signaturen verificeres mod den samme fil, hvilket gør det selvkonsistent og ubrugeligt som legitimation for en andens gateway.
Gatewayen spørger ikke, om certifikatet er internt konsistent. Den spørger, om en betroet udsteder har signeret det.
Derfor er fejlmeddelelserne forvirrende. Klienten kan rapportere en verifikationsfejl, der lyder som et serverproblem, mens serveren logger en ukendt udsteder. Begge beskriver den samme uoverensstemmelse fra hver sin ende.
CSR-vejen bevarer din private nøgle
Du kan stadig gøre det meste af arbejdet lokalt. Generer et nøglepar, byg en anmodning om certifikatsignering omkring den offentlige halvdel, og send anmodningen til operatøren. Kun anmodningen forlader din maskine. Den private halvdel bliver, hvor du genererede den.
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"
Operatøren signerer anmodningen med deres CA og returnerer et certifikat. Din private nøgle har aldrig været afsted, og resultatet kæder til det anker, gatewayen stoler på.
Administrerede tjenester springer ofte CSR'en over og udsteder hele bundtet. Det er en rimelig handel, når den samme udbyder allerede afslutter tunnelen og har CA'en. Nøglens opbevaring bliver ikke bedre af at beholde den, fordi udbyderen til enhver tid kan lave en ny.
Bundter importeres, de installeres ikke
Leverandørbundter med sikkerhedsklingende navne er ofte OpenVPN-profiler. De indeholder konfiguration og nogle gange certifikater, og de installerer intet. Importér filen i en klient, der taler protokollen, og forbindelsen er konfigureret.
Håndteringsreglen følger af indholdet. Hvis profilen indlejrer en privat nøgle, er det en legitimationsoplysning og fortjener samme omhu som en adgangskode: ingen e-mail, ingen kodelager, ingen delt downloadmappe. Når operatøren leverer ca.crt, client.crt og client.key separat, skal du opbevare dem sammen med restriktive tilladelser og pege profilen på dem.
Tilføj de kontroller, operatøren måske har sprunget over
En routergenereret profil mangler nogle gange peer-verifikation. remote-cert-tls server kræver, at peer-certifikatet bærer formålet servergodkendelse, så et klientcertifikat ikke kan genafspilles som server. Den ene linje er en lille ændring med en klar begrundelse.
verify-x509-name går videre, når operatøren kan angive det forventede subjekt eller SAN. Begge er små tilføjelser til en profil, og begge er forsvarlige. Undersøg, hvad du har modtaget, før du importerer det.
openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt
Verifikationsindstillinger er ikke en reparation af en brudt kæde. Hvis udstederen er forkert, er svaret et certifikat fra den rigtige CA, ikke et flag, der slår kontrollen fra. At slå verifikationen fra gør en godkendelsesfejl til en uopdaget fejl.
Bed om ét bundt: myndighedens certifikat som PEM, et klientcertifikat, som myndigheden har signeret, en nøgle, du selv har genereret, eller som er kommet gennem en kanal, du stoler på, og det præcise servernavn, som certifikatet skal præsentere. Notér udløbsdatoen i samme besked, fordi et udløbet certifikat ser ud som en netværksfejl måneder senere.