Certificat VPN Mac : quel compte la passerelle voit-elle ?

Le profil affiche votre nom, le libellé visible du certificat dit autre chose, et le journal de la passerelle enregistre un troisième identifiant. Aucun des trois ne ment, et c’est bien là le problème : trois champs différents sont lus comme s’ils répondaient à une seule question. La connexion présente un justificatif, un identifiant IKEv2 et un compte, et la passerelle décide lequel autorise quoi.

Trois identités dans une seule connexion

Le nom visible du profil est un libellé destiné aux humains. Il sélectionne une connexion et rien d’autre. Le certificat est un justificatif, et le fait qu’il puisse prouver quelque chose dépend de la possession, par le client, de la clé privée correspondante. Le champ de compte est une affirmation sur un principal, et le serveur est libre de le mapper vers une autre identité locale.

Quand l’authentification échoue, demandez auquel des trois l’erreur se rapporte. Un justificatif rejeté, un identifiant inconnu et un compte désactivé produisent des messages différents, et les traiter comme un unique « problème de certificat » vous envoie vers la mauvaise console.

Lisez les champs natifs selon leur rôle

Dans une configuration IKEv2 native gérée, la référence de charge utile d’Apple sépare les valeurs, et la méthode d’authentification détermine quelle combinaison est requise :

Un certificat et une connexion EAP peuvent avoir des rôles distincts dans la même connexion. Ne forcez pas chaque champ à contenir le même texte simplement parce que l’un d’eux le fait, et ne supposez pas que modifier l’un écrase les autres. Une application VPN tierce peut exposer un modèle totalement différent ; utilisez sa sélection d’identité documentée au lieu d’y transposer les noms de champs natifs.

Un certificat de serveur n’est pas une identité client

Le certificat qui valide la passerelle est une ancre de confiance. Il prouve que vous avez atteint le serveur attendu. Une identité client est un autre objet : elle inclut l’accès à la clé privée qui prouve que la partie qui se connecte est bien celle qu’elle prétend être. Renommer un compte visible ne peut transformer l’une en l’autre.

C’est ici qu’une correction bien intentionnée tourne mal. Importer le certificat CA de la passerelle dans le magasin du client ne fait rien pour l’authentification du client, et étiqueter cette entrée avec le nom de l’utilisateur n’en fait pas une identité utilisateur. Les deux objets vivent dans des parties différentes du profil et répondent à des questions différentes.

Suivez le principal jusqu’au mappage de la passerelle

Confirmez à quoi le justificatif a été délivré : cet utilisateur, cet appareil ou un rôle partagé. Le compte de connexion du Mac n’est pas automatiquement ce principal, et un certificat copié depuis une autre machine conserve l’identité de la machine pour laquelle il a été délivré.

Comparez ensuite le justificatif réel, pas le libellé. L’émetteur, le numéro de série et l’empreinte vous permettent, à vous et à l’administrateur, de confirmer que vous parlez du même objet. Les noms affichés sont modifiables et souvent dupliqués, ce qui en fait le pire identifiant possible pendant un incident.

La dernière étape se joue sur la passerelle. Demandez à son propriétaire de corréler une connexion avec les identifiants présentés et avec la règle de mappage de comptes qui les a consommés. Un libellé côté client ne peut pas établir ce que le serveur a décidé, et une règle qui mappe un certificat vers un compte désactivé échouera alors que tous les champs côté client semblent corrects.

Réparez la couche qui possède le décalage

Si le profil pointe vers le mauvais justificatif, corrigez sa référence ou sa sélection. Si le justificatif appartient à un autre principal, passez par le réenrôlement de l’émetteur plutôt que de modifier des libellés. Si la passerelle associe un justificatif valide au mauvais compte, son propriétaire de politique doit corriger le mappage. Ce sont trois changements différents avec trois approbateurs différents.

Le renouvellement mérite le même soin. Remplacer le certificat, renommer son libellé visible et déplacer une personne entre systèmes de comptes n’affectent pas nécessairement le mappage de la même manière. Notez lequel des trois vous avez changé, car la prochaine panne semblera identique côté client et différente dans le journal de la passerelle.

Ne partagez que les identifiants publics minimaux dont le support a besoin. Une clé privée ou un paquet d’identité complet ne fait jamais partie de cet échange, quelle que soit la commodité du diagnostic.