La Developer ID Certification Authority expire le 1er février 2027

Apple a annoncé le 1er octobre 2026 que la Developer ID Certification Authority d’origine expire le 1er février 2027, et que les paquets d’installation signés avec un certificat qu’elle a émis « will no longer install » (ne s’installeront plus) à partir de cette date. Les apps notarisées sont épargnées : « Previously signed and notarized Mac software (with a secure timestamp) will keep working. » (Les logiciels Mac déjà signés et notarisés, avec un horodatage sécurisé, continueront de fonctionner.)¹ L’autorité qui la remplace, G2, émet des certificats depuis le 27 janvier 2022, mais Apple a continué de proposer celle d’origine aux équipes restées sur d’anciennes versions de Xcode, si bien qu’une équipe peut détenir un certificat de chacune.²³ Le critère d’Apple est l’Organizational Unit dans le nom de l’émetteur du certificat, et non la date d’expiration.

Vous trouverez ci-dessous les commandes qui lisent cette information dans un trousseau, un paquet et une app ; ce qu’elles affichent pour les 66 apps Developer ID et les quatre installeurs de mon propre Mac, où 49 apps et les quatre installeurs remontent à l’autorité qui expire ; une phrase de l’avis d’Apple que les certificats que je peux examiner ne confirment pas ; et l’ordre dans lequel je signerais à nouveau.⁴

En bref

• La date. Le certificat de l’autorité d’origine prend fin le 1er février 2027 à 22:12:15 UTC, quinze ans à la seconde près après son entrée en vigueur. Apple : « Certificates issued by this authority will stop working on that date. » (Les certificats émis par cette autorité cesseront de fonctionner à cette date.)¹⁴
• Les paquets s’arrêtent, pas les apps notarisées. « .pkg files signed with an affected certificate will no longer install » (les fichiers .pkg signés avec un certificat concerné ne s’installeront plus), tandis que les logiciels notarisés dotés d’un horodatage sécurisé « will keep working » (continueront de fonctionner).¹
• Lisez l’émetteur. L’Organizational Unit de l’émetteur vaut « Apple Certification Authority » sur un certificat de l’autorité d’origine et « G2 » sur un certificat de l’autorité actuelle. Selon Apple, la date d’expiration « doesn’t prove which authority issued a certificate » (ne prouve pas quelle autorité a émis un certificat).²
• L’échantillon d’un seul Mac. Les quatre installeurs signés Developer ID de mon dossier Téléchargements remontent tous à l’autorité d’origine, le plus récent ayant été signé le 29 décembre 2025. Sur les 66 apps Developer ID de mon dossier Applications, 49 remontent à elle et 17 à G2.⁴
• Jusqu’ici, l’expiration n’a pas arrêté les logiciels horodatés. Six de ces 49 apps sont signées avec des certificats expirés entre 2022 et mai 2026, et un installeur avec un certificat expiré en 2017. Gatekeeper accepte les sept aujourd’hui. Selon l’avis d’Apple, l’expiration de l’autorité elle-même met fin à cette tolérance pour les paquets.¹⁴
• Une discordance. Apple affirme que les certificats G2 « expire annually » (expirent chaque année). Les 12 certificats G2 de mes apps installées, ainsi que le mien de mai 2026, sont valables cinq ans. Aucune des deux pages ne dit quand la durée d’un an a commencé à s’appliquer.¹²⁴

Qu’a annoncé Apple ?

L’avis est court. Il commence ainsi : « The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date. » (La Developer ID Certification Authority d’origine, une Sub-CA, expire le 1er février 2027. Les certificats émis par cette autorité cesseront de fonctionner à cette date.)¹ Suivent trois étapes : vérifier si vous êtes concerné, créer un nouveau certificat et signer à nouveau. La troisième étape dépend de ce que vous distribuez :

• Paquets d’installation. « Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date. » (À partir du 1er février 2027, les fichiers .pkg signés avec un certificat concerné ne s’installeront plus. Signez à nouveau tous vos paquets avec votre nouveau certificat avant cette date.)
• Apps Mac. « Previously signed and notarized Mac software (with a secure timestamp) will keep working » (les logiciels Mac déjà signés et notarisés, avec un horodatage sécurisé, continueront de fonctionner), sans action requise, et « For future updates, sign with your new certificate and include a secure timestamp for notarization. » (Pour les futures mises à jour, signez avec votre nouveau certificat et ajoutez un horodatage sécurisé en vue de la notarisation.)¹

La page d’aide vers laquelle renvoie l’avis décrit l’effet sur la signature : « After that date, certificates issued from the original authority can no longer be used for signing and must be replaced with certificates from the current Developer ID Certification Authority (G2). » (Après cette date, les certificats émis par l’autorité d’origine ne pourront plus servir à signer et devront être remplacés par des certificats de l’actuelle Developer ID Certification Authority, G2.) Elle indique aussi « Required role: Account Holder. » (Rôle requis : Account Holder.)²

Cette distinction entre apps et paquets est proche des consignes habituelles d’Apple sur les certificats expirés. Pour les apps, la page d’aide Developer ID d’Apple indique : « As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate. » (Tant que votre certificat Developer ID était valide au moment où vous avez compilé votre app, les utilisateurs peuvent la télécharger et l’exécuter, même après la date d’expiration du certificat.) Pour les installeurs, les pages d’Apple ne concordent pas, ni entre elles ni avec elles-mêmes. La même page d’aide affirme : « Your installer package will only launch if your Developer ID Installer certificate is valid. » (Votre paquet d’installation ne se lancera que si votre certificat Developer ID Installer est valide.) L’entrée Developer ID Installer de la vue d’ensemble des certificats tire dans les deux sens : les utilisateurs « can still install packages that were signed with this certificate as long as the package includes a trusted timestamp » (peuvent toujours installer les paquets signés avec ce certificat tant que le paquet comporte un horodatage de confiance), et pourtant, deux phrases plus loin, « new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate » (aucune nouvelle installation ne sera possible tant que vous n’aurez pas signé à nouveau votre paquet d’installation avec un certificat Developer ID Installer valide).⁵ L’avis du 1er octobre n’accorde aux paquets aucune exception liée à l’horodatage.

L’avis ne parle que d’installation. Il ne dit pas ce qu’il advient des logiciels déjà installés à partir d’un paquet concerné, ni si les installations poussées par la gestion des appareils ou lancées avec la commande installer sont traitées comme un paquet qu’un utilisateur ouvre. Il ne mentionne pas non plus les images disque signées. Sur le premier point, l’entrée de la vue d’ensemble consacrée à un certificat d’installeur expiré indique « Previously installed apps will continue to run. » (Les apps déjà installées continueront de fonctionner.)¹⁵

Pourquoi y a-t-il deux autorités ?

Un certificat ne peut pas survivre à l’autorité qui l’a émis. La page d’assistance d’Apple de 2022 en fait une règle : « Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date. » (Aucun certificat ne peut être émis avec une période de validité qui dépasse la date d’expiration du certificat intermédiaire.)³ Tous les certificats Developer ID antérieurs à 2022 que je peux trouver sont valables cinq ans ; à partir de février 2022, l’autorité d’origine, à qui il restait cinq ans, ne pouvait donc plus en émettre un pour une durée complète. La réponse d’Apple a été une seconde autorité : « Starting January 27, 2022, the digital certificates you use to sign your software and installer packages on macOS will be issued from the new Developer ID intermediate certificate that expires on September 16, 2031. » (À partir du 27 janvier 2022, les certificats numériques qui vous servent à signer vos logiciels et paquets d’installation sur macOS seront émis par le nouveau certificat intermédiaire Developer ID, qui expire le 16 septembre 2031.) (Le certificat lui-même prend fin le 17 septembre 2031 à 00:00:00 GMT, ce qui correspond encore au 16 septembre à l’heure du Pacifique.)³⁴

L’autorité d’origine est restée disponible. Pour les équipes « running Xcode 11.4 or earlier » (utilisant Xcode 11.4 ou une version antérieure), Apple écrivait : « the Apple Developer website will continue to offer Developer ID certificates associated with the original intermediate certificate. Newly issued certificates from this intermediate certificate will be valid for less than five years » (le site Apple Developer continuera de proposer des certificats Developer ID associés au certificat intermédiaire d’origine ; les certificats nouvellement émis par ce certificat intermédiaire seront valables moins de cinq ans), une option qui « will be available for at least one year, starting January 27, 2022 » (restera disponible au moins un an à compter du 27 janvier 2022).³

Les certificats de mon Mac montrent les deux moitiés de cette histoire. Les 49 apps qui remontent à l’autorité d’origine portent 27 certificats de signature distincts. Les cinq émis avant février 2022 sont chacun valables cinq ans. Les 22 émis à partir du 8 février 2022 prennent tous fin à la même seconde, le 1er février 2027 à 22:12:15 UTC, qui est la dernière seconde de l’autorité elle-même, et le plus récent a été émis le 15 janvier 2026. Près de quatre ans après l’arrivée de G2, l’autorité d’origine émettait donc encore des certificats, chacun plus court que le précédent.⁴

Comment savoir quelle autorité a émis mon certificat ?

La page d’aide d’Apple commence par le portail développeur : « Any certificates expiring on or before February 1, 2027, are likely affected. However, the expiration date alone doesn’t prove which authority issued a certificate. » (Tout certificat expirant le 1er février 2027 ou avant est probablement concerné. Toutefois, la date d’expiration seule ne prouve pas quelle autorité a émis un certificat.) La raison avancée : « A team can hold a certificate from each authority with identical names, such as the same Developer ID Installer entry twice, differing only in expiration date. » (Une équipe peut détenir un certificat de chaque autorité sous des noms identiques, par exemple deux fois la même entrée Developer ID Installer, qui ne diffèrent que par leur date d’expiration.) Le test d’Apple se fait dans Keychain Access : sélectionnez le certificat, puis « expand the Issuer Name field, and review the Organizational Unit field » (développez le champ du nom de l’émetteur et examinez le champ Organizational Unit, c’est-à-dire l’unité d’organisation). « Apple Certification Authority » signifie « The certificate was issued from the previous Sub-CA. Replace this certificate. » (Le certificat a été émis par la Sub-CA précédente. Remplacez-le.) « G2 » signifie « The certificate was issued from the current Sub-CA. No action needed. » (Le certificat a été émis par la Sub-CA actuelle. Aucune action requise.) La page ajoute une mise en garde : « Check your own certificate, not the Developer ID Certification Authority entry in your keychain. That entry is the authority itself, and it’s issued by Apple Root CA, whose Organizational Unit is also Apple Certification Authority. » (Vérifiez votre propre certificat, et non l’entrée Developer ID Certification Authority de votre trousseau. Cette entrée est l’autorité elle-même ; elle est émise par Apple Root CA, dont l’Organizational Unit est elle aussi Apple Certification Authority.)²

Le même test s’exécute depuis un terminal, à trois endroits.

Un certificat dans votre trousseau.

security find-certificate -a -c "Developer ID Installer" -p \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

L’option -a renvoie toutes les correspondances, ce qui compte à cause de l’avertissement d’Apple sur les noms identiques, et le pipeline affiche une ligne subject et une ligne issuer pour chacune. Remplacez par « Developer ID Application » pour le certificat de signature d’apps. Mon Mac contient un certificat Developer ID Application et aucun certificat Installer ; avec le /usr/bin/openssl du système, sa ligne issuer se lit issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. OpenSSL 3 de Homebrew affiche les mêmes champs séparés par des virgules. Un nom sans correspondance n’affiche rien.⁴

Un paquet que vous avez distribué.

pkgutil --check-signature YourProduct.pkg

La sortie indique l’état de la signature, l’état de la notarisation, l’horodatage de confiance et la chaîne de certificats. La date à lire est celle qui figure sous la deuxième entrée, « Developer ID Certification Authority ». Sur chacun de mes quatre installeurs, on y lit Expires: 2027-02-01 22:12:15 +0000. Le certificat de G2 lui-même prend fin le 17 septembre 2031 (GMT) ; un paquet signé sous G2 devrait donc afficher cette date à cet endroit. Je n’ai aucun paquet signé sous G2 pour le confirmer.⁴

Une app. codesign -dvv ne suffit pas à lui seul, car les deux autorités partagent le même nom commun et ses lignes Authority= se lisent de la même façon pour l’une comme pour l’autre. Extrayez la chaîne et lisez le certificat intermédiaire :

codesign -d --extract-certificates=/tmp/chain. YourApp.app
openssl x509 -inform DER -in /tmp/chain.1 -noout -subject -enddate

Sur une app signée sous G2 de mon dossier Applications, la seconde commande affiche OU=G2 dans le subject et notAfter=Sep 17 00:00:00 2031 GMT. Sur une app signée sous l’autorité d’origine, elle affiche OU=Apple Certification Authority et notAfter=Feb 1 22:12:15 2027 GMT.⁴

Que montrent les logiciels d’un seul Mac ?

Installeurs. Mon dossier Téléchargements contient quatre paquets signés Developer ID, issus de deux éditeurs, et les quatre remontent à l’autorité d’origine. Trois viennent d’un même éditeur, signés les 28 septembre, 14 décembre et 29 décembre 2025 avec un certificat d’installeur émis le 13 avril 2022 et valable jusqu’au 1er février 2027. Cet éditeur signait donc encore des paquets sous l’autorité d’origine il y a neuf mois. Le quatrième a été signé en février 2014 avec un certificat expiré le 29 mars 2017.⁴

L’évaluation d’installation de Gatekeeper, spctl -a -t install -vv, accepte aujourd’hui les quatre comme « Notarized Developer ID », y compris celui dont le certificat de signature a expiré il y a neuf ans. Ce résultat concorde avec la phrase sur l’horodatage de confiance de l’entrée consacrée aux installeurs dans la vue d’ensemble des certificats, mais pas avec la phrase « new installations won’t be possible » (aucune nouvelle installation ne sera possible) de cette même entrée, ni avec la page d’aide Developer ID. C’est aussi précisément le comportement auquel, selon l’avis d’Apple, il est mis fin pour les paquets le 1er février. Je ne peux pas tester février depuis octobre : ce qui se passera ce jour-là relève donc de la déclaration d’Apple, pas de mon observation.¹⁴⁵

Apps. Parmi les 66 apps de mon dossier Applications signées Developer ID, 49 remontent à l’autorité d’origine et 17 à G2. Les 66 signatures portent toutes un horodatage sécurisé. Gatekeeper en signale 63 comme « Notarized Developer ID », soit la combinaison qui, selon Apple, continue de fonctionner : 46 des 49 sous l’autorité d’origine et les 17 sous G2. Des trois autres, toutes sous l’autorité d’origine, deux échouent à l’évaluation avec « a sealed resource is missing or invalid », une erreur qui porte sur le contenu du bundle, et une, signée en juillet 2018, est acceptée comme Developer ID sans notarisation. La phrase d’Apple couvre les logiciels notarisés, et l’avis ne dit pas ce qu’il adviendra d’une app comme cette dernière.¹⁴

Six des 49 sont signées avec des certificats déjà expirés au 1er octobre 2026, le plus ancien en août 2022 et le plus récent en mai 2026. Gatekeeper accepte les six, dont cinq comme notarisées. La règle d’Apple pour les apps, selon laquelle un certificat valide au moment de la signature suffit, joue donc déjà sur des logiciels que j’utilise.⁴⁵

Quelle phrase de l’avis ne concorde pas ?

L’avis dit de G2 : « This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year. » (Cette autorité de certification est valable jusqu’en 2031, mais les certificats qu’elle émet expirent chaque année et doivent être renouvelés annuellement.) La page d’aide dit la même chose : « Certificates issued from G2 are valid for one year and must be renewed annually. » (Les certificats émis par G2 sont valables un an et doivent être renouvelés chaque année.)¹²

Les certificats G2 que je peux examiner ne sont pas des certificats d’un an. Les 17 apps signées sous G2 sur mon Mac portent 12 certificats de signature distincts, émis entre février 2023 et le 29 mai 2026, et chacun est valable cinq ans. Trois d’entre eux ont été émis en avril et mai 2026. Mon propre certificat Developer ID Application, émis le 10 mai 2026, prend fin le 11 mai 2031.⁴

Aucune des deux pages ne dit quand la validité d’un an a commencé, et je n’ai pas créé de certificat depuis l’avis : je ne peux donc pas dire avec quelle durée revient un certificat émis aujourd’hui. Prévoyez un renouvellement annuel, et lisez les dates du certificat que vous recevez réellement. Si les certificats d’un an deviennent désormais la règle, le désaccord entre les pages d’Apple, et au sein même de l’entrée de la vue d’ensemble, au sujet des certificats d’installeur expirés prend plus d’importance : si la phrase sur l’horodatage de confiance tient, un paquet survit à son certificat ; si ce sont les autres qui tiennent, il n’y survit pas. Mon seul point de donnée est le paquet de 2014 évoqué plus haut, que Gatekeeper accepte toujours. Le poids relatif de ces phrases relève de ma lecture, non de celle d’Apple.

Que ferais-je, et dans quel ordre ?

1. Inventaire. Lancez la vérification du trousseau pour les deux types de certificat, et pkgutil --check-signature sur chaque paquet que vous proposez encore au téléchargement, anciennes versions comprises. La vérification des paquets fonctionne aussi sur les installeurs d’autres éditeurs : c’est ainsi que vous repérerez ceux que votre équipe déploie et pour lesquels il vous faudra un build signé à nouveau par l’éditeur.
2. Remplacement. Si un émetteur affiche « Apple Certification Authority », créez un certificat G2. D’après les étapes de la page d’aide, si l’on vous demande de sélectionner un « Developer ID Certificate Intermediary » (intermédiaire de certificat Developer ID), choisissez « G2 Sub-CA (Xcode 11.4.1 or later) », car « Any other option might issue a certificate from the expiring Certificate Authority » (toute autre option pourrait émettre un certificat de l’autorité de certification qui expire), et l’avis prévient que « Choosing another option may issue a certificate that also expires in 2027 » (choisir une autre option peut produire un certificat qui expire lui aussi en 2027). Si vous détenez les deux types, « repeat these steps for each, since one certificate does not cover the other » (répétez ces étapes pour chacun, car un certificat ne couvre pas l’autre). L’avis ajoute une condition préalable : « If you’re using Xcode 11.4 or earlier, update before creating your new certificate. » (Si vous utilisez Xcode 11.4 ou une version antérieure, mettez-le à jour avant de créer votre nouveau certificat.)¹²
3. Tester avant que l’ancien ne disparaisse. Apple : « Because you can hold up to five Developer ID Application and five Developer ID Installer certificates at a time, you can create and test a replacement before your current certificate expires. » (Comme vous pouvez détenir jusqu’à cinq certificats Developer ID Application et cinq certificats Developer ID Installer à la fois, vous pouvez créer et tester un remplaçant avant l’expiration de votre certificat actuel.)²
4. Signer à nouveau les paquets. Le manuel de productsign indique : « If you run productsign on a product archive that was previously signed, the existing signature will be replaced » (si vous lancez productsign sur une archive produit déjà signée, la signature existante sera remplacée), et précise qu’un horodatage de confiance « is enabled by default when signing with a Developer ID identity » (est activé par défaut lors d’une signature avec une identité Developer ID). L’outil intègre aussi « any intermediate certificates that are found in the keychain » (tout certificat intermédiaire trouvé dans le trousseau) ; le certificat intermédiaire G2 doit donc d’abord se trouver dans le trousseau (l’option --cert du manuel désigne un intermédiaire par son nom commun, que les deux autorités partagent ; je ne compterais donc pas sur elle pour choisir entre les deux) : selon la page d’Apple de 2022, Xcode 13.2 ou ultérieur le télécharge automatiquement, et sinon « you can download it from the Certificate Authority page » (vous pouvez le télécharger depuis la page Certificate Authority). Le pipeline de trousseau ci-dessus, lancé avec le nom « Developer ID Certification Authority », liste les autorités présentes sur un Mac ; le mien affiche les deux. Ensuite, notarisez et agrafez (staple) de nouveau le résultat. L’étape de notarisation relève de ma lecture et non d’une phrase d’Apple : un paquet signé à nouveau est un autre fichier. Je ne détiens aucun certificat Developer ID Installer, je n’ai donc pas exécuté cette étape.³⁴
5. Vérifier le résultat. pkgutil --check-signature sur le fichier signé à nouveau ne devrait plus afficher la date de 2027 sous l’autorité, et spctl -a -t install -vv devrait toujours indiquer « Notarized Developer ID ».
6. Garder des signatures d’apps horodatées. L’horodatage sécurisé est la propriété qu’Apple cite pour les logiciels qui continuent de fonctionner, et sa consigne pour la suite est de « sign with your new certificate and include a secure timestamp for notarization » (signer avec votre nouveau certificat et ajouter un horodatage sécurisé en vue de la notarisation).¹

Cette échéance est le deuxième changement de la saison qui touche les installeurs. Le premier se trouve dans macOS 27 lui-même, où un paquet qui ne nomme aucune architecture hôte passe désormais par défaut à arm64 ; l’article sur Golden Gate précise quels paquets sont concernés, et une équipe qui signe de toute façon ses installeurs à nouveau peut vérifier les deux en une seule passe. L’article sur les notes de version de macOS 27 couvre le reste de cette version pour les développeurs Mac, l’article sur Xcode 27 et l’article sur Intel traitent de la chaîne d’outils, l’article sur l’accès aux conteneurs entre équipes décrit un changement qui fait échouer des apps Mac déjà distribuées au moment de la lecture, sans aucune invite, et l’article sur ld64 couvre deux changements de la chaîne d’outils qui bloquent des builds Mac.

FAQ

Quand la Developer ID Certification Authority expire-t-elle ?

Le 1er février 2027. Le certificat de l’autorité d’origine prend fin ce jour-là à 22:12:15 UTC. L’autorité actuelle, G2, prend fin en septembre 2031 ; la page d’assistance d’Apple indique le 16 septembre, et le certificat lui-même affiche le 17 septembre à 00:00:00 GMT.¹³⁴

Mon app Developer ID cessera-t-elle de se lancer le 1er février 2027 ?

Apple répond non pour les logiciels notarisés et signés avec un horodatage sécurisé : ils « will keep working » (continueront de fonctionner), sans action requise. codesign -dvv YourApp.app affiche une ligne Timestamp= lorsque la signature en comporte un, et spctl -a -t exec -vv YourApp.app signale « source=Notarized Developer ID » pour une app notarisée.¹⁴

Qu’advient-il des installeurs .pkg signés sous l’autorité d’origine ?

Apple : « Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date. » (À partir du 1er février 2027, les fichiers .pkg signés avec un certificat concerné ne s’installeront plus. Signez à nouveau tous vos paquets avec votre nouveau certificat avant cette date.)¹

Comment vérifier quelle autorité a signé un paquet ?

Lancez pkgutil --check-signature dessus et lisez la date sous l’entrée « Developer ID Certification Authority » de la chaîne. Expires: 2027-02-01 22:12:15 +0000 correspond à l’autorité d’origine.⁴

Les certificats G2 durent-ils un an ou cinq ?

L’avis d’Apple et sa page d’aide disent tous deux un an. Chaque certificat G2 que j’ai pu examiner le 1er octobre 2026, dont le plus récent a été émis le 29 mai 2026, est valable cinq ans. Aucune des deux pages ne dit quand la durée d’un an a commencé.¹²⁴

Qui, dans l’équipe, peut créer le certificat de remplacement ?

La page d’aide indique « Required role: Account Holder. » (Rôle requis : Account Holder.)²

Sources