codesign errSecInternalComponent : réparer la signature à distance en 2026

Ce guide s’adresse aux développeurs indépendants qui se connectent en SSH à un Mac distant et constatent un échec de signature alors que l’Archive fonctionne dans l’interface graphique.

Il convient également aux petites équipes qui utilisent un script, fastlane ou un exécuteur autohébergé pour signer sans surveillance, ainsi qu’aux personnes ayant migré leur environnement et ne parvenant toujours pas à utiliser une identité Apple Distribution ou Developer ID.

Dernière mise à jour : 25 août 2026. Les points relatifs aux certificats, au Keychain, aux profils et aux réglages de compilation ont été revérifiés à partir de la documentation Apple sur les certificats de signature, de la note technique TN3161 sur les certificats de signature et des références Apple liées au code signing.

Une erreur de signature devient beaucoup plus difficile à interpréter après un nettoyage précipité. Avant de supprimer une identité, de réinitialiser un trousseau ou de révoquer un certificat, conservez une copie des éléments suivants, en les anonymisant :

• le nom de l’utilisateur macOS qui exécute réellement codesign ;
• le type de session : terminal graphique, SSH, tâche planifiée ou exécuteur de CI ;
• le chemin du Keychain utilisé par le script ;
• la commande exacte, sans mot de passe, jeton, identifiant d’équipe ni chemin confidentiel ;
• le stade d’échec : codesign, xcodebuild, Archive, export ou téléversement ;
• le nom de l’identité demandée, sans publier son empreinte complète ;
• le message complet de l’outil, avec les noms de projet et de produit remplacés par des valeurs génériques.

Un échec pendant codesign n’a pas la même portée qu’un échec lors de l’exportation d’un Archive. Dans le premier cas, l’accès à l’identité ou à la clé est immédiatement suspect ; dans le second, il faut aussi examiner le profil de provisionnement, les entitlements et les réglages de distribution. Les ressources Apple consacrées au dépannage du code signing permettent de replacer errSecInternalComponent dans cette catégorie d’erreurs générales, sans l’attribuer automatiquement à une version précise de Xcode ou de macOS.

Attention : ne publiez jamais un trousseau, une clé privée, un fichier de profil complet ou la valeur d’un secret dans un rapport de CI. Un journal utile décrit le contexte et les empreintes nécessaires, mais ne transforme pas l’environnement de signature en copie exploitable.

La première expérience doit être volontairement étroite : même utilisateur, même artefact, même identité et même commande minimale. Si le terminal graphique et SSH ne testent pas exactement le même produit, la comparaison ne permet pas de distinguer un problème de session d’un problème d’identité.

Dans le terminal graphique, relevez d’abord :

id -un
printf '%s\n' "$HOME"
security list-keychains
security default-keychain
security find-identity -v -p codesigning

Depuis SSH, exécutez les mêmes commandes avec le compte de construction, sans sudo, puis comparez les résultats. Les chemins de trousseaux, le répertoire personnel et la liste d’identités doivent être interprétés dans le contexte du compte qui lance la compilation, pas dans celui d’un administrateur utilisé pour préparer la machine.

Pour le test, utilisez un artefact de démonstration non destiné à la publication et une identité déjà approuvée par l’équipe. Le but n’est pas encore de produire une application distribuable, mais de déterminer si la session distante peut accéder à une identité de signature.

Trois observations orientent immédiatement la suite :

• si l’identité n’apparaît pas dans SSH, inspectez le Keychain et le compte utilisé ;
• si elle apparaît dans les deux sessions mais que seul SSH échoue, examinez le verrouillage et l’autorisation non interactive ;
• si les deux sessions échouent, cessez de traiter SSH comme cause principale et vérifiez la paire certificat-clé, le profil et la chaîne de confiance.

Cette comparaison explique pourquoi un codesign qui « fonctionne dans le terminal » peut échouer sur le même Mac par SSH : le programme n’est pas nécessairement exécuté avec le même trousseau ouvert, les mêmes variables d’environnement ou les mêmes droits d’accès aux clés.

Un certificat public visible dans un Keychain ne constitue pas, à lui seul, une identité de signature utilisable. La signature exige une relation exploitable entre le certificat, sa clé privée correspondante et les autorisations permettant à l’outil de demander cette clé.

Commencez par l’inventaire non destructif :

security find-identity -v -p codesigning
security find-certificate -a -p "$HOME/Library/Keychains/BUILD.keychain-db"
security find-key -a "$HOME/Library/Keychains/BUILD.keychain-db"

Remplacez BUILD par un nom local neutre. Le chemin réel doit être celui du compte de construction. Une identité dont le nom paraît correct peut toutefois être inutilisable dans plusieurs situations :

• le certificat a été importé sans sa clé privée ;
• le certificat et la clé privée se trouvent dans des Keychain différents ;
• plusieurs certificats portent un nom proche, dont un est expiré ou associé à une autre clé ;
• l’identité appartient à un autre compte macOS ;
• la clé est présente mais verrouillée ou protégée par une autorisation interactive ;
• le certificat est valide, mais la chaîne nécessaire à sa validation n’est pas disponible.

La documentation Apple sur la structure des certificats de code signing sert de référence pour distinguer le certificat et les éléments cryptographiques qui l’accompagnent. Dans une migration, l’exportation du certificat public ne suffit donc pas : la clé privée doit être transférée par un mécanisme sécurisé, puis rendue accessible au compte qui construit.

Pour une identité Apple Distribution, contrôlez également que le profil de provisionnement correspond à l’identifiant d’application, à l’équipe et au type de distribution attendus. Apple décrit la création d’un profil App Store de provisionnement ; cette étape ne remplace pas la vérification de la clé privée, mais elle évite de confondre une erreur d’identité avec une incompatibilité de profil.

Lorsque la signature graphique réussit et que SSH échoue, le correctif le plus probable concerne le contexte d’accès. Le script doit ouvrir le Keychain réellement utilisé, le déverrouiller avec un secret fourni par le gestionnaire de secrets de la chaîne de construction, puis autoriser l’outil de signature selon une politique minimale.

Un exemple générique, à adapter à l’environnement cible, peut ressembler à ceci :

KEYCHAIN="$HOME/Library/Keychains/BUILD.keychain-db"

security list-keychains -s "$KEYCHAIN"
security default-keychain -s "$KEYCHAIN"
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
security find-identity -v -p codesigning "$KEYCHAIN"

Les variables doivent être injectées de manière éphémère ; elles ne doivent pas être écrites dans le dépôt, dans une commande affichée par la CI ou dans un journal conservé sans protection. L’étape d’autorisation doit ensuite viser les binaires strictement nécessaires, selon la politique retenue par l’équipe et la version de macOS. La documentation Apple sur les Keychain constitue la base à consulter avant de modifier les règles d’accès.

Le script doit s’exécuter sous le compte qui lancera xcodebuild, fastlane ou codesign. Employer sudo pour « faire fonctionner » la commande masque souvent un changement d’utilisateur et de répertoire personnel ; cela peut faire croire que le certificat est réparé alors que le processus utilise simplement un autre Keychain.

À éviter dans une réparation normale :

• désactiver durablement les mécanismes de sécurité du système ;
• rendre le mot de passe du Keychain permanent dans un fichier texte ;
• autoriser indistinctement tous les programmes à utiliser toutes les clés ;
• supprimer toutes les identités avant d’avoir exporté une sauvegarde sécurisée ;
• révoquer un certificat partagé par une version déjà publiée sans plan de remplacement.

Si plusieurs identités portent le même nom, documentez d’abord celle qui doit rester active. La suppression d’un doublon peut modifier une chaîne de publication existante ; elle ne doit être effectuée qu’après sauvegarde, identification de l’impact et possibilité de retour arrière.

Une commande codesign minimale qui réussit indique seulement que l’outil a pu signer l’artefact testé. Elle ne prouve pas que l’Archive complet sera exportable ni que l’application pourra être téléversée.

Poursuivez avec un projet de test désensibilisé qui reproduit les caractéristiques importantes du produit réel :

• application principale et composants imbriqués ;
• entitlements réellement utilisés ;
• profil de provisionnement adapté ;
• identité Apple Distribution pour une distribution iOS ;
• réglages de compilation identiques à ceux du pipeline ;
• étape d’exportation, puis validation du paquet produit.

Les réglages de signature, d’équipe et de profils peuvent être influencés par les paramètres de construction ; consultez la référence Apple des Build Settings de Xcode plutôt que de déduire le comportement à partir du seul nom affiché dans Xcode.

À ce stade, les messages donnent des pistes différentes :

• « clé privée manquante » renvoie à l’importation de l’identité numérique ;
• « identité invalide » impose de contrôler certificat, équipe et expiration ;
• une chaîne impossible à établir oriente vers les certificats intermédiaires ou la validation de confiance ;
• un profil incompatible oriente vers l’identifiant d’application, les entitlements ou le type de distribution ;
• un succès en graphique mais un échec en SSH maintient l’hypothèse Keychain et autorisation au premier plan.

La modification d’un profil ne doit pas être confondue avec la régénération d’un certificat. Les profils peuvent être modifiés, téléchargés ou supprimés depuis l’aide du compte développeur, tandis que la paire certificat-clé relève d’un autre niveau de la chaîne.

La réparation n’est terminée que lorsque le pipeline passe dans les états qui ont provoqué l’incident. Une session graphique laissée ouverte ne constitue pas une preuve d’automatisation fiable.

Utilisez cette liste de contrôle après le premier succès :

• [ ] Le compte de construction est explicitement identifié et ne dépend pas d’un compte administrateur.
• [ ] Le script sélectionne le Keychain attendu au lieu de compter sur un état hérité.
• [ ] Le Keychain est déverrouillé avant la première opération de signature.
• [ ] La présence du certificat et de la clé privée est vérifiée sans afficher de secret.
• [ ] L’identité demandée est déterminée sans ambiguïté malgré les doublons éventuels.
• [ ] Le profil de provisionnement correspond à l’application, à l’équipe et au mode de distribution.
• [ ] Un Archive réel est produit depuis SSH, et pas uniquement une commande codesign.
• [ ] L’exportation et la validation du paquet sont exécutées dans le même contexte.
• [ ] Le test est répété après fermeture de la session graphique.
• [ ] Une nouvelle connexion SSH reproduit l’initialisation du Keychain.
• [ ] Un échec contrôlé peut être relancé sans intervention sur une boîte de dialogue.
• [ ] Un redémarrage du Mac ne détruit pas les étapes documentées d’initialisation.
• [ ] Les secrets peuvent être révoqués ou remplacés sans modifier le dépôt.
• [ ] Le journal d’acceptation indique la date, le compte, le profil et le résultat, sans donnée sensible.

Cette séquence permet de décider rationnellement. Si la signature reste fonctionnelle après fermeture de session, reconnexion et redémarrage, le Mac peut rester dans l’environnement actuel avec une procédure documentée. Si le pipeline exige toujours une fenêtre graphique ou une autorisation manuelle, il faut traiter cette dépendance comme un défaut d’exploitation, pas comme une simple nuisance.

La recréation d’un certificat Apple Distribution devient pertinente seulement lorsqu’une preuve l’impose : clé privée définitivement absente, identité importée de façon incomplète, certificat expiré, doublon impossible à maîtriser ou chaîne de confiance irrécupérable dans le cadre autorisé par l’équipe.

Avant toute rotation, vérifiez l’impact sur les autres machines, les branches de publication et les versions actuellement maintenues. Préparez une nouvelle identité dans un environnement contrôlé, validez-la avec un Archive de test, puis planifiez le remplacement des secrets et des profils. Révoquer trop tôt l’ancien certificat peut interrompre un autre pipeline qui n’a pas encore reçu la nouvelle clé.

Pour les équipes qui ne veulent pas maintenir elles-mêmes l’état d’un Mac de construction, un environnement distant avec accès administrateur complet et disponibilité continue peut être évalué. NUKCLOUD présente son service de Mac distant comme une option à comparer avec l’achat d’une machine réservée à la signature ; cette voie reste à juger selon la durée d’utilisation, les exigences de matériel physique et la politique de conservation des clés.

Pourquoi la commande réussit-elle dans un terminal mais échoue-t-elle en SSH ?

Le terminal graphique et SSH peuvent utiliser des utilisateurs, des répertoires personnels et des Keychain différents, même sur le même Mac. Comparez id -un, security list-keychains, le trousseau par défaut et les identités visibles, puis testez le même artefact. Si seul SSH échoue, corrigez l’initialisation et l’autorisation du Keychain avant de toucher aux certificats.

Faut-il régénérer Apple Distribution ?

Non, pas tant que la présence de la clé privée, l’accès au Keychain et la chaîne de confiance n’ont pas été vérifiés. errSecInternalComponent ne suffit pas à démontrer qu’un certificat est défectueux. La rotation ne devient défendable qu’après constat documenté d’une identité incomplète, expirée, ambiguë ou impossible à valider.

Comment confirmer la présence de la clé privée ?

Utilisez security find-identity pour obtenir les identités de signature valides, puis inspectez le certificat et les clés privées dans le Keychain du compte de construction. Le nom affiché ne suffit pas : l’association doit être cohérente et accessible dans le contexte SSH. Ne copiez jamais la clé privée dans un journal ni dans un dépôt.

Que faire après la fermeture de la session graphique ?

Le script doit sélectionner le bon Keychain, le déverrouiller et appliquer une autorisation non interactive limitée aux outils nécessaires. Rejouez ensuite un Archive depuis une nouvelle connexion SSH, après déconnexion graphique puis après redémarrage. Une boîte de dialogue qui reste obligatoire signifie que l’environnement n’est pas encore prêt pour une publication autonome.

Pourquoi find-identity affiche-t-il une identité inutilisable ?

Cette commande ne garantit pas que le processus dispose de la clé privée au moment de signer, ni que le bon Keychain est ouvert, ni que le profil et les entitlements correspondent à l’Archive. Complétez toujours l’observation par l’examen du compte, du trousseau, des autorisations, du profil et de l’étape exacte qui échoue.

Un Mac local reste préférable lorsque le besoin porte sur une charge lourde et permanente, sur des périphériques physiques ou sur une présence interactive fréquente. En revanche, une machine utilisée uniquement pour les Archives peut immobiliser un budget matériel, rester inaccessible lors d’un déplacement et conserver un état de Keychain difficile à reproduire après migration.

Les solutions de CI entièrement abstraites simplifient parfois la maintenance, mais elles imposent leurs contraintes de durée d’exécution, de stockage des secrets, de cache et de personnalisation. Un Mac distant conserve davantage de contrôle sur macOS, les outils de développement, les scripts et les journaux ; il exige en contrepartie une vraie procédure d’accès, de sauvegarde et de rotation des identités. Pour comparer les conditions d’accès et les modalités de support, la page d’aide NUKCLOUD peut compléter cette analyse.

Le point décisif n’est donc pas de faire disparaître une erreur par une commande radicale. Il consiste à rendre le contexte de signature reproductible : même utilisateur, même Keychain, clé privée accessible, profil cohérent et Archive validé après sortie de session. Si le Mac actuel exige encore une session graphique permanente ou une intervention sur une fenêtre au moment de publier, louer un Mac distant NUKCLOUD peut offrir un environnement plus adapté à une équipe qui doit conserver un hôte macOS disponible sans acheter une machine dédiée ; avant de choisir cette option, vérifiez toutefois les contraintes de charge longue, de matériel physique et de gestion des secrets propres au projet.