Android IKEv2: Nutzerzertifikat und CA erfüllen verschiedene Aufgaben
Das eine Feld belegt, wer das Telefon ist, das andere entscheidet, welchem Gateway zu trauen ist. Das IKEv2-Profil in Android hält beides getrennt.
Ein IKEv2-Bildschirm in Android, der zugleich ein Nutzerzertifikat und ein CA-Zertifikat verlangt, sieht aus, als wolle er dasselbe zweimal. Das stimmt nicht. IKEv2 authentifiziert beide Seiten in beide Richtungen innerhalb eines Austauschs, und das Telefon spielt in jeder Richtung eine andere Rolle: Es muss beweisen, wer es ist, und entscheiden, welchem Gateway es glaubt. Das Nutzerzertifikat beantwortet die erste Frage, die vertrauenswürdige CA die zweite, und keines ersetzt das andere.
Zwei Richtungen der Authentifizierung in einem Austausch
IKEv2 baut einen Steuerkanal in zwei Phasen auf. Die erste handelt Algorithmen und Schlüssel aus; die zweite, IKE_AUTH, trägt je eine AUTH-Nutzlast von jeder Seite samt deren Identität. Die Nutzlast ist eine Signatur oder ein MAC über den Austausch und wird gegen etwas geprüft, dem der Empfänger bereits vertraut.
Das Gateway weist sich mit seinem eigenen Zertifikat aus; das Telefon prüft die Kette bis zu einer Wurzel, der es vertraut, und ob die Identität im Zertifikat zu dem Gateway passt, das es erreichen wollte. Das Telefon weist sich mit seinen Zugangsdaten aus, und das Gateway prüft sie gegen die CA, die das Client-Zertifikat ausgestellt hat.
Das ist der ganze Mechanismus hinter den beiden Feldern. Das Nutzerzertifikat ist eine Aussage des Telefons über sich selbst; das CA-Feld ist eine Aussage darüber, wem das Telefon glauben wird. Ein Profil mit nur einem von beiden kann die gegenseitige Authentifizierung nicht abschließen, und Wiederholen ändert daran nichts. Selbst die Fehler sehen anders aus: Ohne Nutzerschlüssel kann das Telefon gar nicht signieren, ohne Vertrauensanker das Gateway-Zertifikat nicht annehmen.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Was der Profil-Generator von Android verlangt
Der IKEv2-Profil-Generator von Android bietet jede Authentifizierungsmethode einzeln an, nicht als einen Zertifikatsmodus. Die Digital-Signatur-Methode nimmt ein Nutzerzertifikat, einen privaten Schlüssel und eine Server-Wurzel-CA; die anderen nehmen Benutzername und Passwort oder einen vorab geteilten Schlüssel.
Lesen Sie diese Signatur genau, denn sie beschreibt den Mechanismus oben. In der Benutzername-Passwort-Methode gibt es kein Feld für den privaten Schlüssel, im PSK-Verfahren keines für den Vertrauensanker des Gateways, weil diese Verfahren Verschiedenes belegen. Ein Passwort in einem Zertifikatsfeld ergibt ein Profil, das bei IKE_AUTH scheitert, mit einer Meldung, die keines von beiden nennt.
Der dokumentierte Typ des privaten Schlüssels für die Digital-Signatur-Methode ist RSA. Ein Menü mit der Bezeichnung IPsec oder Zertifikat bedeutet keine ECDSA-Unterstützung, und ein auf dieser Annahme gebautes Profil scheitert an der Plattform-API, bevor das Netzwerk überhaupt beteiligt ist.
Warum ein öffentliches Nutzerzertifikat allein nicht reicht
Die AUTH-Nutzlast ist eine Signatur über den Austausch, erzeugt mit dem privaten Schlüssel des Clients. Das öffentliche Zertifikat erlaubt dem Gateway, eine Signatur zu prüfen, hilft dem Telefon aber nicht, denn es braucht den Schlüssel, um eine zu erzeugen. Nur .crt zu importieren und den Schlüssel zurückzulassen ist die häufigste Form dieses Fehlers.
Die Schlüsselinfrastruktur von Android spiegelt das. Die Auswahl einer Client-Identität läuft über KeyChain, das Zugriff auf den zugehörigen privaten Schlüssel verlangt, nicht nur einen Zertifikatseintrag. Ein Registrierungspaket oder eine Geräteverwaltung, die das Paar gemeinsam installiert, ist der übliche Weg zu einer brauchbaren Identität; das Kopieren einer Datei von Hand ist es meist nicht.
Die beiden Elemente im Profil sind also kein Zertifikatsbündel und dessen Kopie. Das eine ist ein Schlüsselpaar, mit dem die Plattform signieren können muss, das andere ein Vertrauensanker, gegen den sie vergleicht. Prüfen Sie beides als zwei getrennte Fakten: Kann dieses Profil signieren, und weiß es, wem es trauen soll?
Vertrauensanker gehören zu einer Anwendung, nicht zum Telefon
Eine im Benutzerspeicher installierte Wurzel macht nicht jede Android-Anwendung misstrauisch: Seit Android 7 muss eine App über ihre Netzwerksicherheitskonfiguration zustimmen, und davor wurden vom Nutzer installierte CAs deutlich breiter akzeptiert. Die Vertrauenskonfiguration kann sich je App unterscheiden, und ein VPN-Client, der sein Vertrauensmaterial selbst verwaltet, schaut vielleicht nie in den Benutzerspeicher. Deshalb kann dieselbe CA-Datei in einem Client funktionieren und in einem anderen ignoriert wirken.
Daraus folgen zwei Eigentumsmodelle. Ein systemverwaltetes Profil nutzt die Zertifikatinstallation des Geräts oder die Administratorregistrierung und verweist dann auf die vorgesehene CA. Ein app-verwaltetes VPN hält eigenes Vertrauensmaterial und einen eigenen dokumentierten Import, der völlig getrennt vom Android-Einstellungsbildschirm sein kann. Dort repariert man auch eine gebrochene Kette.
Entscheiden Sie vor dem Import, in welchem Modell Sie sind, und bestätigen Sie danach die Vertrauensauswahl des aktiven Profils. Widersprechen sich Betreiberanweisung und Client-Menü, gewinnt für diese Installation das dokumentierte Verhalten des Clients, aber die CA muss weiterhin über einen prüfbaren Kanal vom Betreiber kommen. Ein Dateiname ist kein Beleg dafür, wer sie ausgestellt hat.
Erst der Modus, dann die Dateien
Der Zertifikatsmodus braucht ein Client-Schlüsselpaar, die ausstellende CA auf der Gateway-Seite, einen Vertrauensanker für das Gateway-Zertifikat und eine Erwartung, welche Identität dieses Zertifikat tragen muss. Benutzername und Passwort ersetzen das Schlüsselpaar durch Zugangsdaten, behalten aber die Vertrauensanforderung an das Gateway. PSK ersetzt beides durch ein gemeinsames Geheimnis und verändert das Vertrauensmodell, statt es zu vereinfachen.
Was immer Sie wählen, lassen Sie die normale Validierung aktiv. Eine Option ohne Prüfung entfernt genau die Kontrolle, für die das CA-Feld existiert; einen fehlenden Vertrauensanker repariert sie nicht. Dasselbe gilt für das Akzeptieren jedes Serverzertifikats, weil die Verbindung auch ohne funktioniert.
Prüfen Sie dann an der richtigen Stelle: Material importieren, einmal verbinden und in den Verbindungsdetails bestätigen, dass die Gateway-Identität die erwartete ist und das Profil die beabsichtigte Methode meldet. Eine erfolgreiche Verbindung mit der falschen Methode ist eine Konfiguration, die Sie noch nicht verstehen, und sie scheitert, sobald der Betreiber eine Richtlinie verschärft.