Selbstsigniert vs. öffentliche CA für ein VPN: Was sich wirklich ändert
Selbstsignierte und öffentliche Zertifikate verschlüsseln einen VPN-Tunnel auf dieselbe Weise. Der eigentliche Unterschied ist, wer für den Server bürgt und wer dieser Behauptung vertrauen muss.
Sie erreichen die Zertifikatsseite einer VPN-Einrichtung, sehen eine kostenlose selbstsignierte Option neben einer kostenpflichtigen öffentlichen CA, und die Frage klingt nach einer Sicherheitsentscheidung. Sie ist in Wahrheit eine Publikumsentscheidung. Beide Optionen verschlüsseln den Tunnel mit denselben Grundbausteinen, und beide werden wertlos, wenn der private Schlüssel abfließt. Was sie trennt, ist, wer die Behauptung über die Identität des Servers aufstellt und wer in der Lage ist, diese Behauptung zu prüfen.
Ein Zertifikat erfüllt zwei Aufgaben, die verwechselt werden
Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Namen, und der Schlüssel erledigt die Verschlüsselungs- und Signaturarbeit. Die Signatur auf dem Zertifikat ist eine getrennte Erklärung: Irgendeine Autorität hat geprüft, dass der Name zu diesem Schlüsselinhaber gehört. Ein selbstsigniertes Zertifikat stellt diese Erklärung über sich selbst aus, was überhaupt keine Behauptung eines Dritten ist.
Öffentliche Websites brauchen die Variante mit Drittpartei, weil Besucher ohne vorherige Beziehung eintreffen und sich auf den Vertrauensspeicher des Browsers verlassen. Ein VPN-Client ist kein Fremder. Sie geben ihm das CA-Zertifikat oder heften das Serverzertifikat im Profil fest, das er installiert, sodass die Prüfung gegen genau die Autorität läuft, die Sie gewählt haben. Keine kommerzielle CA muss beteiligt sein, damit diese Prüfung etwas bedeutet.
Die Stärke der resultierenden Sitzung kommt von der Schlüsselgröße und der Verschlüsselungssuite, nicht vom Unterzeichner. Deshalb ist es schlicht falsch, ein selbstsigniertes Zertifikat "weniger verschlüsselt" zu nennen; es ist weniger breit verbürgt, was eine andere Eigenschaft ist.
Wo eine öffentliche CA ihre Gebühr verdient
Der klarste Fall ist die Administrationsseite. Wenn Kollegen, Auftragnehmer oder sonst jemand ohne vorbereitetes Profil die Weboberfläche des VPN-Servers ohne Browserwarnung öffnen müssen, beseitigt ein öffentlich vertrauenswürdiges Zertifikat diese Reibung. Der Browser vertraut dem Unterzeichner bereits, also gibt es nichts zu importieren und nichts zu erklären.
Dieser Komfort hat Kosten, die man vor dem Kauf nennen sollte. Die Erneuerung muss automatisiert werden, sonst bricht die Seite nach Plan, öffentliche Zertifikate legen den Hostnamen in Zertifikatstransparenzprotokollen offen, und Ratenbegrenzungen für die Ausstellung bestrafen ein Skript, das zu eifrig erneut versucht. Nichts davon ist ein Grund, eine öffentliche CA zu meiden, aber es ist Betriebsarbeit, die eine private CA woandershin verlagert.
Was ein öffentliches Zertifikat nicht tut, ist Ihre Benutzer zu authentifizieren. Die Client-Identität ist eine separate Entscheidung, getroffen mit Clientzertifikaten, Passwörtern oder einem zweiten Faktor, und die CA, die den Server signiert, sagt nichts darüber aus, wer sich mit ihm verbinden darf.
Wo eine private CA zu einem VPN passt
Für ein privates VPN mit einem bekannten Satz von Clients ist der Betrieb einer eigenen CA die übliche Wahl. Sie erstellen die CA einmal, signieren das Serverzertifikat mit einem Namen, den die Clients verwenden werden, und verteilen das CA-Zertifikat in jedem Profil. Jeder Client prüft dann den Server gegen Ihre Autorität, und keine außenstehende Partei erfährt den Hostnamen.
Die Kosten sind real, aber begrenzt. Browser warnen, wenn jemand die Administrationsseite direkt öffnet, weil der Browser keinen Grund hat, Ihrer CA zu vertrauen. Die Profilverteilung wird Teil des Onboardings, und beim Wechsel der CA muss jeder Client angefasst werden. Das sind akzeptable Preise für einen Dienst mit zehn oder fünfzig bekannten Nutzern und schmerzhaft für einen öffentlichen Endpunkt mit Tausenden.
Eine Bedingung macht die ganze Anordnung gültig: Die Prüfung muss stattfinden. Ein Client, der so konfiguriert ist, Zertifikatsfehler zu ignorieren, akzeptiert jeden Server, der irgendein Zertifikat vorlegt, sodass die Identitätsgarantie verschwindet, während die Verschlüsselung bleibt. Diese Einstellung ist die eigentliche Schwäche in den meisten Geschichten von "selbstsigniert ist unsicher".
Der private CA-Schlüssel entscheidet, was Sie später tun können
Die Überraschung kommt meist Monate später, wenn Sie ein Gerät hinzufügen möchten. Das Ausstellen eines Clientzertifikats erfordert den privaten CA-Schlüssel, ebenso das Erzeugen einer Sperrliste. Wenn Sie einen Server übernommen haben, der die Zertifikats- und Schlüsseldateien, aber nicht den CA-Schlüssel hat, können Sie nichts Neues signieren. Ihre Möglichkeiten sind, die PKI neu aufzubauen und jedem Client ein neues CA-Zertifikat zu geben oder auf Passwortauthentifizierung umzusteigen, was ein anderes Sicherheitsmodell ist und das Verlorene nicht wiederherstellt.
Zwei kleinere Fallen liegen im selben Bereich. Die easy-rsa-Skripte gehen davon aus, dass Sie in dem Verzeichnis stehen, das sie enthält, ein Fehler über eine fehlende Datei bedeutet also meist den falschen Ort und nicht eine beschädigte Installation. Und ein reines Zertifikatsdesign ist völlig legitim: Sie können Clientzertifikate ohne vorab geteilten Schlüssel verlangen, sofern jeder Client eines hat und der Server die Kette prüft.
Stellen Sie ein Zertifikat pro Gerät aus statt eines gemeinsamen Clientzertifikats für das ganze Team. Ein verlorener Laptop kostet Sie dann einen einzigen Widerruf statt einer Neuausstellung für alle.
Prüfen Sie, was Sie übernommen haben
Lesen Sie vor jeder geplanten Änderung das Zertifikat, das Sie bereits haben:
$ 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
Wenn der Aussteller dem Subjekt entspricht, ist das Zertifikat selbstsigniert, was eine Designentscheidung und kein Defekt ist. Die Daten sagen Ihnen, wann die Erneuerung zu jemandes Problem wird, und eine erfolgreiche Prüfung gegen die CA, die Sie ausliefern wollen, bestätigt, dass die Kette funktioniert, bevor ein einziger Client sie ausprobiert.
Wählen Sie dann nach Publikum und Verteilung: öffentliche CA, wenn unbekannte Browser der Administrationsseite vertrauen müssen, private CA, wenn jeder Client ein Profil erhält, das Sie kontrollieren. Keine der Antworten ist stärker verschlüsselt als die andere.