Selvsigneret kontra offentlig CA til en VPN: hvad ændrer sig egentlig

Du når certifikatsiden i en VPN-opsætning, ser en gratis selvsigneret mulighed ved siden af en betalt offentlig CA, og spørgsmålet lyder som et sikkerhedsvalg. Det er i virkeligheden et publikumsvalg. Begge muligheder krypterer tunnelen med de samme primitive elementer, og begge bliver værdiløse, hvis den private nøgle lækker. Det, der adskiller dem, er, hvem der fremsætter påstanden om serverens identitet, og hvem der er i stand til at kontrollere den påstand.

Et certifikat udfører to job, der bliver forvekslet

Et certifikat binder en offentlig nøgle til et navn, og nøglen udfører krypterings- og signeringsarbejdet. Signaturen på certifikatet er en særskilt erklæring: en eller anden myndighed har kontrolleret, at navnet tilhører denne nøgleindehaver. Et selvsigneret certifikat fremsætter den erklæring om sig selv, hvilket slet ikke er nogen tredjepartspåstand.

Offentlige websteder har brug for tredjepartsversionen, fordi besøgende ankommer uden forudgående forhold og stoler på browserens tillidslager. En VPN-klient er ikke en fremmed. Du giver den CA-certifikatet eller fastgør servercertifikatet inde i den profil, den installerer, så verifikationen kører mod præcis den myndighed, du valgte. Ingen kommerciel CA behøver at være involveret, for at den kontrol betyder noget.

Styrken i den resulterende session kommer fra nøglestørrelsen og ciphersuiten, ikke fra underskriveren. Derfor er det simpelthen forkert at kalde et selvsigneret certifikat "mindre krypteret"; det er mindre bredt garanteret, hvilket er en anden egenskab.

Hvor en offentlig CA tjener sit gebyr

Det klareste tilfælde er administrationssiden. Hvis kolleger, entreprenører eller enhver anden uden en forberedt profil skal åbne VPN-serverens webgrænseflade uden en browseradvarsel, fjerner et offentligt betroet certifikat den friktion. Browseren stoler allerede på underskriveren, så der er intet at importere og intet at forklare.

Den bekvemmelighed har omkostninger, der er værd at nævne, før du køber. Fornyelse skal automatiseres, ellers bryder webstedet sammen efter en tidsplan, offentlige certifikater afslører værtsnavnet i gennemsigtighedslogge for certifikater, og grænser for udstedelseshastighed straffer et script, der prøver for ivrigt igen. Intet af dette er grunde til at undgå en offentlig CA, men det er driftsarbejde, som en privat CA flytter et andet sted hen.

Det, et offentligt certifikat ikke gør, er at godkende dine brugere. Klientidentitet er en særskilt beslutning, truffet med klientcertifikater, adgangskoder eller en anden faktor, og den CA, der signerer serveren, siger intet om, hvem der må forbinde til den.

Hvor en privat CA passer til en VPN

Til en privat VPN med et kendt sæt klienter er det den konventionelle løsning at køre din egen CA. Du opretter CA'en én gang, signerer servercertifikatet med et navn, klienterne vil bruge, og distribuerer CA-certifikatet i hver profil. Hver klient verificerer derefter serveren mod din myndighed, og ingen udenforstående får kendskab til værtsnavnet.

Omkostningerne er reelle, men afgrænsede. Browsere advarer, når nogen åbner administrationssiden direkte, fordi browseren ikke har nogen grund til at stole på din CA. Profildistribution bliver en del af onboarding, og rotation af CA'en betyder, at hver klient skal røres. Det er acceptable priser for en tjeneste med ti eller halvtreds kendte brugere og smertefulde for et offentligt endpoint med tusindvis.

Én betingelse gør hele arrangementet gyldigt: verifikationen skal finde sted. En klient, der er konfigureret til at ignorere certifikatfejl, accepterer enhver server, der præsenterer et hvilket som helst certifikat, så identitetsgarantien forsvinder, mens krypteringen består. Den indstilling er den egentlige svaghed i de fleste historier om, at "selvsigneret er usikkert".

CA'ens private nøgle afgør, hvad du kan gøre senere

Overraskelsen kommer normalt måneder senere, når du vil tilføje en enhed. Udstedelse af et klientcertifikat kræver CA'ens private nøgle, og det gør produktionen af en tilbagekaldelsesliste også. Hvis du har overtaget en server, der har certifikat- og nøglefilerne, men ikke CA-nøglen, kan du ikke signere noget nyt. Dine muligheder er at genopbygge PKI'en og give hver klient et nyt CA-certifikat eller skifte til adgangskodegodkendelse, som er en anden sikkerhedsmodel og ikke gendanner det tabte.

To mindre fælder ligger i samme område. easy-rsa-scripts antager, at du står i den mappe, der indeholder dem, så en fejl om manglende fil betyder normalt den forkerte placering og ikke en beskadiget installation. Og et design med kun certifikater er helt legitimt: du kan kræve klientcertifikater uden en forudelt nøgle, forudsat at hver klient har et, og serveren verificerer kæden.

Udsted ét certifikat for hver enhed i stedet for ét delt klientcertifikat til hele teamet. En mistet bærbar computer koster dig så én tilbagekaldelse i stedet for en genudstedelse til alle.

Kontroller, hvad du har overtaget

Før du planlægger nogen ændring, skal du læse det certifikat, du allerede har:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Hvis udstederen er lig med subjektet, er certifikatet selvsigneret, hvilket er et designvalg og ikke en fejl. Datoerne fortæller dig, hvornår fornyelse bliver nogens problem, og en vellykket verifikation mod den CA, du agter at udrulle, bekræfter, at kæden virker, før en eneste klient prøver den.

Vælg derefter efter publikum og distribution: offentlig CA, når ukendte browsere skal stole på administrationssiden, privat CA, når hver klient modtager en profil, du kontrollerer. Intet af svarene er mere krypteret end det andet.