Certificat IKEv2 sur iPhone : inscription manuelle ou gérée

Choisir RSA parce que l’outil de certificats de la passerelle l’utilise par défaut est une décision prise avant la question qui compte : comment ces iPhone seront-ils inscrits ? Une connexion saisie par l’utilisateur et un profil de configuration fourni par la gestion exposent des réglages différents, et certains choix de certificat n’existent que sur l’une de ces voies. Mettez l’ordre dans le bon sens et le plan de certificat devient court ; trompez-vous et vous émettez un identifiant que le téléphone n’utilisera pas. Traitez les étapes ci-dessous comme une séquence, car chacune réduit les choix disponibles pour la suivante.

Première étape : choisir la voie d’inscription

L’installation manuelle signifie que l’utilisateur saisit l’adresse du serveur, choisit la méthode d’authentification et fournit tout identifiant que l’interface autorise. L’inscription gérée signifie qu’un profil porte l’adresse, les identifiants et une référence à une charge utile d’identifiants. La voie gérée peut exprimer des combinaisons que l’écran manuel ne peut pas, et c’est pourquoi la décision de certificat doit venir après ce choix et non avant.

Les deux voies peuvent authentifier un téléphone. Elles diffèrent par ce que vous pouvez configurer et par qui possède l’identité, alors choisissez-en une délibérément au lieu de mélanger un profil géré avec une saisie manuelle d’identifiants.

Deuxième étape : choisir les algorithmes pour la voie retenue

Pour les iPhone configurés manuellement, les notes d’interopérabilité iOS de strongSwan recommandent un certificat de serveur RSA, car le client manuel peut ne pas accepter un certificat de serveur ECDSA ; ces mêmes notes traitent macOS séparément. Lisez cela comme une recommandation pour l’ensemble de clients pris en charge, non comme une loi permanente sur les appareils Apple. Un profil géré dispose de plus de marge : il peut sélectionner explicitement un type de certificat, y compris une identité client ECDSA, lorsque la charge utile et la passerelle le prennent en charge toutes deux.

Validez les versions d’iOS que vous prenez réellement en charge avant de déployer quoi que ce soit. Un téléphone de laboratoire sur la version la plus récente ne décrit pas un parc qui comprend des appareils plus anciens, et un algorithme qui fonctionne au laboratoire peut malgré tout échouer sur le téléphone le plus ancien du terrain. Prenez la plage de versions dans la gestion des appareils, pas dans votre mémoire. Si le parc couvre plusieurs versions, testez d’abord la plus ancienne, car c’est là que l’interface manuelle est la plus restrictive.

Troisième étape : lire les champs du profil comme des objets distincts

Plusieurs clés aux noms similaires décrivent des objets différents. L’adresse distante est l’hôte que le téléphone appelle. L’identifiant distant est l’identité IKE qu’il attend de la passerelle. La référence au certificat de la charge utile désigne un identifiant client, et le champ de type de certificat choisit le type utilisé pour l’authentification machine IKEv2. Aucun de ces éléments n’est l’algorithme de signature de la CA, même si les mots se recoupent.

La référence de charge utile IKEv2 d’Apple liste RSA comme type de certificat par défaut avec des variantes ECDSA explicites, et elle lie la clé de nom d’émetteur à des réglages d’authentification particuliers. Lisez ces relations dans la référence de la méthode choisie au lieu de copier une clé d’un déploiement qui fonctionne.

Quatrième étape : faire correspondre l’identité de la passerelle à son certificat

Utilisez un nom de passerelle explicite, par exemple vpn.example.com et placez un nom alternatif de sujet correspondant dans le certificat du serveur. Le guide Apple de strongSwan attend aussi l’usage étendu de clé pour l’authentification du serveur. Choisir RSA ou ECDSA ne change rien à cela : un algorithme ne peut pas réparer une incohérence de nom, une EKU manquante ou une chaîne incomplète.

Distribuer l’ancre de confiance est une tâche distincte de l’affirmation de l’identité. Le téléphone a besoin d’une chaîne de certificats qu’il peut valider, et il doit être configuré pour attendre le nom que vous avez réellement placé dans le certificat.

Qu’une autre plateforme se connecte avec succès est une preuve des règles de validation de cette plateforme, pas une autorisation d’assouplir celles du téléphone. Gardez les contrôles identiques d’un client à l’autre, sauf si vous avez une raison documentée de différer.

Cinquième étape : séparer l’identité client de la confiance envers la CA

Un certificat client et sa clé privée ne sont pas le même objet que le certificat de CA auquel le téléphone fait confiance. Regrouper un certificat de CA dans une identité PKCS#12 ne l’installe pas automatiquement comme ancre de confiance sur chaque appareil pris en charge, alors traitez la distribution de confiance comme une étape à part avec sa propre vérification.

Si la conception utilise plutôt EAP par mot de passe, le téléphone a besoin de l’authentification de compte prévue plus la validation du serveur. Cette voie ne justifie pas d’envoyer une clé privée client partagée à tout le parc, ce qui est une conception différente avec un mode de défaillance bien pire.

Terminez le plan en gardant le renouvellement et la révocation en tête : qui réémet l’identifiant client, comment le profil est mis à jour et comment un téléphone perdu est coupé. Enregistrez la version du profil et les versions d’appareil avec lesquelles vous avez validé, car ce registre est ce qui fait du prochain renouvellement de certificat un changement de routine.