Comment migrer le certificat Developer ID G2 ? Validation de signature Mac 2026

Échéance publiée par Apple : 1er février 2027 pour l’ancienne autorité Developer ID ; vérifiez l’émetteur avant de modifier votre chaîne de signature (annonce d’Apple).
Solution rapide : migrez les certificats concernés vers G2 et traitez séparément les applications Mac et les paquets .pkg : une application déjà horodatée et notariée n’a pas automatiquement à être resignée, tandis qu’un paquet concerné doit être resigné avant l’échéance.

À qui s’adresse ce guide ?
Aux développeurs indépendants qui distribuent une application Mac hors du Mac App Store et doivent vérifier leur identité de signature.
Aux équipes de publication qui livrent des .pkg, ainsi qu’aux ingénieurs CI/CD qui gèrent certificats, clés privées et tâches de signature.

Dernière vérification : 28 octobre 2026, à partir de l’annonce d’Apple, de son guide de remplacement des certificats et de ses documents de référence liés ci-dessous.

Ce que l’échéance change pour vos livrables

L’expression « migration du certificat Developer ID G2 » recouvre plusieurs opérations, mais toutes les équipes ne doivent pas refaire toutes leurs signatures. Apple indique que l’ancienne autorité de certification Developer ID arrive à échéance le 1er février 2027 ; les certificats émis par cette autorité ne doivent plus être utilisés pour signer après cette date. Les paquets d’installation concernés doivent être resignés avec un certificat de remplacement avant l’échéance. En revanche, les logiciels Mac déjà signés avec un horodatage sécurisé et notariés peuvent continuer à fonctionner selon l’annonce d’Apple.

Cette distinction porte sur le type de livrable et son historique de signature, pas simplement sur le fait qu’il soit « ancien ». Un fichier .app et un paquet .pkg n’ont pas le même rôle : le premier est l’application distribuée, tandis que le second est un installateur qui peut contenir l’application, des scripts ou d’autres éléments. Il faut donc inventorier les fichiers réellement remis aux utilisateurs, plutôt que de traiter un projet comme un seul artefact indifférencié.

Livrable	Effet de l’échéance de l’ancienne autorité	Décision de migration
Application Mac déjà horodatée de façon sécurisée et notariée	Apple indique qu’elle peut continuer à fonctionner après l’échéance.	Ne la resigniez pas par réflexe ; vérifiez son statut et faites un essai de lancement sur une machine représentative.
Paquet `.pkg` signé avec un certificat concerné	Apple demande de le resigner avec un certificat de remplacement avant l’échéance.	Produisez un nouveau paquet signé et validez l’installation, pas seulement la signature.
Nouveau livrable ou livrable dont l’émetteur reste incertain	Le comportement dépend de l’identité de signature et du type de livrable.	Confirmez l’émetteur, puis faites un essai de publication avec le certificat de remplacement.

Les règles de remplacement et la portée de l’échéance doivent être vérifiées dans la page Apple consacrée au remplacement des certificats Developer ID. La description Apple des certificats Developer ID distingue notamment les identités destinées à signer des applications de celles qui signent des installateurs.

Après l’échéance, un .pkg signé avec l’ancien certificat pourra-t-il encore être installé ? Pour un paquet touché par l’ancienne autorité, ne prévoyez pas sa distribution comme si elle restait garantie : Apple demande de le resigner avec le certificat de remplacement avant le 1er février 2027. Remplacez le fichier dans vos canaux de téléchargement et de mise à jour, puis validez le nouveau paquet sur une installation propre. L’annonce ne justifie pas d’étendre cette conclusion à toutes les applications déjà distribuées.

Développeurs indépendants : identifier l’émetteur

La première vérification consiste à établir si le certificat utilisé est effectivement concerné. La présence des mots « Developer ID Application » ou « Developer ID Installer » ne suffit pas : ces noms désignent des types d’identité, pas à eux seuls l’autorité qui a émis le certificat. La date affichée dans le trousseau ne suffit pas davantage. Apple demande de vérifier les informations du certificat et de suivre ses consignes de remplacement ; la page sur les certificats intermédiaires Developer ID fournit des repères sur la chaîne de certification.

Comment savoir si le certificat Developer ID a été émis par l’ancienne autorité ? Consultez d’abord la fiche du certificat dans votre compte de développeur, puis comparez-la aux informations du certificat présent dans le trousseau de la machine qui signe. Vérifiez le champ de l’émetteur et les éléments de chaîne indiqués par Apple ; si les informations ne concordent pas, suspendez la publication jusqu’à clarification, au lieu de déduire la réponse du seul nom visible dans un réglage de projet.

L’inventaire doit porter sur les certificats actifs et sur les copies installées dans les environnements qui peuvent encore publier : poste de développement, machine de construction et éventuelle machine de secours. Une ancienne identité peut rester référencée dans une configuration même après la création d’un certificat de remplacement. Vérifiez aussi quel fichier est effectivement envoyé aux utilisateurs : une application notarée peut être accompagnée d’un installateur distinct, et c’est alors le paquet qui impose une action.

Comment distinguer un certificat Developer ID G2 de l’ancien certificat ? Comparez les détails de l’émetteur et la chaîne du certificat aux indications officielles d’Apple ; ne vous fiez ni à un libellé abrégé dans l’interface, ni au seul nom de l’identité dans la configuration de signature. Si l’interface ne permet pas de conclure, utilisez les détails du certificat et la documentation Apple plutôt que de publier en supposant que « Developer ID » signifie automatiquement G2.

Le glossaire Apple sur Developer ID aide à ne pas confondre les deux identités essentielles : Developer ID Application pour signer le logiciel applicatif et Developer ID Installer pour signer le paquet d’installation. Si le compte présente un certificat de remplacement, relevez son type, son émetteur et son état avant de l’ajouter aux tâches de publication. Une identité d’application ne remplace pas une identité d’installateur lorsqu’un projet distribue un .pkg.

Une migration vérifiée n’est pas simplement un nouveau certificat visible dans le trousseau : elle doit aussi prouver que la tâche de publication utilise bien cette identité et que l’artefact livré correspond au test effectué.

Équipes de publication : accepter séparément l’application et le paquet

Pour une équipe Mac, la question utile n’est pas « faut-il tout resigner ? », mais « quel artefact publié dépend de l’identité concernée ? ». Si l’application existante possède l’horodatage sécurisé et la notarisation mentionnés par Apple, l’annonce ne demande pas de la resigner systématiquement du seul fait de l’échéance de l’autorité. Si le produit est remis dans un paquet signé par un certificat affecté, il faut en revanche reconstruire ou reconditionner ce .pkg, le signer avec le certificat de remplacement et vérifier l’installation obtenue.

Le changement de certificat oblige-t-il à resigner l’application et le paquet ? Non, pas automatiquement. Pour l’application, consignez l’état de signature, l’horodatage sécurisé et la notarisation, puis décidez selon les conditions publiées par Apple. Pour un .pkg concerné, prévoyez une nouvelle signature avec l’identité Developer ID Installer de remplacement. Si l’application est embarquée dans ce paquet, contrôlez les deux niveaux : la signature de l’application incluse ne prouve pas à elle seule que le paquet d’installation est correctement signé.

Un contrôle de livraison doit aller au-delà d’un message de réussite du système de construction. Consultez les recommandations Apple sur la notarisation d’un logiciel Mac avant distribution et sur la résolution des problèmes courants de notarisation. La notarisation et la signature répondent à des contrôles différents ; une réponse positive pour l’un ne remplace pas l’inspection du livrable et de son installation.

L’équipe peut ordonner l’acceptation ainsi : mise à jour de l’identité de signature, production d’un artefact candidat, vérification de la signature, traitement de la notarisation si le flux de publication l’exige, puis installation sur un environnement de test. Conservez les résultats associés à l’artefact exact, afin qu’une validation ne soit pas réutilisée par erreur pour un paquet reconstruit ou modifié ultérieurement.

Contrôle avant diffusion	Application `.app`	Paquet `.pkg`
Identité à examiner	Developer ID Application	Developer ID Installer
Question centrale	L’application existante répond-elle aux conditions Apple relatives à l’horodatage et à la notarisation ?	Le paquet utilise-t-il un certificat concerné par l’échéance ?
Action si l’identité est touchée	Adopter l’identité de remplacement pour les prochaines signatures, sans imposer une resignature générale des applications déjà couvertes par l’annonce.	Resigner le paquet avec l’identité de remplacement avant l’échéance.
Vérification de livraison	Contrôler signature, notarisation selon le flux retenu et lancement de l’application.	Contrôler signature, résultat de notarisation le cas échéant et installation effective du paquet.
Preuve à archiver	Artefact testé et résultats de validation correspondant à cette version.	Paquet testé, identité utilisée et résultat d’installation correspondant à ce fichier.

Les instructions Apple pour personnaliser un flux de notarisation sont à consulter lorsque l’équipe adapte le processus à ses livrables. Elles ne dispensent pas de faire une installation d’essai : un installateur peut être correctement signé sans que le parcours d’installation, les scripts ou la configuration attendue aient été validés sur une machine propre.

Ingénieurs CI/CD : changer l’identité sans perdre la traçabilité

Dans une chaîne macOS CI, le risque courant est de créer le nouveau certificat tout en laissant une tâche pointer sur l’ancienne identité. La vérification doit donc couvrir le trousseau utilisé par l’agent de construction, la présence de la clé privée associée, les références de signature dans le projet et les paramètres de la tâche qui fabrique le livrable. Vérifiez également les étapes de publication et de notarisation : une tâche peut signer correctement l’application, alors que le paquet est encore produit avec une identité d’installateur différente.

La séquence la plus sûre consiste à isoler une tâche de publication de test, à lui fournir l’identité de remplacement selon la procédure Apple, puis à inspecter les artefacts qu’elle génère. Ne remplacez pas l’identité en production avant d’avoir confirmé que la tâche utilise effectivement le nouveau certificat, que la clé privée correspondante est accessible au processus de signature et que l’artefact obtenu passe les contrôles prévus.

Pour la gestion des secrets, limitez les accès aux personnes et aux tâches qui en ont besoin, évitez d’inscrire une clé privée ou un secret dans le dépôt, et suivez la documentation Apple pour l’intégration de votre flux. Les détails varient selon l’architecture du constructeur et la façon dont l’équipe conserve ses identifiants ; une commande ou un réglage copié d’un autre pipeline ne constitue donc pas une garantie universelle. La documentation Apple sur les certificats et l’horodatage du code est une référence utile pour interpréter les certificats et les preuves associées à une signature.

Comment intégrer le nouveau certificat sans interrompre les publications ? Faites d’abord une publication candidate isolée, sans remplacer la tâche de production. Comparez l’identité réellement utilisée, inspectez séparément l’application et le .pkg, puis réalisez l’installation à partir du fichier candidat. Lorsque tous les résultats sont consignés, modifiez la tâche officielle et gardez un moyen documenté de revenir à la configuration précédente, sans réintroduire un certificat dont l’usage après échéance serait inadapté.

Liste de validation avant bascule

[ ] Inventorier chaque identité Developer ID Application et Developer ID Installer dans le compte et les trousseaux des machines de publication.
[ ] Vérifier l’émetteur de chaque certificat avec les indications Apple, sans conclure à partir du nom ou de la date d’expiration seuls.
[ ] Associer chaque identité aux livrables réellement distribués : application seule, paquet .pkg, ou les deux.
[ ] Obtenir et installer le certificat de remplacement correspondant à chaque rôle concerné, en suivant le guide Apple.
[ ] Exécuter une tâche isolée qui signe l’application et le paquet avec les identités prévues, puis inspecter les résultats.
[ ] Vérifier la notarisation lorsque le flux de distribution l’exige et conserver la preuve correspondant à l’artefact testé.
[ ] Installer le .pkg candidat sur un environnement de test et lancer l’application issue de l’installation.
[ ] Attribuer un responsable à la bascule et définir le retour arrière avant de modifier la chaîne officielle.
[ ] Remplacer les anciens artefacts concernés dans les canaux de téléchargement et les mécanismes de mise à jour avant le 1er février 2027.

Cette liste sert à organiser une validation reproductible ; elle ne remplace pas les conditions techniques précises d’Apple. En cas d’erreur de signature ou de notarisation, comparez le certificat utilisé, le fichier réellement examiné et les journaux de la tâche avec les recommandations Apple de dépannage de notarisation, plutôt que de relancer la publication sans identifier le point de divergence.

Responsabilités de migration et choix d’environnement

Une bascule fiable nécessite une personne responsable de l’inventaire, une autre ou la même personne chargée d’obtenir les certificats de remplacement, et un propriétaire de la validation utilisateur. Dans une petite équipe, une personne peut tenir plusieurs rôles, à condition que la décision de diffusion repose sur des preuves distinctes : identité utilisée, signature du livrable, résultat de notarisation si applicable et installation du paquet.

Rôle	Décision à prendre	Condition de passage
Développeur indépendant	Déterminer si l’application ou le paquet est concerné.	Émetteur vérifié et livrable identifié.
Responsable de publication	Choisir les artefacts à signer de nouveau et organiser leur remplacement.	Nouveau paquet accepté après installation d’essai ; application évaluée séparément selon les critères Apple.
Ingénieur CI/CD	Mettre à jour les références de certificat et les secrets utilisés par la chaîne.	Tâche isolée concluante et production officielle traçable.

Il vaut mieux commencer l’inventaire dès maintenant que d’attendre la date limite. Cela laisse du temps pour repérer les paquets conservés dans un ancien canal de téléchargement, corriger une référence oubliée dans un agent de construction ou refaire une installation qui échoue uniquement sur une machine propre. La migration vers G2 ne prolonge pas indéfiniment la validité d’un certificat : les équipes doivent continuer à suivre sa date d’expiration et les instructions de renouvellement applicables.

L’environnement de signature compte aussi dans la décision. Une machine macOS déjà contrôlée par l’équipe peut convenir lorsque ses trousseaux, ses clés privées et sa disponibilité sont maîtrisés. À l’inverse, un environnement Linux ne permet pas à lui seul de reproduire toutes les étapes macOS de signature et d’installation ; une machine locale partagée peut compliquer la séparation des secrets, la disponibilité des tâches et la reproduction d’un incident. Pour une équipe qui publie rarement, louer un Mac peut éviter l’achat et la maintenance d’un poste dédié, tout en fournissant une machine macOS pour tester la chaîne. Pour une charge lourde et continue, ou lorsqu’un projet exige un accès physique particulier, un Mac détenu et administré en interne peut être plus approprié.

La location ne remplace ni la vérification de l’émetteur ni une politique de gestion des clés. Elle peut toutefois apporter une solution lorsqu’il manque un environnement macOS pour vérifier le certificat de remplacement et refaire l’acceptation d’un paquet. Avant de choisir, comparez les besoins de contrôle, la durée d’utilisation, la confidentialité des secrets et la disponibilité requise ; les offres de location Mac d’ArmMacs permettent d’examiner cette option, tandis que l’assistance Mac d’ArmMacs peut être consultée pour préciser les questions liées à l’environnement.

La prochaine action n’est donc pas de resigner tous les fichiers par précaution : recensez les émetteurs et les livrables, distinguez l’application du .pkg, puis testez la nouvelle identité sur une tâche isolée. Si votre équipe ne dispose pas d’un Mac pour la signature et l’installation de validation, un Mac loué peut être plus simple qu’un poste local à acheter et à maintenir ; si la charge est permanente ou nécessite un contrôle matériel particulier, privilégiez une machine interne et formalisez sa gestion des clés.