Ein eigenes VPN-Zertifikat ist keine zusätzliche Verschlüsselungsschicht

Ein eigenes Zertifikat auf einem VPN-Endpunkt zu installieren fühlt sich wie zusätzlicher Schutz an, weil Zertifikate und Verschlüsselung überall gemeinsam auftreten. Tatsächlich ändert es zwei Dinge: welche Identität der Endpunkt vorzeigt und welchem Aussteller sein Gegenüber zu vertrauen bereit ist. Keines von beiden wickelt Ihre Daten ein zweites Mal ein. Wenn die eigentliche Anforderung ein zweiter geschützter Kanal ist, brauchen Sie einen zweiten Kanal mit eigenen Endpunkten, nicht noch ein Zertifikat.

Drei getrennte Aufgaben in einem TLS 1.3-Handshake

RFC 8446 hält diese Dinge getrennt, und genau diese Trennung ist die ganze Antwort. Die Certificate-Nachricht trägt die Zertifikatskette des Endpunkts. CertificateVerify beweist den Besitz des passenden privaten Schlüssels und bindet das Handshake-Transkript. Die Record-Schicht schützt den Datenverkehr mit den ausgehandelten Traffic-Keys.

Tauschen Sie das Zertifikat, ändern sich die ersten beiden Punkte. Der Record-Schutz läuft nicht zweimal und wird nicht stärker, nur weil der Aussteller jetzt privat ist.

Was eine private CA tatsächlich bringt

Sie bringt ein kontrolliertes Identitätssystem: Sie entscheiden, wer ausgestellt bekommt, Sie entscheiden, welche Aussteller Gegenstellen akzeptieren, und Sie können nach Ihrem eigenen Zeitplan widerrufen. Das ist wirklich nützlich, wenn Sie beide Enden betreiben.

Sie bringt aber auch Pflichten mit. Vertrauen muss bewusst verteilt werden, die Gegenstellenprüfung muss eingeschaltet bleiben, und jemand muss den Lebenszyklus der Zugangsdaten verantworten. Eine private CA ist keine Abkürzung an einem dieser drei Punkte vorbei.

Wann ein zweiter Kanal die richtige Antwort ist

Angenommen, eine Anwendung öffnet verifiziertes HTTPS zu ihrem eigenen Dienst, während ihre Pakete zusätzlich durch ein VPN laufen. Dieses Design hat zwei Grenzen mit möglicherweise unterschiedlichen Endpunkten, und so sieht ein zweiter geschützter Kanal aus.

Der Unterschied zählt am Gateway. Wenn die TLS-Sitzung der Anwendung am VPN-Gateway endet statt bei der Anwendung, ist der Schutz, den Sie jenseits des Tunnels vermutet haben, nicht da. Schreiben Sie auf, wer welchen Kanal beendet, bevor Sie die Eigenschaft behaupten.

Fragen Sie, was die Installation ändert

Ein Antrag, ein Zertifikat zu installieren, kann drei verschiedene Dinge bedeuten. Er kann die eigene Identität des Clients ändern, einen anwendungsspezifischen Vertrauensanker oder plattformweites Vertrauen für alles auf dem Gerät. Das ist nicht gleichwertig, und nur das letzte betrifft fremde Software.

Fragen Sie, welche der drei gemeint ist, und dann, was sie erreichen soll. Lautet die Antwort mehr Verschlüsselung, zielt der Vorschlag auf den falschen Mechanismus.

Schreiben Sie die Grenzen auf

Notieren Sie für jeden Kanal die Endpunkte, die Identität, die jede Seite prüft, und was der Betreiber in der Mitte sehen kann. Notieren Sie dann das Fehlerverhalten: was passiert, wenn die Prüfung scheitert, und was, wenn der Kanal abgelehnt wird.

Zwei Zeilen auf einer Seite entscheiden meist einen Streit, den eine Zertifikatsrotation nicht entscheiden kann.

Entscheiden Sie mit drei Fragen

Ist das Problem, wer der Endpunkt zu sein behauptet, oder was mit den Daten passiert? Muss der Schutz über das VPN-Gateway hinaus bis zu einer bestimmten Anwendung reichen? Und können Sie die zwei Endpunkte benennen, die einen zweiten Kanal beenden würden?

Ist die erste Frage die richtige, korrigieren Sie Identität und Vertrauen. Ist es die zweite oder dritte, entwerfen Sie den zweiten Kanal und lassen Sie das Zertifikat, wo es hingehört.