Självsignerat eller offentlig CA för en VPN: vad som faktiskt ändras

Du kommer till certifikatsidan i en VPN-konfiguration, ser ett gratis självsignerat alternativ bredvid en betald offentlig CA, och frågan låter som ett säkerhetsval. Det är egentligen ett publikval. Båda alternativen krypterar tunneln med samma primitiver, och båda blir värdelösa om den privata nyckeln läcker. Det som skiljer dem är vem som gör påståendet om serverns identitet och vem som är i stånd att kontrollera det påståendet.

Ett certifikat gör två jobb som blandas ihop

Ett certifikat binder en offentlig nyckel till ett namn, och nyckeln gör krypterings- och signeringsarbetet. Signaturen på certifikatet är ett separat uttalande: någon myndighet har kontrollerat att namnet tillhör denna nyckelhavare. Ett självsignerat certifikat gör det uttalandet om sig själv, vilket inte alls är något påstående från tredje part.

Offentliga webbplatser behöver tredjepartsversionen, eftersom besökare kommer utan någon tidigare relation och förlitar sig på webbläsarens förtroendelager. En VPN-klient är ingen främling. Du ger den CA-certifikatet, eller fäster servercertifikatet, inne i profilen den installerar, så verifieringen körs mot exakt den myndighet du valde. Ingen kommersiell CA behöver vara inblandad för att den kontrollen ska betyda något.

Styrkan i den resulterande sessionen kommer från nyckelstorleken och chifferpaketet, inte från undertecknaren. Därför är det helt enkelt fel att kalla ett självsignerat certifikat "mindre krypterat"; det är mindre brett garanterat, vilket är en annan egenskap.

Där en offentlig CA tjänar in sin avgift

Det tydligaste fallet är administrationssidan. Om kollegor, entreprenörer eller någon annan utan en förberedd profil måste öppna VPN-serverns webbgränssnitt utan en webbläsarvarning, tar ett offentligt betrott certifikat bort den friktionen. Webbläsaren litar redan på undertecknaren, så det finns inget att importera och inget att förklara.

Den bekvämligheten har kostnader som är värda att nämna innan du köper. Förnyelsen måste automatiseras, annars går webbplatsen sönder enligt ett schema, offentliga certifikat exponerar värdnamnet i transparensloggar för certifikat, och gränser för utfärdandetakt straffar ett skript som försöker igen för ivrigt. Inget av detta är skäl att undvika en offentlig CA, men det är driftarbete som en privat CA flyttar någon annanstans.

Det ett offentligt certifikat inte gör är att autentisera dina användare. Klientidentitet är ett separat beslut, fattat med klientcertifikat, lösenord eller en andra faktor, och CA:n som signerar servern säger ingenting om vem som får ansluta till den.

Där en privat CA passar för en VPN

För en privat VPN med en känd uppsättning klienter är det det vanliga valet att driva sin egen CA. Du skapar CA:n en gång, signerar servercertifikatet med ett namn som klienterna kommer att använda, och distribuerar CA-certifikatet i varje profil. Varje klient verifierar då servern mot din myndighet, och ingen utomstående får kännedom om värdnamnet.

Kostnaderna är verkliga men begränsade. Webbläsare varnar när någon öppnar administrationssidan direkt, eftersom webbläsaren inte har någon anledning att lita på din CA. Profildistribution blir en del av introduktionen, och att rotera CA:n innebär att röra varje klient. Det är acceptabla priser för en tjänst med tio eller femtio kända användare och smärtsamt för en offentlig slutpunkt med tusentals.

Ett villkor gör hela arrangemanget giltigt: verifieringen måste ske. En klient som är konfigurerad att ignorera certifikatfel accepterar vilken server som helst som presenterar vilket certifikat som helst, så identitetsgarantin försvinner medan krypteringen består. Den inställningen är den verkliga svagheten i de flesta historier om att "självsignerat är osäkert".

CA:ns privata nyckel avgör vad du kan göra senare

Överraskningen kommer vanligtvis månader senare, när du vill lägga till en enhet. Att utfärda ett klientcertifikat kräver CA:ns privata nyckel, och detsamma gäller att ta fram en återkallningslista. Om du har ärvt en server som har certifikat- och nyckelfilerna men inte CA-nyckeln, kan du inte signera något nytt. Dina alternativ är att bygga om PKI:n och ge varje klient ett nytt CA-certifikat, eller att byta till lösenordsautentisering, vilket är en annan säkerhetsmodell och inte återställer det som gick förlorat.

Två mindre fällor bor i samma område. easy-rsa-skripten antar att du står i katalogen som innehåller dem, så ett fel om en saknad fil betyder oftast fel plats och inte en skadad installation. Och en design med bara certifikat är helt legitim: du kan kräva klientcertifikat utan en fördelad nyckel, förutsatt att varje klient har ett och att servern verifierar kedjan.

Utfärda ett certifikat per enhet i stället för ett delat klientcertifikat för hela teamet. En förlorad bärbar dator kostar dig då en enda återkallelse i stället för en nyutfärdande för alla.

Kontrollera vad du har ärvt

Innan du planerar någon ändring, läs certifikatet du redan 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

Om utfärdaren är lika med subjektet är certifikatet självsignerat, vilket är ett designval och inte en defekt. Datumen berättar när förnyelsen blir någons problem, och en lyckad verifiering mot CA:n du avser att leverera bekräftar att kedjan fungerar innan en enda klient provar den.

Välj sedan efter publik och distribution: offentlig CA när okända webbläsare måste lita på administrationssidan, privat CA när varje klient får en profil som du kontrollerar. Inget av svaren är mer krypterat än det andra.