Mac-VPN-Anmeldung per Zertifikat: Identität, Schlüsselnutzung oder Gateway-Vertrauen?

Zertifikatsbasierte VPN-Anmeldungen verlangen vom Mac etwas Engeres als ein Passwort: diesen bestimmten privaten Schlüssel in diesem Ausführungskontext zu verwenden, um eine Identität gegenüber jenem Gateway zu belegen. Wenn es fehlschlägt, beschreibt die Meldung meist nur das Letzte, was schiefging, und das ist selten die Ursache. Die drei Entscheidungen in der Reihenfolge durchzugehen, in der das System sie trifft, hält die Diagnose ehrlich und verhindert, dass ein lokales Berechtigungsproblem als Kettenvalidierungsfehler behandelt wird.

Gehen Sie die Anmeldung in der Reihenfolge des Mac durch

Zuerst wählt der Client eine Identität: ein Zertifikat mit einem nutzbaren privaten Schlüssel, verfügbar über den unterstützten Speicher oder den Anmeldedaten-Anbieter. Dann verlangt die VPN-Komponente eine kryptografische Operation mit diesem Schlüssel, und das lokale Autorisierungsmodell antwortet. Erst wenn beides gelingt, findet der entfernte Handshake statt, bei dem der Mac das Gateway bewertet und das Gateway den Client-Nachweis bewertet.

Lesen Sie die Tabelle von oben nach unten und halten Sie bei der ersten Zeile an, die scheitert. Alles unterhalb eines Fehlers ist unbewiesen, weshalb „das Zertifikat ist nicht vertrauenswürdig“ eine so verbreitete wie unzuverlässige Schlussfolgerung ist.

Was die lokale Berechtigung tatsächlich abdeckt

Im macOS-Schlüsselbundmodell tragen geschützte Objekte operationsspezifische Zugriffsregeln und eine Liste vertrauenswürdiger Programme. Das Signieren mit einem privaten Schlüssel ist eine dieser Operationen, und die Regeln gelten für die ausführbare Datei, die sie ausführt, nicht für das Zertifikat als Dokument. Apples Referenz zur Zugriffskontrolle zieht zudem eine Grenze zwischen diesem Modell und dem iCloud-Schlüsselbund sowie Zugriffsgruppenregelungen, sodass für das eine geschriebener Rat nicht auf das andere übertragbar ist.

Daraus folgen zwei Konsequenzen. Dass ein öffentliches Zertifikat in einer Liste sichtbar ist, beweist nicht, dass die Hintergrundkomponente des VPN überhaupt an diesen Schlüssel gelangen kann. Und eine einem Frontend-Programm erteilte Berechtigung sagt nichts über einen separaten Helfer oder eine Netzwerkerweiterung aus, denn das ist anderer Code mit anderen Identitäten.

Ermitteln Sie die tatsächliche Implementierung und ihren unterstützten Mechanismus zur Weitergabe von Anmeldedaten, statt einen Programmpfad aus einem alten Client zu kopieren. Bestätigen Sie, welche Identität das System überhaupt anbieten wird:

security find-identity -v -p ssl-client

Lesen des Codes errSecInteractionNotAllowed

Dieser Status meldet eine unzulässige Interaktion mit dem Sicherheitsserver und sagt nichts über Zertifikatsketten aus. Lesen Sie ihn zusammen mit der Operation, die ihn erzeugt hat: Eine Signaturanforderung aus einem Kontext, der keine Abfrage anzeigen kann, schlägt so fehl, selbst wenn Schlüssel und Zertifikat beide einwandfrei gültig sind. Ausgangspunkt ist die Operation, die ihn protokolliert hat, nicht der Zertifikatsspeicher. Jede Änderung an Vertrauensankern lässt den Fehler genau dort, wo er war.

Behandeln Sie den Code daher als Grund, Ausführungskontext und Autorisierung zu prüfen. Ihn als Beleg dafür zu nehmen, dass die CA des Gateways nicht vertrauenswürdig ist, schickt Sie in die falsche Hälfte des Problems, und die dort vorgenommene Änderung wird den Fehler überhaupt nicht beeinflussen.

Eng reparieren, nicht breit

Beginnen Sie mit den Registrierungs- oder Importanweisungen des Verbindungseigentümers. Notieren Sie Clientversion, Profilumfang, die gewählte Identität und den ersten relevanten lokalen Fehler, denn diese vier Fakten braucht eine Support-Übergabe, und davon hängt ein späterer Vergleich ab. Ein verwaltetes Profil oder eine hardwaregestützte Identität kann erfordern, dass der Administrator oder der Anbieter die Übergabe repariert, und kein lokales Klicken ersetzt das.

Wo das Produkt eine Benutzergenehmigung erwartet, bestätigen Sie, welche Komponente fragt, und genehmigen Sie nur diesen Zugriff über den unterstützten Ablauf. Wo die Komponente in ihrem Ausführungskontext keine Abfrage auslösen kann, muss die Bereitstellung dem vom Hersteller dokumentierten Weg folgen, nicht einem Dialog, der aus einem anderen Terminalfenster hervorgelockt wird.

In älteren Ratschlägen werden zwei Änderungen gebündelt, und beide sind zu weit. Jedem Programm Zugriff auf den privaten Schlüssel zu geben, erweitert die lokale Schlüsselnutzung weit über die Anforderung hinaus, und das Zertifikat auf Immer vertrauen zu setzen, ändert die Zertifikatsbewertung für alles auf dem Rechner. Keine von beiden drückt „diese genehmigte VPN-Implementierung mit dieser vorgesehenen Identität“ aus.

Prüfen Sie lokal, bevor Sie das Gateway lesen

Bestätigen Sie nach einer Reparatur, dass die lokale Operation gelingt, bevor Sie eine Antwort der anderen Seite interpretieren. Funktioniert das Signieren jetzt, ist eine spätere Ablehnung von Name, Kette oder Client-Zulassung ein neues Ergebnis und keine Wiederholung, und sie gehört zu einer anderen Entscheidung mit einem anderen Verantwortlichen.

Eine nützliche Übergabe benennt, welche der drei Entscheidungen gescheitert ist, und hört dort auf. Sie enthält nie den privaten Schlüssel und setzt nie unabhängige Schlüsselbundobjekte zurück in der Hoffnung, ein sauberes Blatt helfe. Legen Sie diese zwei Gewohnheiten vor dem Vorfall an statt währenddessen, wenn die Versuchung, alles auf einmal zu probieren, am stärksten ist. Ein Ticket, das „Schlüsselbund neu aufgebaut“ sagt, verrät dem nächsten Leser fast nichts über den ursprünglichen Fehler.