Zelfondertekend VPN-certificaat: wat het betekent en waarop het vertrouwt

Twee overtuigingen richten hier de meeste schade aan: dat een zelfondertekend VPN-certificaat betekent dat de tunnel niet versleuteld is, en dat het installeren van wat de VPN-client ook vroeg alleen de VPN beïnvloedt. Geen van beide overleeft contact met een echte uitrol. Een zelfondertekend certificaat beschrijft een ondertekeningsrelatie, geen veiligheidsoordeel, en de reikwijdte van het vertrouwen dat je toevoegt hangt af van in welke opslag het belandt. Ik heb een helpdesk een provider-root in een Windows-machine zien importeren om één waarschuwing te dempen, en daarna een middag zien besteden aan uitleggen waarom de browser stopte met klagen over een niet-gerelateerd portaal. De twee helften van deze vraag horen bij elkaar, dus behandel ze als één.

Een certificaat is geen vertrouwensopslag

Het bestand dat de server presenteert, draagt een openbare sleutel, een subjectnaam, een uitgeversnaam, geldigheidsdatums en extensies. Zelfondertekend betekent dat het subject en de uitgever dezelfde entiteit zijn en de handtekening met de eigen sleutel van het certificaat wordt geverifieerd. Niets in die definitie zegt dat de verbinding zwak is, en niets zegt dat de client hem zal accepteren.

Acceptatie komt ergens anders vandaan: een CA-bestand waar je de client naar wijst, een vingerafdruk die je met de hand vergelijkt, of een root die al in een opslag staat die de client leest. Een uitrol kan volkomen gezond zijn terwijl het certificaat elke publieke test zou falen. openssl verify tegen de systeembundel meldt een onbekende uitgever, en dat rapport is correct, geen defect.

De optie ca van OpenVPN is het duidelijkste geval van aan de app gebonden vertrouwen. Dat bestand noemt de ankers die de client accepteert, en het kan één particuliere CA bevatten of, in een kleine uitrol, het eigen zelfondertekende certificaat van de server. Versie 2.6 accepteert ook --peer-fingerprint om een SHA-256-vingerafdruk vast te pinnen in plaats van een CA-bestand te verspreiden. WireGuard staat nog verder buiten: het heeft helemaal geen certificaten, alleen een statische openbare sleutel per peer, dus de zelfondertekeningsvraag is er niet op van toepassing.

Waar je vertrouwen installeert, bepaalt wie het erft

Zet hetzelfde certificaat op drie plekken en je krijgt drie verschillende explosieradiussen. Een bundel die alleen de VPN-client leest, beïnvloedt die client. Een root in de opslag van het besturingssysteem beïnvloedt elk programma dat die opslag raadpleegt. Een browser met zijn eigen vertrouwensdatabase kan beide negeren, en daarom kan een waarschuwing een import overleven die leek te werken.

Op Debian of Ubuntu verandert het neerleggen van een bestand in /usr/local/share/ca-certificates/ en het uitvoeren van update-ca-certificates de systeembrede bundel. Op Windows schrijft certutil -addstore -f Root naar de machineopslag en vereist een verhoogde prompt, terwijl het toevoegen van -user in plaats daarvan de opslag van de huidige gebruiker target; de twee zijn niet uitwisselbaar. Firefox houdt zijn eigen NSS-database, dus een import op OS-niveau verschijnt daar misschien nooit.

Bereik is belangrijk vanwege wat een autoriteit kan doen. Een uitgevende CA kan namen ondertekenen waarmee hij geen enkele relatie heeft, dus alles wat die opslag vertrouwt, accepteert die handtekeningen. Eén vastgepind blad kan dat niet; het authenticeert precies één peer-identiteit. Als het doel is één VPN te laten verbinden, bereikt een aan de app gebonden CA of een vastgepind blad dat, terwijl een machinebrede root een veel grotere concessie is dan het symptoom vereist.

Je versleutelt nog steeds zonder openbare CA

De TLS-handshake leidt sessiesleutels af ongeacht of het peercertificaat aansluit bij iets dat je al vertrouwt. Zelfondertekend betekent niet platte tekst, en niet dat het verkeer onderweg leesbaar is. Het betekent dat de client geen a-priori reden heeft om te geloven dat de sleutel bij de server hoort die hij heeft gevraagd.

In die kloof leven echte aanvallen. Een client die is geconfigureerd om elk certificaat te accepteren, hetzij via een uitgeschakelde verificatie-instelling, hetzij via een vertrouw-toch-maar-knop die één keer is ingedrukt en vergeten, versleutelt vrolijk naar wie dan ook antwoordt. De onderschepping gebeurt in de authenticatiestap, voordat applicatiegegevens bewegen. Versleuteling zonder identiteitscontrole houdt een passieve waarnemer buiten en doet weinig anders.

De uitgever vertrouwen slaat de naamcontrole niet over

Ketenvalidatie, naamafstemming en certificaatdoel zijn afzonderlijke beslissingen. Een keten kan geldig zijn terwijl de naam fout is, en een naam kan kloppen terwijl het certificaat voor een andere rol is uitgegeven. RFC 5280 definieert de velden die die beperkingen dragen, en hoe strikt een client ze handhaaft, is een zaak per toepassing.

OpenVPN maakt de splitsing zichtbaar. verify-x509-name pint het verwachte subject via name-, name-prefix- of subject-afstemming. remote-cert-tls server vereist dat het peercertificaat bruikbaar is als servercertificaat, wat een alleen-client-certificaat weigert, zelfs wanneer de uitgever vertrouwd is. Geen van beide instellingen wordt vervangen door het versturen van een CA-bestand.

Inspecteer het certificaat voordat je iets beslist:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName toont wie het heeft uitgegeven, voor welke namen en tot wanneer.
• openssl verify -CAfile ca.crt server.crt controleert of de keten die je wilt versturen het blad echt valideert.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error werkt voor TLS-eindpunten zoals een webportaal; het OpenVPN-protocol op 1194 is geen gewone TLS-stroom, dus die test geldt daar niet.

Een certificaat met een verlopen datum, zonder subjectAltName voor de naam waarmee je verbindt, of zonder serverAuth-gebruik faalt ongeacht hoe zorgvuldig het anker is geïnstalleerd.

Vijf controles voordat je er een accepteert

Vergelijk de vingerafdruk via een kanaal dat niet de verbinding is die je probeert te repareren: een console, een installer die je al hebt, een ondertekend configuratiebestand. openssl x509 -in server.crt -noout -fingerprint -sha256 op de server en dezelfde waarde in het clientlog zijn genoeg om te weten dat je naar één object kijkt.

Bepaal vervolgens wat je installeert: één blad, of een autoriteit die er meer kan slaan. Bepaal dan waar het heen gaat, en noem de toepassingen die die opslag lezen. Schrijf het verwijderpad op terwijl je het nog herinnert, want vertrouwen-en-doorgaan is hoe een tijdelijke import permanent wordt.

Plan ten slotte de wijziging. Een vastgepind certificaat of vingerafdruk moet via hetzelfde vertrouwde kanaal worden bijgewerkt wanneer het certificaat roteert, en een particuliere CA heeft zijn eigen uitgifte- en intrekkingslevenscyclus. Als de particuliere sleutel lekt, repareert opnieuw vertrouwen in een kopie van hetzelfde certificaat niets; de identiteit moet worden vervangen.

Als een waarschuwing alle vijf controles overleeft, is de nuttige vraag niet welke knop hem dempt, maar welke opslag de client werkelijk leest en waar die root vandaan kwam. Beantwoord dat, en de import die je op het punt staat te doen wordt een beslissing in plaats van een reflex.