Mac IKEv2 ECDSA : quel type de certificat revient au client ?

Sur macOS, le choix ECDSA dans un réglage client IKEv2 répond à une question étroite : quel certificat prouve l'identité du Mac. Il ne décrit ni le certificat de la passerelle, ni la signature ayant émis le certificat client, ni la proposition de chiffrement du tunnel. Traiter ces quatre rôles comme une seule question de compatibilité, c'est ainsi qu'un réglage local correct se retrouve accusé d'un décalage côté serveur. La décision est petite, mais les preuves qui la fondent doivent être précises.

Le champ nomme un certificat : l'identité locale

L'API Network Extension d'Apple expose un type de certificat pour l'identifiant du client, dont NEVPNIKEv2CertificateType.ECDSA256, documenté comme le type de certificat ECDSA p-256. La propriété s'applique au certificat fourni via identityReference ou identityData.

Cela signifie que la décision porte sur le certificat que le Mac présente, ainsi que sur la clé privée associée. Choisissez le type qui correspond à la clé publique de ce certificat feuille et fournissez l'identité par le mécanisme pris en charge. Si le Mac n'a pas de clé privée utilisable pour l'identité, le choix du type ne peut pas sauver la connexion.

Les profils gérés prennent la même décision via CertificateType de la charge utile IKEv2, associé à une référence de certificat comme PayloadCertificateUUID. Ces champs ont des prérequis et un schéma pour la version du système d'exploitation cible ; une valeur de type nue copiée dans un profil n'est pas installable, et une fenêtre de réglages peut ne pas exposer toutes les options de l'API. Vérifiez les prérequis de la charge utile pour cette version avant le déploiement.

Décidez par rôle, pas par l'étiquette du certificat

Lisez le champ que vous êtes sur le point de modifier et demandez à quel certificat il renvoie. Les étiquettes d'un visualiseur de certificats mélangent le sujet, l'émetteur et l'algorithme de signature, et une seule d'entre elles relève du choix de l'identité du client.

Si le visualiseur de certificats montre une signature ECDSA de la CA, cela décrit la clé de signature de l'émetteur. La clé propre au client peut toujours être RSA, et le champ de type doit suivre la clé du client plutôt que la ligne de signature. Cette seule confusion explique de nombreux rapports « ECDSA est configuré mais la connexion échoue ». Comparez le type de clé de la feuille avec le type sélectionné dans le profil avant de changer quoi que ce soit.

La décision devient plus simple une fois la feuille identifiée : ECDSA256 pour une clé client p-256, un autre type pris en charge pour une clé différente. Si le certificat client et sa clé ne correspondent pas, corrigez cette paire avant de modifier le profil VPN.

Le certificat de la passerelle est une décision distincte

La passerelle présente son propre certificat et le Mac le valide par rapport à une ancre de confiance et à un nom attendu. Que ce certificat utilise ECDSA, RSA ou un autre type de clé est une propriété du serveur, non du réglage d'identité du client.

La prise en charge locale d'un certificat client ECDSA ne prouve pas que tous les certificats de passerelle, courbes ou configurations d'authentification serveur interopéreront. Vérifiez l'identité du serveur, sa chaîne et sa méthode d'authentification IKE comme des entrées distinctes, et testez avec le profil qui sera réellement déployé.

Si le certificat de la passerelle est le problème, le symptôme apparaît généralement lors de la validation du pair, pas au choix de l'identité. Lisez l'étape d'échec avant de changer le type du client, car un échec de confiance et un décalage de clé client ne partagent pas la même correction.

La signature de l'émetteur et le groupe d'accord de clés ne sont pas le type du client

X.509 conserve la clé publique du sujet et la signature de l'émetteur dans des champs différents. Les informations de clé publique du sujet décrivent la clé du certificat ; l'algorithme de signature décrit la clé de la CA et l'opération de signature. Seule la première correspond au réglage du type de certificat.

Les propositions IKE et Child SA sont un autre axe. Un type de certificat ECDSA n'est pas un choix de chiffrement ESP, et changer le groupe d'accord de clés ne sélectionne pas de type de certificat. Un profil peut avoir des propositions valides et le mauvais type d'identité, ou le bon type d'identité et une proposition que le pair rejette.

Gardez les trois lignes séparées dans le journal des modifications : certificat et clé d'identité, entrées de confiance de la passerelle et algorithmes des propositions. Les fusionner dans une seule note « réglages crypto » rend l'échec suivant impossible à attribuer.

Vérifiez la décision avec les champs que vous avez configurés

Vérifiez l'identité à laquelle le profil fait réellement référence, puis confirmez que le certificat de cette référence possède la clé publique attendue et une clé privée utilisable. Le type affiché dans l'interface, le certificat référencé et la clé sur l'appareil doivent concorder.

Confirmez ensuite les entrées de la passerelle : le nom de serveur attendu, l'ancre de confiance et la méthode d'authentification IKE. Enfin, connectez-vous et lisez où la poignée de main s'arrête. Un échec avant l'échange d'identité écarte ce réglage ; un échec à la validation du pair pointe vers le côté passerelle.

Notez le type choisi, la référence d'identité et le sujet du certificat de la passerelle dans les notes de déploiement. La prochaine mise à jour du profil peut changer l'un d'eux, et trois valeurs nommées se comparent plus vite qu'une capture d'écran d'un panneau de réglages.