Mac-VPN-Zertifikat: Warum die Identitätsauswahl leer bleibt
Der Client braucht ein Zertifikat mit seinem privaten Schlüssel, in einem Speicher, den er liest. Prüfen Sie zuerst die Identität und dann, ob das Gateway sie akzeptiert.
Sie haben das Zertifikat installiert, es erscheint in der Keychain-Verwaltung mit einem freundlichen Namen, und die Identitätsauswahl des VPN-Clients ist weiterhin leer. Der Client sucht kein Zertifikat. Er sucht eine Identität: ein Zertifikat zusammen mit dem privaten Schlüssel, der den Besitz nachweisen kann, gespeichert dort, wo der Client lesen darf.
Was der Client verlangt, ist eine Identität
Das Sicherheitsframework von Apple behandelt ein Zertifikat und eine Identität als verschiedene Objekte. Ein Zertifikat sind öffentliche Daten. Eine Identität ist dieses Zertifikat plus sein privater Schlüssel, und nur die Identität kann eine Challenge abschließen. Ein vertrauenswürdiges CA-Zertifikat wiederum lässt einen Client einen Aussteller bewerten; es macht den Rechner nicht zum Inhaber ausgestellter Client-Anmeldedaten.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
Deshalb erzeugt der Import einer .cer Datei nie eine nutzbare Client-Identität. Die Datei enthält nur öffentliches Material, und kein Umbenennen oder Vertrauen macht daraus ein Schlüsselpaar.
Drei Gründe, warum die Auswahl leer bleibt
Der erste ist ein fehlender privater Schlüssel, was bedeutet, dass der Registrierungs- oder Importvorgang keinen geliefert hat. Der zweite ist ein Speicher, den der Client nicht heranzieht: Ein benutzerbezogenes Profil sucht im Schlüsselbund des Benutzers, und ein Element in einem System-Speicher kann für ihn unsichtbar sein. Der dritte ist eine Zweck- oder Richtlinienabweichung, bei der das Zertifikat existiert, aber nach den Regeln der Bereitstellung nicht für die Client-Authentifizierung gültig ist.
security find-identity -v -p ssl-clientDiese Ausgabe listet die Identitäten auf, die das System für die Client-Authentifizierung als gültig ansieht. Ist die Anzahl null, liegt das Problem oberhalb des VPN-Clients, und keine Profiländerung behebt es. Erscheint die Identität hier, aber nicht im Client, liegt der Unterschied im Speicher oder Umfang des Clients.
Wo der private Schlüssel lebt und wer ihn verwenden darf
Wenn Sie eine Identität über die Keychain-Verwaltung importieren, bietet der Importdialog einen Zielschlüsselbund an. Welches Ziel richtig ist, hängt vom Client und davon ab, ob das Profil benutzer- oder gerätebezogen ist. Eine alte Antwort, die den Systemschlüsselbund empfiehlt, ist keine allgemeine Regel, und das Kopieren von Elementen zwischen Speichern ist keine Reparatur.
System Roots ist eine Vertrauenssammlung. Ein Zertifikat dort abzulegen ändert, welchen Ausstellern das System vertraut; es erzeugt keinen privaten Schlüssel, und es ist kein Identitätsspeicher. Unzusammenhängende Zertifikate zu verschieben, um eine Auswahl zu füllen, ist die Art von Reparatur, die einen Rechner mit dauerhaft erweitertem Vertrauenssatz zurücklässt.
Der Zugriff auf den privaten Schlüssel ist eine separate Kontrolle. Jeder Anwendung die Erlaubnis zu geben, den Schlüssel zu verwenden löst das Auswahlproblem eines Clients und gibt dieselbe Fähigkeit an alles andere auf dem Rechner weiter. Geben Sie sie dem Client, der sie braucht, und prüfen Sie, ob der Schlüssel hardwaregestützt oder als nicht exportierbar markiert ist; wenn ja, muss der unterstützte Anbieter verwendet werden statt einer exportierten Kopie.
Wie das Profil auf die Anmeldedaten verweist
In einer verwalteten nativen IKEv2-Konfiguration verweist das Profil über PayloadCertificateUUID auf seine Zertifikatsnutzlast. Entscheidend sind die referenzierte Identität und die Art ihrer Bereitstellung; das Bearbeiten eines Anzeigenamens im Profil repariert keinen Verweis, der auf die falsche Nutzlast oder auf eine zeigt, die nie einen Schlüssel geliefert hat.
Ein Drittanbieter kann einen völlig anderen Auswahlmechanismus verwenden, etwa einen eigenen Speicher oder eine Systemabfrage. Lesen Sie die Dokumentation dieses Anbieters, statt Annahmen über das native Profil zu übertragen, und prüfen Sie den Verweis in dem Profil, das tatsächlich installiert ist, nicht in dem Entwurf der Verwaltungskonsole.
Auswahl und Annahme sind getrennte Meilensteine
Eine gefüllte Auswahl bedeutet, dass der Client eine Identität finden und verwenden kann. Das sagt nichts darüber aus, ob das Gateway sie akzeptiert. Der Server prüft weiterhin den Aussteller, das Gültigkeitsfenster, den Sperrstatus und die Zuordnung dieser Anmeldedaten zu einem Konto.
Testen Sie beide Stufen ausdrücklich, in dieser Reihenfolge. Bestätigen Sie, dass die Identität angeboten wird, verbinden Sie sich, und lassen Sie dann den Eigentümer des Gateways bestätigen, welche Anmeldedaten vorgelegt wurden und welche Zuordnungsregel sie verbraucht hat. Wenn der Client eine Identität anbietet und der Server sie ablehnt, liegt die verbleibende Arbeit auf der Serverseite. Eine Neuinstallation des Zertifikats auf dem Mac ändert dieses Ergebnis nicht, so oft sie auch wiederholt wird.