Que faire à l’expiration du certificat Developer ID en 2027 ? Liste de migration 2026

Un paquet .pkg signé avec un ancien certificat Developer ID risque de ne plus s’installer à l’échéance, alors qu’une app déjà notariée n’est pas automatiquement à resigner.

Décision rapide : vérifiez d’abord l’émetteur de chaque certificat dans votre compte développeur, puis traitez séparément les apps et les installateurs .pkg. Pour un paquet concerné, prévoyez une nouvelle signature avant la date limite ; pour une app déjà signée, notariée et horodatée, ne la resignez pas uniquement à cause de cette échéance. Apple a annoncé que l’ancienne sous-autorité arrive à expiration le 1er février 2027 ; la portée doit être confirmée sur vos certificats réels (annonce d’Apple).

Ce guide s’adresse aux développeurs qui distribuent une app macOS avec Developer ID et doivent préparer ses prochaines versions.
Il concerne aussi les équipes qui maintiennent des installateurs .pkg ou une machine de publication distante.
Le contrôle porte sur la chaîne de certification, le produit livré et l’identité utilisable par le compte de compilation.

Mis à jour le 2 octobre 2026 ; informations vérifiées à partir de l’annonce et des documents de certification d’Apple.

Chaîne de certification : ancienne sous-autorité ou G2

La date de péremption affichée sur un certificat ne suffit pas à savoir si cette échéance vous concerne. Le point décisif est sa chaîne de certification : Apple indique que l’ancienne Developer ID Certification Authority, ou Sub-CA, doit expirer le 1er février 2027 et que les certificats qu’elle a émis cesseront alors de fonctionner (annonce sur l’expiration de la Sub-CA). Il faut donc examiner chaque certificat employé pour signer, et non conclure que tous les certificats Developer ID sont concernés.

Dans le compte développeur, ouvrez les enregistrements de certificats et relevez, pour chaque identité utilisée en production, son type, son état, sa date d’expiration et son autorité émettrice. Comparez ces informations avec celles du trousseau sur la machine qui effectue réellement la signature. La documentation d’Apple sur le certificat intermédiaire Developer ID et la création de certificats Developer ID permet de vérifier les références à utiliser.

Comment déterminer si un certificat Developer ID dépend de l’ancienne Sub-CA ?
Ne vous fiez ni au nom de l’identité affiché dans un script ni à la seule date d’expiration. Confirmez l’autorité émettrice dans les détails du certificat du compte, puis vérifiez la chaîne présentée par le certificat installé sur la machine de publication. Si ces informations ne concordent pas, suspendez la migration automatisée et résolvez d’abord l’écart entre le compte et le trousseau.

Sur macOS, cette commande permet de lister les identités de signature disponibles pour le compte actif :

security find-identity -v -p codesigning

Le résultat attendu est une liste d’identités reconnues par le trousseau. Ce relevé ne prouve pas à lui seul que le certificat est issu de la bonne sous-autorité : il sert à vérifier la présence de l’identité et à repérer une entrée absente ou invalide. Pour examiner la chaîne et les usages du certificat, complétez l’inspection avec les détails du certificat dans le compte développeur et la documentation technique sur les certificats de signature de code.

Une identité visible dans le trousseau n’est pas une preuve de migration réussie. Il faut aussi vérifier que la clé privée correspondante est disponible pour le compte qui lance le processus de publication.

Produits distribués : application macOS ou paquet .pkg

Les conséquences annoncées diffèrent selon l’artefact. Un Mac App signé, notarié et muni d’un horodatage sécurisé peut continuer à fonctionner après l’échéance ; Apple recommande d’utiliser un nouveau certificat pour les versions ultérieures. En revanche, les .pkg signés par un certificat concerné ne pourront plus être installés à compter du 1er février 2027, selon l’annonce officielle. Ces limites ne justifient pas de resigner indistinctement tout le parc.

Quels Mac App sont concernés par l’expiration de l’ancienne sous-autorité ?
Pour une app déjà publiée, vérifiez le certificat qui a signé le produit réellement distribué, la présence de la notarisation et celle de l’horodatage sécurisé. Si les trois éléments correspondent aux conditions précisées par Apple, l’échéance ne signifie pas qu’il faut immédiatement refaire la signature de cette version. Pour une nouvelle version, basculez vers le nouveau certificat et vérifiez à nouveau l’artefact complet.

Une app déjà notariée et horodatée doit-elle être resignée ?
Pas uniquement en raison de cette expiration. Apple distingue la continuité de fonctionnement des logiciels déjà signés et notariés avec horodatage des signatures à employer pour les futures mises à jour. Une modification du contenu, une nouvelle livraison ou un autre problème de validation constitue une situation distincte, à traiter selon les contrôles habituels. La documentation Apple sur les conséquences des changements de certificats décrit les effets à examiner.

Developer ID Application et Developer ID Installer ne sont pas interchangeables. Le premier sert à signer l’application ; le second signe le paquet d’installation. Un développeur qui ne livre qu’une app peut ne pas avoir de .pkg à reconstruire. À l’inverse, un processus d’installation peut dépendre d’un certificat Developer ID Installer même si l’application contenue dans le paquet possède sa propre signature.

Quand faut-il resigner un .pkg signé avec Developer ID Installer ?
Le paquet dont le certificat est lié à l’ancienne Sub-CA doit être traité avant le 1er février 2027, date à laquelle Apple indique que ces paquets ne pourront plus être installés. La règle porte sur les paquets affectés ; elle ne permet pas de prédire sans test le comportement d’un canal de distribution, d’un outil de déploiement ou d’un système particulier. Il faut reconstruire le paquet avec le nouveau certificat, puis vérifier l’installation à partir du fichier réellement distribué.

Pour confirmer la signature d’un paquet, utilisez le fichier de livraison et non une copie intermédiaire :

pkgutil --check-signature Produit.pkg

Le contrôle doit identifier le certificat attendu et aboutir à une vérification de signature valide. Conservez le résultat avec le nom et la somme de contrôle du fichier contrôlé, afin de pouvoir relier la preuve au paquet mis à disposition. La commande ne remplace pas un test d’installation sur une machine de validation.

Identité de signature : certificat, clé privée et machine

Créer un certificat ne transfère pas automatiquement l’identité de signature sur toutes les machines. La partie publique du certificat et sa clé privée doivent être utilisables ensemble par le compte qui signe. Une identité peut apparaître dans le compte développeur, mais être inutilisable dans un processus exécuté sous un autre utilisateur ou dans un trousseau verrouillé.

La création d’un nouveau certificat doit suivre les indications actuelles d’Apple, notamment le choix de l’autorité et des certificats intermédiaires proposé dans le parcours de création. Apple documente la création du certificat Developer ID et les choix associés dans sa page d’assistance dédiée. Il ne faut pas imposer une sélection identique à tous les projets : les contraintes de compatibilité avec d’anciennes versions de Xcode ou de macOS doivent être contrôlées à partir de la documentation applicable au projet.

Voici un ordre de vérification qui limite les changements simultanés :

• Dans le compte développeur, relevez le type, l’émetteur et l’état du certificat destiné à remplacer l’ancien.
• Sur la machine de signature, vérifiez que l’identité apparaît dans le trousseau du compte qui exécute effectivement la compilation.
• Confirmez que cette identité inclut la clé privée correspondante et qu’elle est accessible au processus de signature.
• Dans les scripts et les tâches automatisées, repérez les identifiants de certificat figés, les sélections par empreinte et les références à des profils de trousseau.
• Produisez un artefact de test avec l’identité attendue, puis contrôlez sa signature plutôt que de vous limiter au résultat de la création du certificat.
• Stockez les preuves de validation en masquant les données sensibles ; ne publiez ni clé privée, ni mot de passe, ni jeton réutilisable.

Pour une app, cette vérification peut s’appuyer sur :

codesign -dv --verbose=4 Exemple.app

L’examen doit confirmer l’identité de signature attendue dans les détails de l’artefact. Ne copiez pas aveuglément une sortie d’exemple dans un rapport : gardez le résultat réel, associé au fichier testé, et éliminez les valeurs sensibles avant partage. La notarisation est un contrôle distinct de la signature locale ; le guide d’Apple sur la résolution des problèmes de notarisation aide à isoler un échec de notarisation d’un problème de certificat.

Acceptation de publication : résultat réel ou simple création du certificat

La migration est terminée seulement lorsque les produits finaux passent les contrôles pertinents. Un certificat créé dans le compte ne démontre ni que la clé privée est disponible sur la machine de compilation, ni que le script choisit la bonne identité, ni que le fichier livré s’installe. La procédure suivante sépare les indicateurs au lieu de transformer la migration en simple remplacement de fichier.

• Inventoriez les produits distribués. Distinguez les apps macOS, les paquets .pkg et les versions encore proposées au téléchargement. Pour chaque artefact, notez l’identité de signature et la machine qui l’a produit.
• Établissez la chaîne de chaque identité. Confrontez le certificat installé et son enregistrement dans le compte. Classez chaque entrée comme concernée, non concernée ou non vérifiée ; une information manquante ne doit pas être traitée comme une confirmation.
• Choisissez le type de certificat approprié. Associez Developer ID Application aux apps et Developer ID Installer aux paquets. Vérifiez les options de création et la compatibilité requise avant de mettre à jour les scripts.
• Préparez l’identité sur la machine cible. Assurez-vous que le certificat et la clé privée correspondante sont accessibles au compte de publication, y compris lorsque la signature est lancée à distance ou par une tâche automatisée.
• Produisez un artefact représentatif. Signez une version de test de l’app et un .pkg si le projet en distribue un. Enregistrez le nom du fichier, l’identité affichée par la vérification et la somme de contrôle.
• Validez séparément signature, notarisation et horodatage. Une signature correcte n’est pas une preuve de notarisation ; une notarisation réussie ne prouve pas que le paquet final s’installe. Les résultats doivent être reliés aux mêmes fichiers que ceux qui seront livrés.
• Testez le canal de livraison. Installez le .pkg final dans un environnement de validation et ouvrez l’app distribuée. Vérifiez aussi que le lien de téléchargement ou le mécanisme de mise à jour pointe vers le nouvel artefact.
• Décidez du sort des anciennes versions. Conservez l’ancien certificat tant qu’il reste nécessaire à l’historique ou aux opérations de transition, sans continuer à le sélectionner pour les nouveaux artefacts concernés. Ne resignez un paquet historique que si son usage futur le justifie et qu’un test confirme le résultat attendu.
• Documentez la décision. Pour chaque app ou paquet, consignez la chaîne, l’identité employée, les vérifications réalisées et la décision : conserver, migrer ou reconstruire. Une entrée « certificat créé » seule n’est pas un résultat de validation.

La distinction entre notarisation et horodatage mérite une attention particulière. La notarisation correspond à une vérification et à un enregistrement distincts ; l’horodatage appartient aux informations de signature. Il ne faut donc pas conclure qu’un nouveau certificat impose automatiquement de renotariser un ancien artefact, ni que le remplacement du certificat suffit à rendre valide une nouvelle version. Pour celle-ci, suivez le flux de publication du projet et contrôlez le résultat final conformément aux indications d’Apple.

Pour les petits collectifs, une machine distante peut aider à séparer les tâches de développement des opérations de signature, mais elle ne résout pas les erreurs de gestion des clés par elle-même. Le compte utilisé, les accès au trousseau, la conservation des journaux et l’absence de secrets dans les scripts restent à définir. Une configuration de Mac mini distant pour les opérations de publication peut être examinée lorsque le poste local n’est pas disponible en continu ; la décision dépend surtout de la maîtrise des accès et de la reproductibilité du processus.

Arbitrage final : conservation ou migration

La décision peut être prise artefact par artefact. Si la chaîne du certificat n’est pas celle de l’ancienne Sub-CA, l’annonce seule ne justifie pas une migration d’urgence ; conservez la preuve et suivez les prochaines mises à jour officielles. Si une app déjà distribuée est signée, notariée et horodatée dans les conditions annoncées, ne la resignez pas uniquement à cause de l’échéance, mais basculez les mises à jour vers la nouvelle identité. Si un .pkg est signé par le certificat concerné, reconstruisez-le, resignez-le et validez son installation avant la date annoncée.

Un poste local convient mieux si la signature est occasionnelle, si le matériel doit être directement accessible ou si les contraintes de sécurité interdisent l’externalisation des éléments de publication. Une chaîne entièrement automatisée convient aussi à une équipe qui dispose déjà d’un environnement maîtrisé et d’une procédure de rotation des identités. En revanche, un poste local réservé à la publication peut imposer des interruptions lorsqu’il est indisponible, concentrer les certificats et la clé privée sur une seule machine, et compliquer la répétition des tests par plusieurs membres de l’équipe.

Un Mac distant ne supprime pas ces risques : il faut toujours restreindre les comptes, protéger le trousseau et vérifier les artefacts. Il peut toutefois fournir un environnement macOS dédié, accessible pour préparer et valider des publications sans acheter un poste supplémentaire. Les critères de location et tarifs des Mac mini permettent d’évaluer cette option face à l’entretien d’un poste local ; elle est moins pertinente pour une charge soutenue nécessitant un accès physique permanent ou pour une équipe qui ne peut pas externaliser sa clé privée.

Pour une migration ponctuelle, le choix le plus prudent consiste à valider d’abord la chaîne et le type d’artefact, puis à tester la nouvelle identité sur le fichier réellement distribué. Si une machine macOS indépendante et contrôlable facilite cette validation, SFTPMAC peut être envisagé comme environnement de publication distant ; la clé privée, les droits d’accès et le mode de livraison doivent toutefois correspondre aux règles de sécurité de l’équipe.