Zertifikat in Windows sichtbar, aber OpenVPN kann den Schlüssel nicht nutzen

Das Zertifikat ist in der Windows-Zertifikatsanzeige sichtbar, und der Client kann es dennoch nicht nutzen. Ein Zertifikat zu sehen beweist nur, dass ein öffentliches Objekt in einem Speicher existiert. Es beweist nicht, dass der Verbindungsprozess den passenden privaten Schlüssel findet oder ihn verwenden darf.

Drei Objekte müssen zusammenpassen. Das ausgewählte Zertifikat, der dahinterstehende private Schlüssel und das Konto, unter dem der Client läuft, sind getrennte Dinge, und jedes kann für sich scheitern.

Drei Objekte, drei Antworten

Die Community-Version von OpenVPN unter Windows dokumentiert eine CryptoAPI-Speicherauswahl, cryptoapicert, die einen Fingerabdruck entgegennimmt. Der Wert muss das Zertifikat bezeichnen, das Sie tatsächlich verwenden wollen, nicht ein ähnlich benanntes. Andere OpenVPN-basierte Anwendungen können ein völlig anderes Importmodell haben, daher ist die Auswahl nur für den Build ein Beleg, der sie dokumentiert. Bestätigen Sie, dass Ihr Client den Mechanismus umsetzt, bevor Sie weiter hinten in der Kette debuggen.

Unterstützt der Build die Auswahl nicht, ist die Lösung ein anderes Profilformat, kein anderes Zertifikat.

Führt die Auswahl zur richtigen Identität

Ein öffentliches Zertifikat lässt sich ohne seinen privaten Schlüssel importieren. Die Zertifikatsanzeige zeigt es in beiden Fällen, und deshalb sieht dieser Fehler aus, als ignoriere der Client ein Zertifikat, das offensichtlich vorhanden ist. Prüfen Sie die Schlüsselzuordnung, nicht nur das Vorhandensein des Eintrags.

Ein erneuertes Zertifikat bringt eine zweite Falle mit. Beide Einträge können im Speicher liegen, während das Profil noch den älteren Fingerabdruck nennt, und der Client wählt weiter die Identität, die Sie ausmustern wollten.

Prüfen Sie, zu welcher Identität die Auswahl auflöst, bevor Sie Berechtigungen ansehen. Ein falscher Fingerabdruck scheitert genauso wie ein fehlender Schlüssel.

Kann dieses Konto den Schlüssel nutzen

Schlüsselzugriff gilt pro Konto. Ein Dienst, eine geplante Aufgabe und eine interaktive Desktopsitzung können unterschiedliche Speicheransichten und unterschiedliche Berechtigungen für einen privaten Schlüssel haben. Dass das Zertifikat in Ihrer eigenen Sitzung sichtbar ist, sagt nichts über das Dienstkonto.

Ein hardwaregestützter Schlüssel braucht möglicherweise seinen Anbieter und einen Bestätigungsschritt. Ein Dienst, der keine Abfrage anzeigen kann, wird nicht dadurch gerettet, dass der Schlüssel in eine einfache Datei exportiert wird.

Lesen Sie den lokalen Fehler, bevor Sie etwas ändern. Ein Auswahlfehler, ein Signaturfehler und eine Ablehnung durch den Server sind drei verschiedene Ergebnisse. Nur die ersten beiden sind lokal. Das dritte bedeutet, dass der Schlüssel funktioniert hat und der Server gegen das Zertifikat entschieden hat.

Lokale Nutzung ist keine entfernte Annahme

Lokaler Erfolg ist keine Berechtigung. Nachdem der Client mit seinem Schlüssel signiert hat, bewertet der Server weiterhin den Aussteller, das Gültigkeitsfenster, die Rolle und seine Zugriffsrichtlinie. Ein anderes Zertifikat derselben CA bringt nicht automatisch dieselben VPN-Rechte mit.

Der Server braucht die Vertrauenskette, keine Kopie des privaten Client-Schlüssels. Den Schlüssel zum Server zu schicken ist nie die Reparatur eines Prüfproblems.

Arbeiten Sie den Fehler der Reihe nach ab

Halten Sie den genauen Fehlertext fest. Eine fehlende Schlüsselberechtigung sollte nicht zu einer CA-Änderung werden, und eine Ablehnung durch den Server nicht zu einer Speicherreparatur. Jedes hat seine eigenen Belege.

Arbeiten Sie in der Reihenfolge, in der der Fehler auftritt: Auswahl, Schlüssel, Konto, dann Serverrichtlinie. Die Community-Client-Referenz dokumentiert die Windows-Speicherauswahl für die Version, die Sie ausführen.