Jenkins errSecInternalComponent : guide de correction CI d’entreprise 2026

Si Terminal graphique réussit la signature mais qu’un Job Jenkins renvoie errSecInternalComponent, il ne faut pas réinstaller les certificats en premier : il faut exécuter le même test minimal dans Terminal, en SSH puis dans Jenkins, avec le même compte, la même identité de signature et le même fichier. Cette comparaison permet ensuite de distinguer une identité numérique incomplète, un trousseau verrouillé, une ACL restrictive ou un contexte d’agent différent.

Cet article concerne les responsables qui maintiennent un agent Jenkins macOS pour les versions iOS et macOS. Il s’adresse aussi aux responsables sécurité qui gèrent les clés privées et l’audit des mises en production, ainsi qu’aux acheteurs IT qui évaluent un Mac distant pour une signature sans intervention humaine.

Dernière mise à jour : 5 septembre 2026. Les éléments Apple ont été vérifiés à partir de la documentation technique et du fil de diagnostic Apple, dont la dernière révision explicitement examinée date du 6 juillet 2026. Références Apple sur la signature de code

[ SECTION_01 ] Jenkins errSecInternalComponent : le signal doit être comparé, pas interprété isolément

L’erreur ne prouve pas, à elle seule, que le certificat est corrompu. Apple décrit ce type d’échec dans des environnements de signature non standards, notamment lors d’une exécution par SSH ou par une intégration continue. Les pistes à examiner incluent le verrouillage du trousseau, l’accès à la clé privée, la confiance du certificat et le mélange de contextes de sécurité. Le diagnostic Apple consacré à la signature de code

Le premier point de mesure est donc la divergence suivante :

• Terminal graphique : signature réussie ;
• session SSH : résultat à vérifier séparément ;
• Job Jenkins : errSecInternalComponent.

Ces trois exécutions doivent utiliser le même utilisateur macOS, le même fichier de test non sensible, la même identité et un environnement comparable. Si seul Jenkins échoue, la machine et l’identité ne sont pas encore disculpées, mais le périmètre se déplace vers l’agent, son lancement et son trousseau réellement sélectionné.

Le test minimal peut rester volontairement limité :

security find-identity -v -p codesigning
codesign --display --verbose=4 chemin/vers/fichier-de-test
codesign --sign "Identité de test" chemin/vers/fichier-de-test

La sortie complète doit être conservée dans le dossier de preuve, mais jamais les mots de passe, les clés privées ou les variables contenant des secrets. La commande ne constitue pas une réparation ; elle établit une base de comparaison. La documentation Apple sur les certificats de signature explique pourquoi un certificat visible ne suffit pas à démontrer qu’une identité complète est disponible pour signer. Consulter la note technique Apple sur les certificats de signature

[ SECTION_02 ] Intégrité de l’identité numérique

Une identité de signature exploitable réunit au minimum le certificat attendu et la clé privée correspondante. La présence du certificat dans le trousseau ne démontre donc pas que codesign peut utiliser la clé privée. Cette distinction est souvent la cause d’une fausse correction : un certificat est réimporté, il apparaît dans l’interface, mais le Job continue de produire la même erreur.

L’équipe doit relever séparément :

1. le nom et l’état du certificat ;
2. la présence de la clé privée associée ;
3. l’identité retournée par security find-identity ;
4. la chaîne de certificats intermédiaires ;
5. l’état de confiance réellement applicable à la signature.

Une identité absente de la liste valide appelle une analyse différente d’une identité listée mais inutilisable. Dans le premier cas, le certificat et la clé privée ne forment peut-être pas une paire exploitable, ou le processus ne consulte pas le bon trousseau. Dans le second, l’accès à la clé, la confiance ou le contexte d’exécution devient prioritaire.

Pourquoi Jenkins peut-il compiler mais échouer pendant codesign ?

La compilation peut utiliser le code source, les dépendances et le SDK sans accéder à une clé privée. La signature intervient ensuite et demande une opération cryptographique ainsi qu’un accès autorisé au matériel secret. Un agent peut donc terminer la compilation, créer un paquet intermédiaire, puis échouer uniquement lorsqu’il doit signer l’archive ou l’application.

Les responsables doivent éviter de conclure à partir du seul message final. La preuve utile associe la commande exécutée, l’utilisateur du processus, le trousseau consulté et le résultat de la recherche d’identité. Un journal qui indique uniquement « signature échouée » ne permet pas de séparer le certificat, la clé privée et l’environnement Jenkins.

Cette vérification vaut également pour les tâches audio, vidéo ou de design qui exportent une application compagnon ou un outil macOS. Le type de projet change, mais la séparation entre production de l’artefact et accès à la clé privée reste la même.

[ SECTION_03 ] Accessibilité du trousseau macOS et contrôle ACL

Le deuxième indicateur est l’accès effectif au trousseau macOS depuis le processus Jenkins. Une session graphique peut bénéficier d’un déverrouillage lié à l’ouverture de session. Une session SSH ou un agent démarré comme service peut ne pas disposer du même état. Le fait qu’un utilisateur soit identique ne garantit donc pas que son processus possède le même contexte de trousseau.

La vérification doit porter sur quatre éléments :

• le trousseau réellement utilisé par le processus ;
• son état verrouillé ou déverrouillé ;
• la liste de recherche active ;
• les règles d’accès de la clé privée.

Un trousseau visible dans l’interface graphique n’est pas une preuve suffisante. L’agent peut utiliser un autre HOME, une autre liste de recherche ou un trousseau laissé verrouillé. Il faut effectuer le test sans fenêtre de confirmation. Si la signature ne fonctionne qu’après un clic manuel, le nœud ne satisfait pas une exigence de publication sans surveillance.

Comment traiter errSecInternalComponent après une connexion SSH sur un Mac distant ?

La procédure sûre consiste à vérifier le trousseau et l’identité dans la session SSH, puis à comparer ces éléments avec ceux observés par le Job Jenkins. Il ne faut pas commencer par donner le mot de passe du trousseau à une commande enregistrée dans le journal. Les mots de passe ne doivent apparaître ni dans un Jenkinsfile, ni dans une variable d’environnement ordinaire, ni dans une ligne de commande conservée par l’outil CI.

L’ACL et la partition d’accès doivent être ajustées au périmètre nécessaire. L’objectif est d’autoriser les outils de signature requis, et non de donner un accès général à tous les processus de l’agent. Toute modification doit être testée avec une identité non productive avant d’être proposée sur un nœud de publication.

La distinction entre certificat visible et signature possible doit rester explicite dans le compte rendu. Une ligne de certificat trouvée dans le trousseau est un indice. Une signature sans interaction, vérifiée dans le contexte Jenkins, est la preuve opérationnelle.

[ SECTION_04 ] Contexte de l’agent Jenkins

Le troisième indicateur concerne le processus qui exécute réellement le Job. La documentation Jenkins distingue le contrôleur, les nœuds et les agents ; le fait qu’un Job soit affecté à un nœud ne suffit pas à décrire son identité macOS ou son environnement de session. Documentation Jenkins sur les nœuds

L’équipe doit comparer, dans le Job et lors du test interactif :

• le compte macOS ;
• le propriétaire du processus ;
• HOME ;
• le mode de lancement de l’agent ;
• les variables nécessaires à la sélection du trousseau ;
• l’accès effectif à la clé privée ;
• le contexte de sécurité établi lors de la connexion.

Le critère de décision est simple : l’exécutant du Job et l’utilisateur du test de référence doivent-ils vraiment voir la même identité et le même trousseau ? Si la réponse est négative, le résultat du test graphique ne valide pas Jenkins.

Comment déterminer si l’échec vient de la clé privée, de l’ACL ou du contexte utilisateur ?

La méthode consiste à modifier une seule variable à la fois et à conserver le résultat de chaque essai. Une identité absente de la liste valide oriente vers l’association certificat-clé ou vers le mauvais trousseau. Une identité visible mais inutilisable oriente vers la clé privée, l’ACL ou la confiance. Une signature réussie dans Terminal mais échouée dans Jenkins oriente vers le contexte de l’agent, son lancement ou son environnement.

Cette matrice de diagnostic évite trois erreurs coûteuses :

• réimporter sans fin un certificat déjà présent ;
• exécuter le Job avec sudo ou root en espérant hériter de la session graphique ;
• confondre les identifiants Jenkins du contrôleur avec l’identité de signature locale au Mac.

sudo et root ne constituent pas une solution générale. Ils changent souvent le propriétaire du processus, le répertoire personnel et le trousseau consulté. La correction doit plutôt reposer sur un compte macOS dédié, non privilégié, dont le rôle est documenté et auditable. Jenkins doit ensuite utiliser ses propres mécanismes d’identifiants pour connecter l’agent, sans mélanger ces secrets avec la clé privée de signature. Voir le fonctionnement officiel des agents Jenkins

[ SECTION_05 ] Isolation des signatures et exposition des secrets

Le quatrième indicateur est l’isolation. Un Job de validation de pull request n’a pas nécessairement besoin d’accéder à une clé de production. Une archive de test, une publication interne et une mise en production doivent être traitées selon des niveaux de confiance différents.

Une organisation peut comparer trois modèles :

• le trousseau de session existant, rapide à mettre en place mais fortement dépendant du contexte de connexion ;
• un trousseau temporaire dédié au Job, adapté à un périmètre court et à un nettoyage vérifiable ;
• un nœud de publication séparé, plus exigeant à administrer mais mieux adapté à une clé de production.

Le choix ne doit pas être dicté par la seule simplicité. Il doit répondre à la question suivante : combien de Jobs, d’utilisateurs et de fichiers temporaires peuvent atteindre la clé ? Les tâches ordinaires ne devraient pas être planifiées sur un nœud qui possède une identité de production.

Les labels Jenkins doivent donc refléter la capacité réelle du nœud, par exemple un label réservé à la publication signée. Les autorisations doivent limiter les Jobs pouvant demander ce label. L’audit doit pouvoir démontrer :

• quel Job a demandé le nœud ;
• quel compte a exécuté la signature ;
• quelle identité a été utilisée ;
• quand la clé a été rendue disponible ;
• si l’espace de travail et les fichiers temporaires ont été nettoyés.

La clé privée ne doit pas être placée dans le dépôt, dans le Jenkinsfile ou dans un journal. Les fichiers de certificat et les profils nécessaires doivent être injectés dans une zone contrôlée, avec une durée de vie limitée et une suppression vérifiable après la tâche.

[ SECTION_06 ] Reprise après redémarrage et décision de production

Le cinquième indicateur est la reprise. Une correction qui fonctionne après une ouverture de session manuelle n’est pas encore une solution de production. La validation doit couvrir le redémarrage de l’hôte, la reconnexion de l’agent et l’absence d’ouverture graphique par un opérateur.

Après chaque changement, la séquence d’acceptation doit comporter les étapes suivantes :

1. exécuter le test minimal dans le Terminal graphique avec un compte de test ;
2. répéter exactement ce test dans une session SSH ;
3. lancer le même test depuis le Job Jenkins ;
4. vérifier l’identité, le trousseau, la clé privée et l’ACL observés par le processus ;
5. redémarrer l’hôte, attendre la reconnexion de l’agent, puis répéter le test sans clic manuel ;
6. lancer une véritable archive non productive ;
7. vérifier la suppression des certificats temporaires, des profils et des fichiers de travail.

Les étapes six et sept ne remplacent pas les tests précédents. Elles vérifient que le correctif résiste au chemin réel de livraison et qu’il ne laisse pas de matériel sensible sur le nœud.

Une preuve complète doit réunir le journal de l’échec initial, la modification appliquée, le résultat de la signature sans interaction, la reprise après redémarrage et la preuve de nettoyage. Si un opérateur doit accepter une fenêtre du trousseau après chaque redémarrage, le nœud ne doit pas être admis comme serveur de publication sans surveillance.

[ SECTION_07 ] Comparatif de décision pour le nœud de signature

Le tableau suivant sert à choisir un périmètre d’essai avant de modifier la production. Il ne remplace pas les preuves issues des commandes et des Journaux Jenkins.

Option	Identité et trousseau	Exposition de la clé	Reprise après redémarrage	Usage recommandé
Nœud partagé avec trousseau de session	Dépend du compte et du lancement de l’agent	Élevée si plusieurs Jobs y accèdent	À démontrer explicitement	Tests contrôlés, pas publication par défaut
Trousseau temporaire dédié	Périmètre limité si le nettoyage est vérifiable	Plus faible, mais gestion des secrets indispensable	À automatiser et à tester	Validation ou publication à faible portée
Nœud macOS dédié à la publication	Compte non privilégié et contexte documenté	Réduite par les labels et les autorisations	Doit fonctionner sans session graphique	Publication d’entreprise après acceptation
Mac distant isolé pour le pilote	Accès graphique et SSH utiles au diagnostic	Dépend de l’isolation et de la politique d’accès	À prouver pendant le pilote	Essai court avant modification d’une machine existante

Pour un pilote distant, la capacité à accéder au Mac par les canaux nécessaires doit être vérifiée avant d’y déposer une identité de production. Les équipes qui évaluent cette option peuvent consulter les solutions Mac distantes de NOVAKVM et comparer une configuration Mac mini destinée aux charges CI. Ces pages servent à préparer le choix du support ; elles ne remplacent pas l’acceptation de la signature sans interaction.

La bonne décision dépend de la preuve obtenue. Un Mac acheté sur site peut convenir à une charge stable lorsque l’équipe maîtrise l’alimentation, l’accès physique, les remplacements et la reprise. En revanche, un poste partagé ou une machine locale mal isolée ajoute souvent des contraintes de maintenance, de disponibilité physique et de séparation des clés. Lorsque l’infrastructure actuelle ne permet pas de réaliser un pilote sans toucher au serveur de production, louer temporairement un Mac distant auprès de NOVAKVM peut fournir un nœud indépendant avec accès graphique et SSH, à condition de valider explicitement le compte dédié, le trousseau, la reconnexion Jenkins et le nettoyage.

La recommandation reste volontairement conditionnelle : les charges lourdes et stables, les besoins d’interface physique ou les exigences de contrôle matériel complet peuvent justifier un Mac acheté et administré sur site. Une signature ponctuelle, un test de reprise ou une validation d’architecture se prête davantage à un nœud distant temporaire. Dans les deux cas, l’admission doit reposer sur la même feuille de preuves, et non sur la seule présence du certificat dans le trousseau.

Un responsable peut donc fermer l’incident lorsque le même test réussit dans les trois contextes, qu’aucune fenêtre n’est nécessaire, que le compte de signature n’est pas root, que les Jobs ordinaires ne voient pas la clé de production et que le redémarrage ne demande pas d’intervention humaine. Si l’un de ces critères échoue, le correctif doit rester en préproduction.