Android IKEv2 : le certificat utilisateur et l'autorité ne font pas le même travail

Un écran IKEv2 d’Android qui demande à la fois un certificat utilisateur et un certificat d’autorité semble demander deux fois la même chose. Ce n’est pas le cas. IKEv2 authentifie les deux pairs dans les deux sens au sein d’un même échange, et le téléphone joue un rôle différent dans chaque sens : prouver qui il est et décider à quelle passerelle il fait confiance. Le certificat utilisateur répond à la première question, l’autorité de confiance à la seconde, et aucun ne remplace l’autre.

Deux sens d’authentification dans un seul échange

IKEv2 établit un canal de contrôle en deux phases. La première négocie les algorithmes et les clés ; la seconde, IKE_AUTH, transporte une charge AUTH de chaque côté avec son identité. Cette charge est une signature ou un MAC calculé sur l’échange et vérifié contre ce que le destinataire tient déjà pour sûr.

La passerelle se prouve par son propre certificat, que le téléphone valide jusqu’à une racine acceptée en vérifiant que l’identité correspond à la passerelle visée ; le téléphone se prouve par ses identifiants, que la passerelle vérifie auprès de l’autorité qui a émis le certificat client.

Voilà tout le mécanisme. Le certificat utilisateur est une déclaration du téléphone sur lui-même ; le champ d’autorité dit à qui il croira. Un profil qui n’a que l’un ne termine pas l’authentification mutuelle, et réessayer n’y change rien. Les échecs diffèrent même : sans clé utilisateur le téléphone ne peut pas signer, sans ancre de confiance il ne peut pas accepter le certificat de la passerelle.

Ce que demande le générateur de profil Android

Le générateur de profil IKEv2 d’Android expose chaque méthode séparément, et non comme un mode certificat unique. La signature numérique prend un certificat utilisateur, une clé privée et une autorité racine de serveur ; les autres prennent un nom et un mot de passe, ou une clé prépartagée.

Lisez bien cette signature, car elle décrit le mécanisme ci-dessus. Aucun champ de clé privée dans la méthode mot de passe, aucune ancre de confiance dans PSK, parce que ces méthodes prouvent autre chose. Un mot de passe collé dans un champ certificat donne un profil qui échoue à IKE_AUTH avec un message qui ne nomme ni l’un ni l’autre.

Le type de clé privée documenté pour la signature numérique est RSA. Un menu intitulé IPsec ou certificat n’implique pas ECDSA, et un profil bâti sur cette supposition échoue dans l’API de la plateforme avant même le réseau.

Pourquoi un certificat public ne suffit pas

La charge AUTH est une signature sur l’échange faite avec la clé privée du client. Le certificat public permet à la passerelle de vérifier une signature, mais n’apporte rien au téléphone, qui a besoin de la clé pour la produire. N’importer que .crt et laisser la clé derrière est la forme la plus courante de cette erreur.

L’infrastructure de clés d’Android le reflète : choisir une identité client passe par KeyChain, qui exige l’accès à la clé privée correspondante, pas seulement une entrée de certificat. Un paquet d’enrôlement ou une gestion de parc qui installe la paire ensemble est la voie normale ; la copie manuelle d’un fichier l’est rarement.

Les deux éléments ne sont donc pas un lot de certificats et son doublon. L’un est une paire de clés avec laquelle la plateforme doit signer, l’autre une ancre de confiance à laquelle elle se compare. Vérifiez-les comme deux faits distincts : ce profil peut-il signer, et sait-il à qui se fier ?

Les ancres de confiance appartiennent à l’application, pas au téléphone

Une racine installée dans le magasin utilisateur ne fait pas que toutes les applications y croient : depuis Android 7 une application doit l’accepter via sa configuration de sécurité réseau, et avant cette version les autorités installées par l’utilisateur étaient bien plus largement acceptées. La configuration varie, et un client VPN qui gère ses propres éléments de confiance peut ne jamais consulter ce magasin. D’où le même fichier qui marche dans un client et semble ignoré dans un autre.

Deux modèles en découlent. Un profil géré par le système utilise l’installation de certificats de l’appareil ou un enrôlement administrateur, puis référence l’autorité prévue. Un VPN géré par l’application garde ses propres éléments et sa propre importation documentée, parfois séparée des réglages Android. C’est aussi là qu’on répare une chaîne cassée.

Décidez du modèle avant d’importer quoi que ce soit, puis confirmez la sélection de confiance du profil actif. Si les consignes de l’opérateur et le menu du client divergent, le comportement documenté du client l’emporte pour cette installation, mais l’autorité doit toujours venir de l’opérateur par un canal vérifiable. Un nom de fichier ne prouve pas qui l’a émis.

Choisissez le mode, puis les fichiers

Le mode certificat exige une paire de clés client, l’autorité émettrice côté passerelle, une ancre de confiance pour le certificat de la passerelle et une attente sur l’identité qu’il doit porter. Nom et mot de passe remplacent la paire par des identifiants mais gardent l’exigence de confiance. PSK remplace les deux par un secret partagé et change le modèle de confiance au lieu de le simplifier.

Quel que soit votre choix, gardez la validation normale active. Une option sans vérification supprime le contrôle pour lequel le champ d’autorité existe ; elle ne répare pas une ancre absente. Idem pour accepter n’importe quel certificat de serveur parce que la connexion fonctionne sans.

Vérifiez ensuite au bon endroit : importez, connectez une fois, et confirmez dans les détails que l’identité de la passerelle est celle attendue et que le profil annonce la méthode voulue. Une connexion réussie avec la mauvaise méthode est une configuration que vous ne comprenez pas encore, et elle échouera quand l’opérateur durcira une règle.