Connexion VPN par certificat sur Mac : identité, usage de la clé ou confiance en la passerelle ?

Les connexions VPN fondées sur un certificat demandent au Mac quelque chose de plus étroit qu’un mot de passe : utiliser cette clé privée précise, dans ce contexte d’exécution, pour prouver une identité à cette passerelle. Lorsque cela échoue, le message ne décrit généralement que la dernière chose qui a mal tourné, qui est rarement la cause. Parcourir les trois décisions dans l’ordre où le système les prend garde le diagnostic honnête et empêche qu’un problème local de permissions soit traité comme un échec de validation de chaîne.

Suivez la connexion dans l’ordre que suit le Mac

D’abord le client choisit une identité : un certificat associé à une clé privée utilisable, disponible via le magasin pris en charge ou le fournisseur d’identifiants. Ensuite le composant VPN demande à effectuer une opération cryptographique avec cette clé, et le modèle d’autorisation local répond. Ce n’est qu’après la réussite des deux que la poignée de main distante a lieu, où le Mac évalue la passerelle et la passerelle évalue la preuve du client.

Lisez le tableau de haut en bas et arrêtez-vous à la première ligne qui échoue. Tout ce qui se trouve sous un échec est non prouvé, et c’est pourquoi « le certificat n’est pas approuvé » est une conclusion aussi courante que peu fiable.

Ce que couvre réellement l’autorisation locale

Dans le modèle du trousseau macOS, les éléments protégés portent des règles d’accès propres à l’opération et une liste d’applications approuvées. La signature avec une clé privée est l’une de ces opérations, et les règles s’appliquent à l’exécutable qui l’effectue, non au certificat en tant que document. La référence d’Apple sur le contrôle d’accès trace aussi une frontière entre ce modèle et le trousseau iCloud ainsi que les arrangements de groupes d’accès, si bien qu’un conseil écrit pour l’un ne se transpose pas à l’autre.

Deux conséquences en découlent. La visibilité d’un certificat public dans une liste ne prouve pas que le composant d’arrière-plan du VPN puisse atteindre cette clé. Et une autorisation accordée à une application de façade ne dit rien d’un assistant ou d’une extension réseau séparés, car ce sont des codes différents avec des identités différentes.

Identifiez l’implémentation réelle et son mécanisme pris en charge de partage d’identifiants plutôt que de copier un chemin d’exécutable depuis un ancien client. Confirmez quelle identité le système proposera d’abord :

security find-identity -v -p ssl-client

Lire le code errSecInteractionNotAllowed

Cet état signale une interaction non autorisée avec le serveur de sécurité et ne dit rien des chaînes de certificats. Lisez-le avec l’opération qui l’a produit : une demande de signature émise depuis un contexte qui ne peut afficher d’invite échouera de cette manière même lorsque la clé et le certificat sont parfaitement valides. Le point de départ est l’opération qui l’a journalisé, non le magasin de certificats. Tout changement apporté aux ancres de confiance laissera l’erreur exactement où elle était.

Traitez donc le code comme une raison d’examiner le contexte d’exécution et l’autorisation. Le traiter comme la preuve que l’AC de la passerelle n’est pas approuvée vous envoie vers la mauvaise moitié du problème, et la modification que vous y ferez n’affectera pas du tout l’erreur.

Réparez étroitement, pas largement

Commencez par les instructions d’enrôlement ou d’importation du propriétaire de la connexion. Notez la version du client, la portée du profil, l’identité sélectionnée et la première erreur locale pertinente, car ces quatre faits sont ce dont un transfert vers le support a besoin et dont dépend une comparaison ultérieure. Un profil géré ou une identité adossée au matériel peut exiger que l’administrateur ou le fournisseur répare le transfert, et aucun clic local ne remplace cela.

Là où le produit attend une approbation de l’utilisateur, confirmez quel composant la demande et n’approuvez que cet accès via le flux pris en charge. Là où le composant n’a aucun moyen de faire apparaître une invite dans le contexte où il s’exécute, le provisionnement doit suivre la voie documentée par le fournisseur, non une boîte de dialogue extorquée à une autre fenêtre de terminal.

Dans les anciens conseils, deux changements sont regroupés, et tous deux sont trop larges. Accorder à chaque application l’accès à la clé privée élargit l’usage local de la clé bien au-delà de l’exigence, et régler le certificat sur Toujours approuver modifie l’évaluation des certificats pour tout ce qui se trouve sur la machine. Aucun des deux n’exprime « cette implémentation VPN approuvée, avec cette identité prévue ».

Vérifiez localement avant de lire la passerelle

Après une réparation, confirmez que l’opération locale réussit avant d’interpréter toute réponse de l’autre côté. Si la signature fonctionne désormais, un rejet ultérieur de nom, de chaîne ou d’admission du client est un résultat nouveau et non une récidive, et il relève d’une autre décision avec un autre responsable.

Un transfert utile nomme laquelle des trois décisions a échoué et s’arrête là. Il n’inclut jamais la clé privée et ne réinitialise jamais des éléments de trousseau sans rapport en espérant qu’une remise à zéro aide. Prenez ces deux habitudes avant l’incident plutôt que pendant, quand la tentation de tout essayer à la fois est la plus forte. Un ticket qui dit « nous avons reconstruit le trousseau » n’apprend presque rien au lecteur suivant sur la panne d’origine.