Selbstsigniertes Client-Zertifikat? Der VPN-Server lehnt es trotzdem ab

Der Betreiber schickt eine Adresse und einen Benutzernamen, und der Client verlangt eine CA-Datei, ein Zertifikat und einen Schlüssel. Diese drei lokal zu erzeugen wirkt wie der naheliegende nächste Schritt. Es entsteht ein Zertifikat, dem nur Ihr eigener Rechner glaubt. Das Vertrauen des Servers ist in einer CA verankert, die Sie nicht kontrollieren, deshalb endet der Handshake, bevor er beginnt.

Vertrauen liegt auf dem Server, nicht in Ihrem Profil

Zertifikatsauthentifizierung ist ein Vergleich. Der Client legt ein Zertifikat vor; das Gateway prüft, ob es von einer der CAs in seiner Konfiguration signiert wurde.

Ihr Profil nennt die CA-Datei, die der Client zur Prüfung des Servers verwenden soll. Es kann keine CA nennen, die der Server zur Prüfung von Ihnen verwenden soll. Diese Hälfte der Konfiguration gehört nicht Ihnen.

Ein selbst erzeugtes Zertifikat scheitert an diesem Vergleich, auch wenn es technisch einwandfrei ist. Es hat eine gültige Signatur, einen Subject und Daten, aber der Aussteller ist eine CA, von der das Gateway nie gehört hat. Der Fehler erscheint während des Handshakes, nachdem der Server bereits ein Zertifikat angefordert hat. Nichts im Clientprofil kann die Antwort ändern.

Warum ein selbstsigniertes Zertifikat nicht einspringen kann

Ein selbstsigniertes Zertifikat ist mit seinem eigenen Schlüssel signiert. Die Signatur verifiziert gegen dieselbe Datei, was es in sich stimmig und als Berechtigungsnachweis für ein fremdes Gateway wertlos macht.

Das Gateway fragt nicht, ob das Zertifikat intern stimmig ist. Es fragt, ob ein vertrauenswürdiger Aussteller es signiert hat.

Deshalb sind die Fehlermeldungen verwirrend. Der Client meldet vielleicht einen Verifikationsfehler, der nach einem Serverproblem klingt, während der Server einen unbekannten Aussteller protokolliert. Beide beschreiben dieselbe Unstimmigkeit von entgegengesetzten Enden.

Der CSR-Weg behält Ihren privaten Schlüssel

Den größten Teil der Arbeit können Sie weiterhin lokal erledigen. Erzeugen Sie ein Schlüsselpaar, bauen Sie eine Zertifikatsignierungsanfrage um die öffentliche Hälfte und schicken Sie diese Anfrage an den Betreiber. Nur die Anfrage verlässt Ihren Rechner. Die private Hälfte bleibt, wo Sie sie erzeugt haben.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Der Betreiber signiert die Anfrage mit seiner CA und schickt ein Zertifikat zurück. Ihr privater Schlüssel ist nie gereist, und das Ergebnis führt zu dem Anker, dem das Gateway vertraut.

Verwaltete Dienste überspringen den CSR oft und stellen das ganze Bündel aus. Das ist ein vernünftiger Tausch, wenn derselbe Anbieter ohnehin den Tunnel beendet und die CA hält. Die Verwahrung des Schlüssels wird nicht besser, indem Sie ihn behalten, denn der Anbieter könnte jederzeit einen neuen prägen.

Bündel werden importiert, nicht installiert

Anbieterbündel mit sicherheitsklingenden Namen sind häufig OpenVPN-Profile. Sie enthalten Konfiguration und manchmal Zertifikate, und sie installieren nichts. Importieren Sie die Datei in einen Client, der das Protokoll spricht, und die Verbindung ist konfiguriert.

Die Handhabungsregel folgt aus dem Inhalt. Wenn das Profil einen privaten Schlüssel einbettet, ist es ein Berechtigungsnachweis und verdient dieselbe Sorgfalt wie ein Passwort: keine E-Mail, kein Repository, kein geteilter Downloadordner. Wenn der Betreiber ca.crt, client.crt und client.key getrennt liefert, speichern Sie sie zusammen mit restriktiven Rechten und verweisen Sie das Profil darauf.

Ergänzen Sie die Prüfungen, die der Betreiber übersprungen haben könnte

Ein routergeneriertes Profil ermangelt manchmal der Peer-Verifikation. remote-cert-tls server verlangt, dass das Peer-Zertifikat den Zweck Serverauthentifizierung trägt, sodass ein Client-Zertifikat nicht als Server wiedergegeben werden kann. Diese eine Zeile ist eine kleine Änderung mit klarer Begründung.

verify-x509-name geht weiter, wenn der Betreiber den erwarteten Subject oder SAN nennen kann. Beides sind kleine Ergänzungen eines Profils, und beides ist vertretbar. Prüfen Sie, was Sie erhalten haben, bevor Sie es importieren.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Verifikationseinstellungen sind keine Reparatur einer gebrochenen Kette. Ist der Aussteller falsch, lautet die Antwort ein Zertifikat der richtigen CA, nicht ein Schalter, der die Prüfung abschaltet. Verifikation abzuschalten macht aus einem Authentifizierungsfehler einen unentdeckten.

Bitten Sie um ein Bündel: das Zertifikat der Autorität als PEM, ein von dieser Autorität signiertes Client-Zertifikat, einen Schlüssel, den Sie erzeugt haben oder der über einen Kanal kam, dem Sie vertrauen, und den genauen Servernamen, den das Zertifikat präsentieren soll. Notieren Sie das Ablaufdatum in derselben Nachricht, denn ein abgelaufenes Zertifikat sieht Monate später wie ein Netzwerkfehler aus.