Warum cryptoapicert in OpenVPN 3 und Connect unter Windows fehlschlägt

Sie kopieren ein funktionierendes OpenVPN 2-Profil in einen neueren Windows-Client, und das Zertifikat, das der alte Client selbst gefunden hat, wird nicht mehr angeboten. Die Zeile, die das ermöglichte, ist ein Windows-spezifischer Selektor, der zum Community-2-Client gehört, und die neuere Anwendung ist ein anderes Programm mit einem anderen Anmeldeinformationspfad. Das Profil ist bis auf diese eine Zeile unverändert, und genau das macht den Unterschied schwer erkennbar.

In diesem Bericht werden drei Ebenen vermischt: der Community-Client, die Kernbibliothek und das Frontend, das jemand installiert hat. Nur eine davon hat die Direktive jemals verstanden.

Was die Option bedeutet, wo es sie gibt

Im Community-OpenVPN-2-Client unter Windows benennt cryptoapicert ein Zertifikat, das der Client im Windows-Zertifikatspeicher statt in einer Datei suchen soll. Das ist eine Windows-spezifische Annehmlichkeit, und sie funktioniert, weil dieser Client den Speicher aufzählen und den resultierenden Schlüssel an seinen eigenen TLS-Stack übergeben kann. Die Direktive ist daher Teil der Konfigurationssprache dieses Clients, keine Eigenschaft des OpenVPN-Protokolls. Nichts im Übertragungsformat trägt sie.

Kopieren Sie dieselbe Zeile in eine andere Anwendung, und Sie haben ein Wort kopiert, das das neue Programm möglicherweise parst, ignoriert oder ablehnt. Eine Direktive ist keine Protokollfunktion, und diese ist nicht einmal eine Funktion jedes Clients, der OpenVPN.

Was die Kernbibliothek stattdessen bereitstellt

OpenVPN 3 Core ist eine Bibliothek, die andere Anwendungen einbetten, und sie behandelt externe Anmeldeinformationen über eine API statt über eine Speichersuche. Die einbettende Anwendung liefert eine Zertifikatskette und bittet die Bibliothek später, mit einem externen Schlüssel zu signieren, und die Bibliothek ruft dafür in die Anwendung zurück. Das ist ein allgemeineres Design, und es bedeutet, dass das Frontend entscheidet, welche Anbieter existieren. In der eigenen Optionsverarbeitung der Kernbibliothek erscheint cryptoapicert unter den Direktiven, die nicht implementiert sind, was zu dieser Aufgabenteilung passt.

Die Existenz dieser Callbacks bedeutet nicht, dass eine bestimmte paketierte Anwendung den persönlichen Speicher des aktuellen Benutzers aufzählt, einen bestimmten Schlüsselanbieter unterstützt oder eine Smartcard-Abfrage abschließen kann. Das sind Frontend-Eigenschaften, und jede davon muss vom Frontend dokumentiert werden.

Was das Windows-Frontend stattdessen tut

OpenVPN Connect geht einen anderen Weg: Der Betreiber importiert eine PKCS#12-Datei mit dem Zertifikat und seinem privaten Schlüssel in einen eigens dafür angelegten OpenVPN Certificate Store und weist das externe Zertifikat dann dem Profil zu. Das ist ein bewusster Importschritt, keine automatische Erkennung dessen, was zufällig im persönlichen Speicher liegt. Der Unterschied zählt, wenn jemand annimmt, ein für einen anderen Zweck installiertes Zertifikat erscheine einfach in der Liste des Clients.

Der Import hat auch Folgen für die Schlüsselrichtlinie, denn einen Schlüssel in eine P12-Datei zu exportieren ist genau das, was ein nicht exportierbarer Schlüssel verhindern soll. Das ist eine Richtlinienfrage und keine Konfigurationsfrage, und sie verdient eine Antwort, bevor jemand den Import versucht.

Wählen Sie einen Weg, der zur Richtlinie des Schlüssels passt

Ist die Anmeldeinformation exportierbar und erlaubt die Richtlinie den dokumentierten Import, nutzen Sie den geschützten Registrierungsprozess der Organisation und halten Sie die temporäre P12 und ihr Passwort aus Protokollen und Skripten heraus. Muss der Schlüssel eine Smartcard oder einen geschützten Anbieter niemals verlassen, wählen Sie eine Kombination aus Client und Anbieter, die diese Anforderung ausdrücklich unterstützt, oder lassen Sie sich die von Ihnen installierte Version vom Hersteller bestätigen. Keiner der beiden Zweige ist ein Ersatz für den anderen.

Die Direktive wieder zum Profil hinzuzufügen kann keine Integration liefern, die die Anwendung nicht hat. Auch eine neuere Client-Version fügt sie nicht zwangsläufig hinzu, weil die Fähigkeit zum eigenen Design des Frontends gehört.

Sobald der lokale Schlüssel funktioniert, prüft der Server weiterhin die Zertifikatsidentität, die Kette und die Autorisierung. Ein nutzbarer lokaler Schlüssel und eine akzeptierte VPN-Identität sind getrennte Ergebnisse, und sie getrennt zu halten ist das, was verhindert, dass eine Frontend-Einschränkung zu einer abgeschwächten Zertifikatsrichtlinie wird.