Zelfondertekend versus openbare CA voor een VPN: wat er echt verandert

Je komt op de certificaatpagina van een VPN-opstelling, ziet een gratis zelfondertekende optie naast een betaalde openbare CA, en de vraag klinkt als een beveiligingskeuze. Het is in werkelijkheid een publiekskeuze. Beide opties versleutelen de tunnel met dezelfde primitieven, en beide worden waardeloos als de privésleutel uitlekt. Wat ze scheidt, is wie de bewering over de identiteit van de server doet, en wie in staat is die bewering te controleren.

Een certificaat doet twee taken die worden verward

Een certificaat bindt een openbare sleutel aan een naam, en de sleutel doet het versleutelings- en ondertekeningswerk. De handtekening op het certificaat is een aparte verklaring: een of andere autoriteit heeft gecontroleerd dat de naam bij deze sleutelhouder hoort. Een zelfondertekend certificaat doet die verklaring over zichzelf, wat helemaal geen bewering van een derde partij is.

Openbare websites hebben de versie van een derde partij nodig, omdat bezoekers zonder eerdere relatie komen en op de vertrouwensopslag van de browser vertrouwen. Een VPN-client is geen vreemde. Je geeft hem het CA-certificaat, of pint het servercertificaat vast, in het profiel dat hij installeert, zodat de verificatie precies tegen de autoriteit loopt die je hebt gekozen. Geen commerciële CA hoeft betrokken te zijn wil die controle iets betekenen.

De sterkte van de resulterende sessie komt van de sleutelgrootte en de ciphersuite, niet van de ondertekenaar. Daarom is een zelfondertekend certificaat "minder versleuteld" noemen gewoon onjuist; het is minder breed gegarandeerd, wat een andere eigenschap is.

Waar een openbare CA zijn vergoeding verdient

Het duidelijkste geval is de beheerderspagina. Als collega's, aannemers of iemand anders zonder voorbereid profiel de webinterface van de VPN-server moeten openen zonder browserwaarschuwing, neemt een publiek vertrouwd certificaat die wrijving weg. De browser vertrouwt de ondertekenaar al, dus er is niets te importeren en niets uit te leggen.

Dat gemak heeft kosten die het waard zijn om te noemen voordat je koopt. Vernieuwing moet worden geautomatiseerd, anders breekt de site volgens een schema, openbare certificaten onthullen de hostnaam in transparantielogs voor certificaten, en uitgeefsnelheidslimieten straffen een script dat te ijverig opnieuw probeert. Niets daarvan is een reden om een openbare CA te vermijden, maar het is operationeel werk dat een private CA elders onderbrengt.

Wat een openbaar certificaat niet doet, is je gebruikers authenticeren. Klantidentiteit is een aparte beslissing, genomen met klantcertificaten, wachtwoorden of een tweede factor, en de CA die de server ondertekent zegt niets over wie er verbinding mee mag maken.

Waar een private CA bij een VPN past

Voor een private VPN met een bekende set clients is het draaien van je eigen CA de conventionele keuze. Je maakt de CA één keer aan, ondertekent het servercertificaat met een naam die de clients zullen gebruiken, en verdeelt het CA-certificaat in elk profiel. Elke client verifieert dan de server tegen jouw autoriteit, en geen enkele buitenstaander leert de hostnaam.

De kosten zijn reëel maar begrensd. Browsers waarschuwen wanneer iemand de beheerderspagina rechtstreeks opent, omdat de browser geen reden heeft om je CA te vertrouwen. Profieldistributie wordt onderdeel van de onboarding, en de CA roteren betekent elke client aanraken. Dat zijn acceptabele prijzen voor een dienst met tien of vijftig bekende gebruikers en pijnlijk voor een openbaar eindpunt met duizenden.

Eén voorwaarde maakt de hele regeling geldig: de verificatie moet plaatsvinden. Een client die is geconfigureerd om certificaatfouten te negeren, accepteert elke server die welk certificaat dan ook presenteert, dus de identiteitsgarantie verdwijnt terwijl de versleuteling blijft. Die instelling is de werkelijke zwakte in de meeste verhalen dat "zelfondertekend onveilig is".

De privésleutel van de CA bepaalt wat je later kunt doen

De verrassing komt meestal maanden later, wanneer je een apparaat wilt toevoegen. Het uitgeven van een klantcertificaat vereist de privésleutel van de CA, en het produceren van een intrekkingslijst ook. Als je een server hebt geërfd met de certificaat- en sleutelbestanden maar niet de CA-sleutel, kun je niets nieuws ondertekenen. Je opties zijn de PKI opnieuw opbouwen en elke client een nieuw CA-certificaat geven, of overstappen op wachtwoordauthenticatie, wat een ander beveiligingsmodel is en het verlorene niet herstelt.

Twee kleinere valkuilen leven in hetzelfde gebied. De easy-rsa-scripts gaan ervan uit dat je in de map staat die ze bevat, dus een fout over een ontbrekend bestand betekent meestal de verkeerde locatie en niet een beschadigde installatie. En een ontwerp met alleen certificaten is volkomen legitiem: je kunt klantcertificaten vereisen zonder vooraf gedeelde sleutel, mits elke client er een heeft en de server de keten verifieert.

Geef één certificaat per apparaat uit in plaats van één gedeeld klantcertificaat voor het hele team. Een verloren laptop kost je dan één intrekking in plaats van een heruitgave voor iedereen.

Controleer wat je hebt geërfd

Lees voordat je een wijziging plant het certificaat dat je al hebt:

$ 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

Als de uitgever gelijk is aan het onderwerp, is het certificaat zelfondertekend, wat een ontwerpkeuze is en geen defect. De datums vertellen je wanneer vernieuwing iemands probleem wordt, en een geslaagde verificatie tegen de CA die je wilt uitrollen bevestigt dat de keten werkt voordat één client het probeert.

Kies dan op basis van publiek en distributie: openbare CA wanneer onbekende browsers de beheerderspagina moeten vertrouwen, private CA wanneer elke client een profiel krijgt dat jij beheert. Geen van beide antwoorden is meer versleuteld dan het andere.