Expiration de Developer ID G1 : comment migrer la signature des paquets d’installation Mac ? 2026

Pour l’expiration de Developer ID G1, vérifiez d’abord l’autorité qui a émis chaque certificat, puis remplacez par une identité G2 les signatures des paquets d’installation concernés avant la date limite. Ne traitez pas de la même façon les PKG et les applications déjà notarisées avec horodatage sécurisé. Cette démarche s’adresse aux équipes qui distribuent des logiciels macOS hors du Mac App Store et doivent sécuriser leurs publications sans interrompre une version déjà en service.

Cette analyse est destinée aux responsables de publication macOS qui doivent déterminer si leurs certificats Developer ID dépendent de G1.
Elle concerne aussi les ingénieurs CI/CD et les administrateurs IT chargés d’ajuster les trousseaux, de vérifier les PKG et d’organiser des essais isolés sur Mac.

Dernière mise à jour : 26 octobre 2026 ; informations vérifiées dans l’annonce Apple du 1er octobre 2026 sur l’expiration de l’autorité Developer ID et dans sa documentation sur le remplacement des certificats.

Certificat G1 et certificat individuel : deux échéances distinctes

Apple indique que l’ancienne autorité Developer ID Certification Authority, désignée ici comme G1, arrive à expiration le 1er février 2027. Les certificats émis par cette autorité ne pourront plus être utilisés à partir de cette date. Cela ne signifie pas que tous les certificats Developer ID ou tous les logiciels Mac deviendront simultanément invalides : le premier diagnostic porte sur la chaîne d’émission de chaque certificat, et non sur son seul nom affiché. L’annonce d’Apple précise aussi les catégories de logiciels concernées ; il faut donc éviter d’étendre cette règle à des certificats ou des artefacts qui n’y sont pas visés.

Dans le compte développeur, examinez les certificats Developer ID Application et Developer ID Installer encore utilisés par les équipes de publication. Une date d’expiration au plus tard le 1er février 2027 constitue un indice utile, mais ne suffit pas à prouver l’autorité qui a émis le certificat. Il faut contrôler l’émetteur. La procédure Apple de remplacement des certificats Developer ID décrit les vérifications à effectuer et la façon de demander une identité de remplacement.

Comment identifier l’autorité qui a émis un certificat Developer ID Installer ? Sélectionnez le certificat concerné dans l’accès au trousseau, puis développez le champ « Nom de l’émetteur » et examinez son unité organisationnelle. Apple indique que « Apple Certification Authority » correspond à l’ancienne sous-autorité, tandis que la mention « G2 » correspond à l’autorité actuelle. Ouvrez le certificat Developer ID de l’équipe, et non le certificat de l’autorité elle-même : ces éléments distincts appartiennent à des niveaux différents de la chaîne et peuvent prêter à confusion.

Pour éviter de confondre deux identités proches, consignez pour chaque certificat son type, son émetteur, son échéance, son équipe propriétaire et son usage dans les scripts de publication. Deux certificats Developer ID Installer peuvent avoir un nom visible similaire tout en dépendant d’autorités différentes. L’inventaire doit donc identifier le certificat effectivement sélectionné pendant la signature, pas seulement une identité qui apparaît dans l’interface.

Une vérification utile consiste à comparer les informations du certificat installé sur le poste de gestion avec celles présentes sur le nœud de construction. Si le certificat est créé ou renouvelé par une équipe, puis copié sur plusieurs environnements, l’inventaire doit aussi préciser où se trouve la clé privée correspondante et quelle tâche l’utilise. Cette précaution évite qu’un rapport de conformité reflète le certificat disponible sur un poste de travail, alors que la chaîne de production continue à utiliser une autre identité.

PKG, applications notarisées et mises à jour : des effets différents

La conséquence confirmée par Apple concerne les paquets d’installation .pkg signés avec un certificat émis par l’ancienne autorité : à partir du 1er février 2027, ces paquets ne pourront plus être installés. Les équipes doivent donc repérer les PKG encore distribués ou susceptibles d’être téléchargés depuis une ancienne page de publication, puis préparer leur nouvelle signature. Cette règle ne permet pas de conclure que tout ancien paquet ou toute distribution macOS est concerné : le lien avec le certificat affecté reste déterminant. Apple distingue également les rôles de Developer ID Application et de Developer ID Installer dans sa documentation sur les certificats Developer ID.

Quels paquets Mac risquent de ne plus s’installer après l’échéance ? Ceux dont la signature de l’installateur a été produite avec un certificat Developer ID Installer issu de G1. Le nom du fichier, sa date de mise en ligne ou la présence d’une application notarisée à l’intérieur ne remplacent pas la vérification de la signature du paquet. Une équipe qui ne possède plus le projet d’origine peut tout de même commencer par inventorier les artefacts distribués et examiner leur signature avant de décider lesquels doivent être reconstruits.

À l’inverse, Apple indique que les logiciels Mac déjà signés et notarisés, accompagnés d’un horodatage sécurisé, continueront de fonctionner. Pour les futures mises à jour de ces applications, il faut utiliser le nouveau certificat et inclure un horodatage sécurisé dans le processus de notarisation. Ces indications ne doivent pas être transposées automatiquement à tous les formats de distribution : pour une image disque, un téléchargement direct ou un autre artefact, vérifiez séparément sa signature et le parcours réel de distribution.

Une application Mac déjà notarisée doit-elle être resignée ? Selon la distinction publiée par Apple, une application déjà signée et notarisée avec un horodatage sécurisé peut continuer à fonctionner sans action immédiate liée à G1. En revanche, une nouvelle version doit être signée avec l’identité de remplacement appropriée. Cette réponse ne dispense pas d’examiner d’autres causes possibles d’échec, comme une révocation, une modification du contenu signé, un problème de notarisation ou une configuration propre à l’application.

Le tableau donne une orientation, pas un diagnostic automatique. Un installateur peut contenir une application dont la signature est correcte alors que la signature du PKG est liée à un certificat G1. À l’inverse, une application peut nécessiter une nouvelle signature pour une raison indépendante de l’échéance de l’autorité. L’équipe doit donc vérifier chaque niveau qu’elle signe, puis répéter les contrôles sur l’artefact effectivement remis aux utilisateurs.

Choix de G2 et pièges de sélection

Lors de la création d’un certificat de remplacement, choisissez explicitement « G2 Sub-CA » si le portail propose le choix de l’autorité intermédiaire. Apple avertit qu’une autre sélection peut produire un certificat rattaché à l’autorité qui expire en 2027. La mention « Developer ID » dans le nom du certificat ne suffit donc pas : après création et installation, vérifiez de nouveau l’émetteur. La procédure Apple de remplacement permet de contrôler les étapes de création et de remplacement.

La compatibilité de l’outillage constitue un point de contrôle distinct. Apple demande aux équipes qui utilisent Xcode 11.4 ou une version antérieure de mettre à jour avant de créer leur nouveau certificat. Sa documentation sur les certificats intermédiaires précise que G2 est pris en charge à partir de Xcode 11.4.1 ; les environnements plus anciens doivent donc faire l’objet d’une décision technique explicite, plutôt que d’un changement silencieux dans la chaîne de production. Avant toute modification, consignez la version de Xcode utilisée par chaque nœud concerné et vérifiez les exigences décrites dans la documentation Apple sur les certificats intermédiaires Developer ID.

Les erreurs de migration les plus courantes relèvent de vérifications incomplètes, et non d’un défaut que l’on pourrait attribuer à un outil sans diagnostic :

• l’équipe vérifie l’échéance, mais pas le champ de l’émetteur ;
• le certificat G2 est téléchargé, mais la clé privée correspondante n’est pas disponible sur le nœud de construction ;
• le certificat Developer ID Application est remplacé, mais le PKG continue d’être signé avec l’ancienne identité Developer ID Installer ;
• l’identité est changée sur un poste de travail, mais pas dans les scripts et les secrets de la chaîne CI ;
• la génération du paquet réussit, mais personne ne vérifie sa signature ni ne teste son installation.

Les certificats Developer ID Application et Developer ID Installer sont des types distincts. Lorsqu’une équipe utilise les deux, elle doit remplacer chacun de ceux qui est concerné, puis confirmer dans les journaux de contrôle quel certificat a effectivement été employé. Cette approche par artefact et par tâche de signature est plus fiable qu’une entrée générique intitulée « certificat Mac ».

Validation de la signature dans la chaîne CI

Une compilation réussie ne prouve pas que le bon certificat a signé le bon artefact. Pour accepter une migration de signature macOS, vérifiez l’identité chargée par le nœud, le certificat et sa chaîne, le résultat de signature, puis l’installation du paquet sur un environnement de test. Cette séparation importe particulièrement lorsqu’un pipeline assemble une application, la signe, la place dans un PKG, puis signe ce paquet avec un autre certificat.

Comment vérifier qu’un PKG utilise bien Developer ID Installer après le passage à G2 ? Examinez la signature du paquet avec pkgutil --check-signature, puis comparez l’identité affichée et la chaîne avec le certificat prévu pour la tâche. Apple documente cette commande pour inspecter la signature d’un installateur ; ce contrôle porte sur l’artefact, mais ne remplace pas le test de son installation sur un Mac représentatif. La documentation Apple sur les problèmes courants de notarisation présente également des outils et des contrôles utiles au diagnostic des artefacts signés.

Une validation reproductible peut suivre cette séquence :

1. Figer un cas de référence. Choisissez une version représentative de l’application et notez les artefacts publiés : application seule, PKG ou plusieurs formats. Conservez l’identifiant de construction et le résultat de la dernière publication validée.
2. Contrôler l’inventaire des certificats. Sur le compte et les nœuds concernés, associez chaque identité à son type, son émetteur et à la présence de la clé privée nécessaire. Écartez les certificats homonymes ou proches qui pourraient être sélectionnés par erreur.
3. Créer et installer les identités de remplacement. Demandez un certificat G2 de chaque type réellement utilisé, puis installez-le sur le nœud isolé. Si un ancien outil ne répond pas aux exigences indiquées par Apple, suspendez la migration de ce nœud jusqu’à ce qu’une solution compatible ait été testée.
4. Modifier la chaîne de signature de façon ciblée. Faites pointer explicitement les étapes qui signent l’application et le PKG vers les identités prévues. Vérifiez également que les scripts ne choisissent pas un certificat sur la base d’une correspondance partielle de nom.
5. Inspecter les artefacts. Utilisez codesign pour examiner et vérifier la signature de l’application, et pkgutil --check-signature pour inspecter celle du PKG. Apple documente aussi spctl comme moyen d’évaluer une application selon les règles système ; adaptez le contrôle au type de produit examiné.
6. Effectuer le parcours de publication pertinent. Pour l’application, vérifiez le processus de notarisation et l’horodatage sécurisé requis pour la distribution. Pour le PKG, installez le paquet généré sur un Mac de test et consignez l’issue, les éventuels messages d’échec et le certificat présenté.
7. Archiver les éléments d’acceptation. Conservez les sorties de vérification, la référence de construction, les empreintes des artefacts et l’identité de signature utilisée. Ne placez ni clé privée, ni mot de passe de trousseau, ni justificatif d’accès dans les journaux de compilation.

Le résultat livré, et pas seulement le fichier intermédiaire produit à l’étape de compilation, doit être contrôlé. Si la chaîne construit une application, la signe, crée un installateur et signe ensuite cet installateur, la vérification réussie du premier artefact ne prouve pas que la signature du paquet final est correcte. Inspectez la signature du PKG puis complétez ce contrôle par une installation effective du paquet de sortie.

La réussite du test doit aussi être définie à l’avance : le paquet doit pouvoir être installé dans l’environnement prévu, l’application doit s’ouvrir selon le parcours normal de l’équipe et les contrôles de signature doivent montrer l’identité attendue. Si un test est effectué sur un système qui conserve des données d’une installation antérieure, notez cette limite et répétez l’essai dans un environnement propre lorsque le résultat pourrait en dépendre. Sans cette précaution, une installation déjà présente peut masquer une erreur dans le nouvel artefact.

Environnement d’essai isolé et préparation des équipes

Un nœud Mac séparé du flux de production permet de tester la nouvelle identité, les scripts et les artefacts sans remplacer immédiatement le mécanisme de publication en service. Il faut toutefois distinguer cette recommandation opérationnelle des exigences officielles : Apple fixe la date d’expiration et différencie le traitement des PKG et des applications notarisées ; le choix d’un environnement isolé, la durée de coexistence des certificats et les critères de retour arrière relèvent de la politique de l’entreprise.

Dans un scénario concret, une équipe qui produit une application audio ou vidéo peut distribuer une application notarisée et proposer en parallèle un PKG à ses clients professionnels. La continuité de l’application déjà distribuée ne garantit pas que l’installateur restera utilisable après l’échéance : il faut contrôler la signature de chaque artefact, essayer l’installation du PKG signé avec G2, puis vérifier séparément la future mise à jour de l’application. Ce découpage est également utile aux équipes de conception qui livrent des outils de création : la vérification d’une application et celle de son installateur correspondent à deux étapes différentes de la livraison.

Pour préparer l’exploitation, définissez un responsable pour chaque certificat, documentez les pipelines qui l’utilisent et prévoyez une procédure de révocation ou de remplacement conforme à la gouvernance interne. La séparation des tâches réduit le risque qu’un développeur remplace une identité dans un trousseau local sans mettre à jour le nœud de publication. Pour cadrer les accès et la conservation des données sur un Mac distant, consultez les informations sur la confidentialité des données ; pour structurer les contrôles prépublication, les guides d’environnement Mac peuvent alimenter la revue d’équipe.

Aucune configuration de nœud, modalité de livraison ou performance d’environnement n’est présentée ici comme un résultat mesuré, car aucune donnée d’essai propre à cette migration n’a été fournie. Les équipes doivent valider leur propre version de Xcode, leurs clés, leur trousseau, leur format de paquet et leurs critères d’installation avant d’approuver le changement en production. Les résultats doivent être associés à l’artefact précis qui a été testé : une validation réussie sur une version ne démontre pas automatiquement le comportement d’un installateur construit ensuite avec d’autres dépendances ou scripts.

Décision de migration pour les équipes de publication

La décision tient à trois vérifications : le certificat utilisé est-il issu de G1, l’artefact est-il un PKG ou une application déjà signée et notarisée avec horodatage sécurisé, et la chaîne CI a-t-elle démontré que le bon certificat signe le résultat final ? Si un PKG dépend de G1, la voie prudente consiste à produire une version signée avec Developer ID Installer G2 et à vérifier son installation avant le 1er février 2027. Pour une application déjà notarisée avec horodatage sécurisé, Apple indique qu’elle continue de fonctionner ; les mises à jour futures doivent, elles, passer à la nouvelle identité.

Une chaîne de publication installée sur des postes dédiés peut éviter un changement d’infrastructure, mais elle concentre les clés, les dépendances et la maintenance sur le matériel de l’entreprise, tout en compliquant parfois la création d’un environnement d’essai séparé. Un service Mac distant n’est pas automatiquement le meilleur choix pour une charge permanente ou pour une équipe qui dépend d’une interface physique ; il peut néanmoins convenir lorsqu’il faut isoler temporairement la validation G2 sans réaffecter les machines de production. Pour ce besoin circonscrit, xcodeops peut être évalué comme environnement Mac à distance, avec des essais d’acceptation définis par l’équipe avant tout usage de publication. Les modalités de prise de contact permettent de vérifier si l’environnement proposé correspond au périmètre du test ; l’acceptation des signatures et des artefacts doit rester fondée sur les contrôles réalisés par l’équipe.