Votre signature ou votre paquet d’installation risque d’être rejeté lors d’une livraison : le pipeline utilise peut-être un certificat émis par l’ancienne autorité intermédiaire Developer ID.
Vérifiez d’abord l’émetteur réel dans votre CI Mac ; remplacez les certificats concernés par des certificats émis par Developer ID Certification Authority (G2), puis validez la signature et la notarisation dans une tâche isolée.
Cet article s’adresse aux équipes qui maintiennent la signature, la distribution et la notarisation d’applications macOS. Les ingénieurs DevOps qui gèrent les nœuds CI et les trousseaux de clés y trouveront une méthode de vérification sous le compte d’exécution réel. Les responsables de publication pourront distinguer les paquets d’installation des applications déjà notarisées avant de décider quoi remplacer.
Dernière mise à jour : 7 novembre 2026 ; informations vérifiées à partir des annonces et guides Developer d’Apple.
Étape de cadrage : identifier les livrables concernés
Apple indique que l’ancien certificat intermédiaire Developer ID Certification Authority (Sub-CA) arrive à expiration le 1er février 2027 et précise que les certificats concernés cesseront alors de fonctionner. La date ne signifie pas que toute application macOS déjà distribuée doit être resignée : Apple distingue les paquets d’installation signés avec un certificat Developer ID Installer de certaines applications déjà notarisées et dotées d’un horodatage sécurisé. Consultez l’annonce d’expiration d’Apple et la documentation Developer ID consacrée à la signature pour vérifier la portée annoncée.
La décision opérationnelle dépend donc de deux éléments : l’émetteur du certificat réellement utilisé et la nature du livrable. Ne lancez pas une rotation générale sur le seul constat qu’un certificat approche de sa date d’expiration ; commencez par établir la chaîne de signature, puis appliquez à chaque type d’artefact le contrôle qui lui correspond.
| Livrable ou situation | Vérification déterminante | Décision de publication |
|---|---|---|
| Certificat Developer ID émis par l’ancienne Sub-CA | L’émetteur du certificat, son usage et le nœud CI qui le sélectionne | Préparer son remplacement par un certificat émis par G2 et tester la chaîne sous le compte du pipeline |
Paquet .pkg signé avec le certificat Developer ID Installer concerné | Signature du paquet, certificat employé et résultat de la vérification | Faire signer de nouveau les paquets concernés avant le 1er février 2027 |
| Application macOS déjà notarisée avec horodatage sécurisé | Signature, ticket ou résultat de notarisation et présence de l’horodatage | Ne pas la resigner uniquement à cause de cette expiration si elle relève bien des conditions indiquées par Apple |
| Pipeline qui mélange plusieurs certificats ou plusieurs cibles | Association entre chaque cible, son identité de signature et son artefact final | Séparer les contrôles ; ne pas conclure à partir d’une seule compilation réussie |
Étape d’inventaire : retrouver l’émetteur utilisé dans Mac CI
Pour identifier le Sub-CA d’un certificat Developer ID, ne vous fiez ni à son nom d’affichage ni à sa seule date d’expiration. L’indice décisif est son émetteur (Issuer), examiné sur le certificat effectivement sélectionné par la tâche de publication. Un compte Apple Developer peut présenter plusieurs certificats, tandis qu’un pipeline peut en sélectionner un ancien dans un trousseau importé, une configuration de signature ou un secret CI.
Commencez par dresser un inventaire par cible de publication : application principale, extensions, outils auxiliaires, installateur et composants signés séparément. Pour chaque cible, notez le type d’identité attendu — Developer ID Application ou Developer ID Installer —, le nom de l’identité configurée, le trousseau où se trouve sa clé privée et le compte système qui exécute la tâche.
Dans l’accès aux trousseaux, ouvrez les certificats correspondants et inspectez leurs détails, notamment les champs de l’émetteur et du titulaire. Comparez ensuite ces informations avec la chaîne de signature d’un artefact réellement produit par CI. Les commandes d’inspection de signature et le contrôle des autorités décrits dans le guide Apple de vérification de la signature de code peuvent contribuer à cette vérification ; une liste d’identités disponibles n’établit pas à elle seule quel certificat le pipeline a choisi.
Comment établir quel Sub-CA a émis le certificat réellement utilisé par Mac CI ? Inspectez l’émetteur du certificat présent dans le trousseau accessible au compte d’exécution, puis vérifiez la chaîne portée par l’application ou le paquet produit. Si les deux contrôles ne concordent pas, considérez que l’inventaire est incomplet : une tâche peut appeler un autre trousseau, un autre profil de signature ou une variable d’environnement différente de celle utilisée lors de votre inspection interactive.
Pour éviter les faux positifs, consignez aussi le contexte de sélection. Relevez le schéma ou la configuration de construction, l’identité de signature demandée, le chemin du trousseau et la manière dont la clé est déverrouillée pendant le travail automatisé. Une identité visible dans une session graphique peut manquer au processus de CI, ou l’inverse. Le but n’est pas seulement de prouver qu’un certificat existe, mais de démontrer quelle identité signe chaque livrable dans les conditions de publication.
La date d’expiration sert de signal pour prioriser l’examen, pas de substitut au champ Issuer. Lorsque plusieurs certificats ont des noms proches, distinguez-les par leur usage, leur émetteur et leur chaîne de certification. Cette étape est essentielle pour ne pas renouveler un certificat non concerné tout en laissant une tâche de publication dépendre de l’ancien.
Étape de remplacement : préparer les certificats G2
La documentation Apple demande de créer les certificats de remplacement en choisissant la chaîne G2. Suivez le guide officiel de remplacement des certificats Developer ID et les instructions de création d’un certificat Developer ID ; vérifiez la procédure au moment de l’opération, notamment les conditions et limitations liées aux versions de Xcode mentionnées par Apple. Ne déduisez pas la compatibilité d’une version à partir d’un essai manuel sur un autre poste.
Les deux types de certificat ne sont pas interchangeables. Developer ID Application sert à signer l’application et les composants macOS concernés ; Developer ID Installer sert à signer le paquet d’installation .pkg. Si votre chaîne produit les deux, préparez et validez les deux usages séparément. Un certificat d’application ne remplace pas un certificat d’installateur, même si les deux relèvent de Developer ID.
Avant d’importer les nouvelles identités dans l’environnement d’automatisation, fixez les responsabilités de l’équipe :
- qui crée ou renouvelle chaque certificat et qui contrôle son usage ;
- qui détient la clé privée associée et qui autorise son importation dans le trousseau ;
- quel nœud, compte d’exécution et groupe de tâches pourront accéder à cette clé ;
- comment les secrets et les mots de passe de trousseau sont distribués, renouvelés et retirés ;
- quelle personne peut approuver une reprise ou un retour temporaire à la chaîne précédente.
Si vous ne disposez pas encore d’un environnement macOS réservé à ces vérifications, vous pouvez examiner les possibilités d’un environnement de développement Mac à distance. Cela vous aide à préparer un nœud de test distinct de votre poste, mais ne préjuge ni du stockage des clés ni des garanties de gestion des certificats : vérifiez ces exigences avant d’y transférer un secret de signature.
Étape d’essai : exécuter la chaîne dans un CI isolé
Une signature réalisée manuellement depuis votre session ne valide pas le pipeline. L’essai doit reproduire le chemin de publication : même compte d’exécution, mêmes références au trousseau et mêmes paramètres de signature que ceux utilisés par la tâche de production. Isolez la tâche des publications réelles et utilisez un artefact de test afin de pouvoir examiner chaque résultat sans déclencher une distribution involontaire.
Quelles opérations faut-il réaccepter après le remplacement par un certificat G2 ? Vérifiez séparément la sélection de l’identité, la signature, l’inspection de la chaîne, l’envoi à la notarisation et la vérification du résultat de notarisation. Une soumission acceptée ne prouve pas à elle seule que l’artefact final est signé avec la bonne identité ; une signature valide ne prouve pas non plus que la tâche de notarisation a abouti.
Conservez une preuve par opération. Pour la signature, enregistrez l’identité demandée et les informations de chaîne relevées sur l’artefact. Pour la notarisation, consignez l’identifiant de soumission, le résultat renvoyé et les journaux utiles ; Apple décrit les étapes de ce flux dans sa documentation de notarisation en ligne de commande. Puis contrôlez l’artefact final, pas seulement un répertoire de travail intermédiaire : un assemblage ultérieur peut remplacer ou modifier un fichier déjà signé.
L’essai doit également vérifier les conditions d’accès à la clé privée. Si l’exécution automatisée échoue alors que l’importation semble correcte, contrôlez le trousseau ouvert par le processus, les autorisations, le compte qui déverrouille le trousseau et les références de signature injectées dans la tâche. Ne contournez pas l’échec en lançant la même commande sous un autre utilisateur puis en déclarant la CI validée : cela masque précisément les différences à corriger.
Pour la notarisation, distinguez l’envoi du logiciel de la vérification du résultat. Apple explique les exigences de préparation et de distribution dans sa documentation sur la notarisation des logiciels macOS avant leur distribution. Archivez le résultat correspondant à l’artefact et au certificat testés. Si vous ne pouvez pas relier clairement le rapport de notarisation au fichier publié, l’essai n’est pas une preuve suffisante pour autoriser le basculement.
Étape de validation : contrôler séparément applications et paquets
La validation finale doit suivre le format de livraison, et non une seule étape générique intitulée « signature ». Pour une application macOS, vérifiez le certificat de signature, la chaîne d’autorité, la notarisation et l’horodatage sécurisé lorsqu’il est applicable. Pour un .pkg, vérifiez la signature du paquet lui-même, puis confirmez que le certificat Developer ID Installer utilisé est celui attendu.
Que faire des paquets signés avec un certificat Developer ID Installer concerné ? Identifiez les paquets qui portent effectivement la signature de l’ancien certificat, remplacez cette identité dans la chaîne d’assemblage, puis faites signer de nouveau les paquets concernés avant le 1er février 2027. Testez ensuite l’installation du paquet reconstruit et archivez son certificat ainsi que le résultat de vérification.
Ne supposez pas qu’une application resignée à l’intérieur d’un installateur met automatiquement à jour la signature du paquet enveloppant. Ce sont deux contrôles distincts. Vérifiez le paquet distribué tel qu’il sera téléchargé, et non seulement l’application extraite après installation. Si votre processus publie plusieurs variantes — par exemple un téléchargement direct et un installateur — appliquez les contrôles adéquats à chacune.
Une application Mac déjà notarisée doit-elle être resignée uniquement à cause de l’expiration ?
Pas nécessairement. Apple indique que les applications déjà notarisées et munies d’un horodatage sécurisé ne doivent pas être resignées uniquement en raison de cette expiration. Confirmez cependant que le livrable est bien une application répondant à ces conditions et ne transposez pas cette indication à un .pkg signé avec le certificat Installer concerné. En cas de doute sur l’horodatage ou l’état de notarisation, vérifiez l’artefact et sa chaîne plutôt que de conclure à partir de l’historique du projet.
Avant de diffuser une version corrigée, comparez le résultat avec les critères de validation du projet : identité attendue, émetteur G2, absence d’erreur de signature, résultat de notarisation associé au bon fichier et installation vérifiée lorsque le livrable est un paquet. Ajoutez ces éléments au dossier de publication, avec le nom de la cible et la configuration CI utilisée. Vous pourrez ainsi expliquer pourquoi une application existante n’a pas été resignée tout en démontrant que les paquets concernés ont, eux, été remplacés.
Étape de déploiement : généraliser la rotation et planifier la revue
Après un essai concluant, mettez à jour les références dans les nœuds de CI par groupes de tâches ou de cibles, puis relancez les validations sur les livrables effectivement publiés. Ne supprimez pas les anciennes références avant d’avoir vérifié que les tâches dépendantes ont été migrées et que le retour arrière reste maîtrisé. La solution de repli doit permettre de suspendre une publication ou de revenir à une version de pipeline connue, sans masquer l’usage persistant d’un certificat concerné.
La preuve de basculement doit répondre à des questions concrètes : quelles cibles utilisent le nouveau certificat, quel compte CI a exécuté la signature, quel émetteur apparaît dans la chaîne, quel résultat la notarisation a renvoyé et quelles versions de paquets ont été remplacées ? Si une réponse repose seulement sur la configuration déclarée, ajoutez une vérification de l’artefact produit. Une configuration peut être correcte alors qu’un cache, un script secondaire ou un trousseau inattendu continue de fournir une autre identité.
Réexaminez ensuite les certificats dans le compte Apple Developer : usage, émetteur, période de validité et nœuds qui en dépendent. Ajoutez la revue des certificats G2 au calendrier de maintenance de l’équipe, conformément aux indications Apple en vigueur, plutôt que d’attendre le prochain blocage de publication. À l’approche du 1er février 2027, contrôlez de nouveau les annonces officielles et les paquets encore distribués ; si Apple modifie sa documentation ou les étapes de remplacement, adaptez le runbook avant la prochaine mise en production.
Choisir le bon environnement de validation
Un poste de travail local peut convenir à l’analyse initiale, mais il ne reproduit pas toujours le compte, le trousseau et les secrets utilisés par la CI. Un nœud automatisé déjà en production permet de tester le chemin réel, mais une expérimentation de certificat directement sur ce nœud augmente le risque de perturber les livraisons. Un Mac de test séparé apporte un périmètre plus net, à condition de configurer la chaîne d’accès et de vérifier les droits de la clé privée.
Pour choisir, évaluez ces critères plutôt que la seule disponibilité d’un ordinateur :
- Reproductibilité : pouvez-vous relancer la même tâche sous le même compte et retrouver ses preuves ?
- Isolation : l’essai peut-il être mené sans modifier les certificats ni interrompre une publication active ?
- Contrôle des secrets : savez-vous précisément où la clé privée est importée et qui peut l’utiliser ?
- Fidélité de livraison : l’environnement permet-il de vérifier le format final, y compris le
.pkglorsque vous en distribuez un ? - Retour arrière : pouvez-vous interrompre le basculement sans laisser le pipeline sélectionner une identité indéterminée ?
À l’inverse, une machine locale est souvent plus adaptée si les essais sont fréquents, si vous avez besoin d’interfaces physiques ou si vos exigences internes imposent un contrôle direct du matériel. Un serveur Linux peut héberger une partie de l’orchestration, mais ne remplace pas l’environnement macOS requis pour valider la signature, la notarisation et l’installation d’un logiciel Mac. Le bon choix dépend donc de la durée du besoin, des exigences de sécurité et de la capacité à reproduire la chaîne de publication.
Votre décision immédiate est simple : identifiez l’émetteur avant de renouveler, séparez les contrôles des applications de ceux des paquets, puis n’autorisez le basculement qu’après un essai sous le compte réel de Mac CI. Si vous manquez temporairement d’un environnement macOS isolé, MACGPU peut être une option de location à examiner pour effectuer ces essais ; pour une chaîne de signature permanente ou des contraintes fortes de contrôle des clés, comparez d’abord cette option à un Mac dédié et à vos règles de sécurité.