Selvsignert eller offentlig CA for en VPN: hva som faktisk endres

Du kommer til sertifikatsiden i et VPN-oppsett, ser et gratis selvsignert alternativ ved siden av en betalt offentlig CA, og spørsmålet høres ut som et sikkerhetsvalg. Det er egentlig et publikumsvalg. Begge alternativene krypterer tunnelen med de samme primitive byggeklossene, og begge blir verdiløse hvis den private nøkkelen lekker. Det som skiller dem, er hvem som fremsetter påstanden om serverens identitet, og hvem som er i stand til å kontrollere den påstanden.

Et sertifikat gjør to jobber som blir forvekslet

Et sertifikat binder en offentlig nøkkel til et navn, og nøkkelen gjør krypterings- og signeringsarbeidet. Signaturen på sertifikatet er en egen erklæring: en eller annen myndighet har kontrollert at navnet tilhører denne nøkkelinnehaveren. Et selvsignert sertifikat fremsetter den erklæringen om seg selv, noe som slett ikke er noen tredjepartspåstand.

Offentlige nettsteder trenger tredjepartsversjonen, fordi besøkende kommer uten noen forhåndsrelasjon og er avhengige av nettleserens tillitslager. En VPN-klient er ikke en fremmed. Du gir den CA-sertifikatet, eller fester serversertifikatet, inne i profilen den installerer, slik at verifiseringen kjøres mot nøyaktig den myndigheten du valgte. Ingen kommersiell CA trenger å være involvert for at den kontrollen skal bety noe.

Styrken i den resulterende økten kommer fra nøkkelstørrelsen og chifferpakken, ikke fra signataren. Derfor er det rett og slett feil å kalle et selvsignert sertifikat "mindre kryptert"; det er mindre bredt garantert, noe som er en annen egenskap.

Hvor en offentlig CA tjener inn gebyret sitt

Det klareste tilfellet er administrasjonssiden. Hvis kolleger, entreprenører eller noen andre uten en forberedt profil må åpne nettgrensesnittet til VPN-serveren uten en nettleseradvarsel, fjerner et offentlig betrodd sertifikat den friksjonen. Nettleseren stoler allerede på signataren, så det er ingenting å importere og ingenting å forklare.

Den bekvemmeligheten har kostnader det er verdt å nevne før du kjøper. Fornyelse må automatiseres, ellers bryter nettstedet sammen etter en plan, offentlige sertifikater eksponerer vertsnavnet i gjennomsiktighetslogger for sertifikater, og grenser for utstedelseshastighet straffer et skript som prøver for ivrig på nytt. Ingen av disse er grunner til å unngå en offentlig CA, men det er driftsarbeid som en privat CA flytter et annet sted.

Det et offentlig sertifikat ikke gjør, er å autentisere brukerne dine. Klientidentitet er en egen beslutning, tatt med klient sertifikater, passord eller en andre faktor, og CA-en som signerer serveren sier ingenting om hvem som har lov til å koble til den.

Hvor en privat CA passer til en VPN

For en privat VPN med et kjent sett klienter er det det vanlige valget å drive sin egen CA. Du oppretter CA-en én gang, signerer serversertifikatet med et navn klientene vil bruke, og distribuerer CA-sertifikatet i hver profil. Hver klient verifiserer da serveren mot din myndighet, og ingen utenforstående får kjennskap til vertsnavnet.

Kostnadene er reelle, men avgrensede. Nettlesere vil advare når noen åpner administrasjonssiden direkte, fordi nettleseren ikke har noen grunn til å stole på CA-en din. Profildistribusjon blir en del av onboarding, og å rotere CA-en betyr å berøre hver klient. Det er akseptable priser for en tjeneste med ti eller femti kjente brukere og smertefulle for et offentlig endepunkt med tusener.

Én betingelse gjør hele ordningen gyldig: verifiseringen må skje. En klient som er konfigurert til å ignorere sertifikatfeil, godtar enhver server som presenterer et hvilket som helst sertifikat, slik at identitetsgarantien forsvinner mens krypteringen består. Den innstillingen er den egentlige svakheten i de fleste historiene om at "selvsignert er usikkert".

Den private nøkkelen til CA-en avgjør hva du kan gjøre senere

Overraskelsen kommer vanligvis måneder senere, når du vil legge til en enhet. Å utstede et klientsertifikat krever CA-ens private nøkkel, og det samme gjør produksjonen av en tilbakekallingsliste. Hvis du har arvet en server som har sertifikat- og nøkkelfilene, men ikke CA-nøkkelen, kan du ikke signere noe nytt. Alternativene dine er å bygge PKI-en på nytt og gi hver klient et nytt CA-sertifikat, eller å bytte til passordautentisering, som er en annen sikkerhetsmodell og ikke gjenoppretter det som gikk tapt.

To mindre feller bor i samme område. easy-rsa-skriptene antar at du står i katalogen som inneholder dem, så en feil om manglende fil betyr vanligvis feil sted og ikke en skadet installasjon. Og et design med bare sertifikater er helt legitimt: du kan kreve klientsertifikater uten en forhåndsdelt nøkkel, forutsatt at hver klient har ett og serveren verifiserer kjeden.

Utsted ett sertifikat per enhet i stedet for ett delt klientsertifikat for hele teamet. En tapt bærbar datamaskin koster deg da én tilbakekalling i stedet for en nyutstedelse for alle.

Kontroller hva du har arvet

Før du planlegger noen endring, les sertifikatet 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 utstederen er lik subjektet, er sertifikatet selvsignert, noe som er et designvalg og ikke en feil. Datoene forteller deg når fornyelse blir noens problem, og en vellykket verifisering mot CA-en du har tenkt å levere, bekrefter at kjeden virker før en eneste klient prøver den.

Velg deretter etter publikum og distribusjon: offentlig CA når ukjente nettlesere må stole på administrasjonssiden, privat CA når hver klient mottar en profil du kontrollerer. Ingen av svarene er mer kryptert enn det andre.