Warum OpenVPN mit Token weiterhin eine Datei für den privaten Schlüssel verlangt

Sie stecken den Token an, das Werkzeug des Anbieters selbst erkennt ihn, und der VPN-Client fragt trotzdem nach einer Datei für den privaten Schlüssel. Diese Aufforderung ist kein Beleg dafür, dass der Token nicht unterstützt wird. Sie bedeutet meist, dass das Profil dem Client nie gesagt hat, er solle den Token verwenden, sodass er auf die Zertifikats- und Schlüsseleingaben zurückfiel, die er standardmäßig erwartet.

Zwei getrennte Werte müssen stimmen, bevor dieser Rückfall aufhört: der Anbieter, der den Token bereitstellt, und die Identität des Zertifikats darin. Sie werden über verschiedene Optionen übergeben und lassen sich leicht verwechseln.

Der Client fragt nach einer Datei, weil das Profil es so vorgibt

Ein Standardprofil erwartet eine Zertifikatsdatei und eine Datei für den privaten Schlüssel oder ein einzelnes PKCS#12-Bündel. Fehlen diese Eingaben, hat der Client nichts zu laden und verhält sich fast wie bei einer fehlenden Datei, weshalb das Symptom als defekter Pfad statt als fehlender Mechanismus gelesen wird. Der PKCS#11-Pfad ersetzt diese Eingaben, statt sie zu ergänzen, sodass ein Profil, das weiterhin eine Schlüsseldatei nennt, die Datei auch weiterhin verwendet. Entfernen Sie die Dateieingaben bewusst und lassen Sie den Token beide Hälften liefern.

Die Anbieteroption benennt eine Middleware-Bibliothek, kein Gerät und kein Zertifikat. Ob ein paketierter Client diese Bibliothek laden kann, hängt davon ab, wie er gebaut wurde, einschließlich der optionalen p11-kit-Unterstützung, die manche Builds aktivieren und andere weglassen. Eine allgemeine Anleitung kann Ihnen nicht sagen, welche Anordnung Ihr Paket hat.

Die serialisierte Identität ist ein anderer Wert

Die Zertifikatsidentität ist eine lange serialisierte Zeichenkette, die der Ermittlungsprozess erzeugt, und sie ist weder der Bibliothekspfad noch die PIN des Tokens noch der Name des VPN-Kontos. Sie enthält oft Zeichen, die in Anführungszeichen gesetzt werden müssen, und ein Wert ohne Anführungszeichen kann ohne klare Fehlermeldung abgeschnitten oder falsch gelesen werden. Nutzen Sie die eigene Option Identitätsermittlung des Clients, um aufzulisten, was der Token bereitstellt, und kopieren Sie dann den gewünschten Eintrag exakt. Das erste Objekt in der Liste zu wählen, ist der Weg, auf dem ein Gerät am Ende das falsche Zertifikat vorlegt.

Die Ausgabe der Ermittlung beantwortet auch eine vorherige Frage: ob der Token über diesen Anbieter überhaupt sichtbar ist. Listet sie nichts auf, liegt das Problem oberhalb des VPN-Clients und gehört zur Middleware.

Der Prozess, der sich verbindet, muss den Token erreichen

Eine Token-Operation, die in Ihrer Desktop-Sitzung funktioniert, beweist nichts über einen Systemdienst. Der Dienst kann als anderer Benutzer laufen, in einem anderen Mount-Namensraum, mit einem Modulpfad, der die Anbieterbibliothek auslässt, oder ohne Berechtigung, den Geräteknoten zu öffnen. Stellen Sie fest, welcher Prozess die Verbindung tatsächlich hält, und testen Sie aus diesem Kontext.

Der Umgang mit der PIN verdient eine eigene Entscheidung. Die Referenzimplementierung bietet einen PIN-Cache und einen geschützten Authentifizierungspfad, und beides existiert, damit ein Betreiber einen Ablauf wählen kann, statt einen zu erfinden. Wandeln Sie eine unbeaufsichtigte Anforderung nicht in eine PIN im Klartext innerhalb eines gemeinsamen Profils um, denn das tauscht den Schutz des Tokens gegen Bequemlichkeit. Wo der Token den Schlüsselexport verbietet, geschieht die Signatur auf dem Gerät und die PIN ist das einzige lokale Geheimnis. Behandeln Sie sie mit der Sorgfalt, die das impliziert.

Was der Token nicht ersetzt

Der Token authentifiziert den Client unter der bereitgestellten Richtlinie und ersetzt nicht die Prüfungen des Clients gegenüber dem Server. Ein erfolgreich ausgewähltes Zertifikat ist keine Erlaubnis, ein unerwartetes Gateway-Zertifikat zu akzeptieren, und die beiden Prüfungen schützen entgegengesetzte Richtungen.

Die Registrierung muss weiterhin beim Aussteller erfolgen, und das Gateway muss die Identität weiterhin autorisieren.

Trennen Sie für die Abnahme die Stufen: Der Anbieter lädt, das beabsichtigte Zertifikat wird gefunden, der private Schlüssel wird mit lokaler Autorisierung genutzt, das VPN authentifiziert sich, und die Ressourcenoperation gelingt. Bleiben Sie bei der ersten Stufe stehen, die fehlschlägt, statt Passwörter durchzuprobieren und den Krypto-Stack neu zu installieren.

Halten Sie Versionen, Moduleigentum, die gewählte öffentliche Kennung und bereinigte Fehler fest, und lassen Sie PINs und Anmeldedatenbündel aus diesem Protokoll heraus.