IKEv2-Zertifikat auf dem iPhone einrichten: manuelle oder verwaltete Registrierung

RSA zu wählen, weil das Zertifikatswerkzeug des Gateways es standardmäßig verwendet, ist eine Entscheidung, die vor der eigentlich wichtigen Frage getroffen wird: Wie werden diese iPhones registriert? Eine vom Benutzer eingetippte Verbindung und ein von der Verwaltung bereitgestelltes Konfigurationsprofil bieten unterschiedliche Einstellungen, und manche Zertifikatsentscheidungen gibt es nur auf einem dieser Wege. Stimmt die Reihenfolge, wird der Zertifikatsplan kurz; stimmt sie nicht, stellen Sie Anmeldedaten aus, die das Telefon nicht verwendet. Behandeln Sie die folgenden Schritte als Abfolge, denn jeder verengt die Möglichkeiten des nächsten.

Schritt eins: Registrierungsweg wählen

Manuelle Einrichtung bedeutet, dass der Benutzer die Serveradresse eingibt, die Authentifizierungsmethode wählt und alle Anmeldedaten liefert, die die Oberfläche zulässt. Verwaltete Registrierung bedeutet, dass ein Profil die Adresse, die Identifikatoren und einen Verweis auf eine Anmeldedaten-Nutzlast enthält. Der verwaltete Weg kann Kombinationen ausdrücken, die der manuelle Bildschirm nicht kann, deshalb muss die Zertifikatsentscheidung nach dieser Wahl kommen und nicht davor.

Beide Wege können ein Telefon authentifizieren. Sie unterscheiden sich darin, was konfigurierbar ist und wem die Identität gehört, wählen Sie also bewusst einen, statt ein verwaltetes Profil mit manueller Eingabe von Anmeldedaten zu mischen.

Schritt zwei: Algorithmen für den gewählten Weg auswählen

Für manuell konfigurierte iPhones empfehlen die iOS-Interoperabilitätshinweise von strongSwan ein RSA-Serverzertifikat, weil der manuelle Client ein ECDSA-Serverzertifikat möglicherweise nicht akzeptiert; dieselben Hinweise behandeln macOS getrennt. Lesen Sie das als Leitlinie für die unterstützte Client-Menge, nicht als dauerhaftes Gesetz über Apple-Geräte. Ein verwaltetes Profil hat mehr Spielraum: Es kann einen Zertifikatstyp ausdrücklich wählen, einschließlich einer ECDSA-Clientidentität, wenn Nutzlast und Gateway beides unterstützen.

Prüfen Sie die iOS-Versionen, die Sie tatsächlich unterstützen, bevor Sie etwas ausrollen. Ein Labor-Telefon mit der neuesten Version beschreibt keine Flotte, die ältere Geräte enthält, und ein Algorithmus, der im Labor funktioniert, kann auf dem ältesten Telefon im Feld dennoch scheitern. Nehmen Sie den Versionsbereich aus der Geräteverwaltung und nicht aus dem Gedächtnis. Umfasst die Flotte mehrere Versionen, testen Sie die älteste zuerst, denn dort ist die manuelle Oberfläche am restriktivsten.

Schritt drei: Profilfelder als getrennte Dinge lesen

Mehrere ähnlich benannte Schlüssel beschreiben unterschiedliche Objekte. Die entfernte Adresse ist der Host, den das Telefon anwählt. Der entfernte Identifikator ist die IKE-Identität, die es vom Gateway erwartet. Der Zertifikatsverweis in der Nutzlast zeigt auf Client-Anmeldedaten, und das Feld für den Zertifikatstyp wählt den Typ für die IKEv2-Maschinenauthentifizierung. Nichts davon ist der Signaturalgorithmus der CA, auch wenn sich die Begriffe überschneiden.

Apples IKEv2-Nutzlastreferenz führt RSA als Standard-Zertifikatstyp mit ausdrücklichen ECDSA-Varianten auf und verknüpft den Ausstellernamen-Schlüssel mit bestimmten Authentifizierungseinstellungen. Lesen Sie diese Beziehungen in der Referenz für die gewählte Methode nach, statt einen Schlüssel aus einer funktionierenden Bereitstellung zu kopieren.

Schritt vier: Gateway-Identität an sein Zertifikat anpassen

Verwenden Sie einen ausdrücklichen Gateway-Namen wie vpn.example.com und tragen Sie einen passenden alternativen Betreffnamen in das Serverzertifikat ein. Die Apple-Anleitung von strongSwan erwartet außerdem die erweiterte Schlüsselverwendung für die Serverauthentifizierung. Die Wahl zwischen RSA und ECDSA ändert daran nichts: Ein Algorithmus kann keine Namensabweichung, keine fehlende EKU und keine unvollständige Kette reparieren.

Die Verteilung des Vertrauensankers ist eine eigene Aufgabe, getrennt vom Behaupten der Identität. Das Telefon braucht eine Zertifikatskette, die es validieren kann, und es muss so konfiguriert werden, dass es den Namen erwartet, den Sie tatsächlich in das Zertifikat gesetzt haben.

Dass eine andere Plattform erfolgreich verbindet, ist ein Beleg für die Validierungsregeln dieser Plattform, keine Erlaubnis, die des Telefons zu lockern. Halten Sie die Prüfungen über alle Clients hinweg gleich, sofern Sie keinen dokumentierten Grund für Abweichungen haben.

Schritt fünf: Client-Identität vom CA-Vertrauen trennen

Ein Client-Zertifikat und sein privater Schlüssel sind nicht dasselbe Objekt wie das CA-Zertifikat, dem das Telefon vertraut. Ein CA-Zertifikat in eine PKCS#12-Identität zu bündeln installiert es nicht automatisch als Vertrauensanker auf jedem unterstützten Gerät, behandeln Sie die Verteilung von Vertrauen also als eigenen Schritt mit eigener Prüfung.

Wenn das Design stattdessen passwortbasiertes EAP verwendet, braucht das Telefon die vorgesehene Kontauthentifizierung plus Servervalidierung. Dieser Weg rechtfertigt nicht, einen gemeinsamen privaten Client-Schlüssel an die ganze Flotte auszuliefern, was ein anderes Design mit einem deutlich schlechteren Fehlermodus ist.

Schließen Sie den Plan mit Blick auf Erneuerung und Widerruf ab: wer die Client-Anmeldedaten neu ausstellt, wie das Profil aktualisiert wird und wie ein verlorenes Telefon abgeschnitten wird. Halten Sie die Profilversion und die Geräteversionen fest, gegen die Sie validiert haben, denn dieser Nachweis macht den nächsten Zertifikatswechsel zu einer Routineänderung.