Le cas « certificat Apple Distribution expiré 2026 » se traite d’abord par un choix : vérifiez si le projet utilise la signature automatique Xcode ou la signature manuelle, puis seulement recréez les actifs nécessaires. Ne révoquez pas tous les certificats avant ce diagnostic. La signature automatique doit être testée avec le bon compte et la bonne équipe ; la signature manuelle exige un certificat valide, sa clé privée et un profil de provisioning cohérent.
Cette méthode convient aux responsables d’une mise à jour App Store proche, aux chefs de projet qui reprennent un dépôt après un changement de prestataire et aux administrateurs qui doivent fournir un Mac stable à une équipe de publication. Elle évite de confondre le compte Apple Developer Program, le certificat de distribution, le profil de provisioning et l’état de l’application dans App Store Connect.
[ SECTION_01 ] Le premier diagnostic : quatre objets distincts à ne pas mélanger
Une alerte de certificat n’indique pas nécessairement un problème de compte. Chaque élément intervient à un endroit différent de la chaîne :
- Apple Developer Program : le compte d’équipe, son adhésion et les rôles autorisés à gérer les ressources de signature ;
- Apple Distribution : l’identité utilisée pour signer une archive destinée à une distribution, notamment vers l’App Store ;
- profil de provisioning : le fichier qui relie l’identifiant de l’application, l’équipe et les conditions de signature ;
- App Store Connect : le service qui reçoit le build et l’associe à une application et à une version.
Apple décrit séparément les certificats de développement et de distribution dans sa documentation officielle sur les certificats. Une nouvelle signature ne répare donc pas une adhésion échue, un mauvais rôle ou une application sélectionnée par erreur dans App Store Connect.
Avant toute modification, l’équipe doit conserver :
- une capture floutée de l’alerte d’expiration ;
- le nom de l’équipe affiché par Xcode ;
- le mode de signature sélectionné dans la cible ;
- le message complet de compilation ou d’archivage ;
- l’identifiant de l’application et le numéro de version prévu.
Ces éléments permettent de comparer l’état avant et après la réparation. Ils évitent également qu’un prestataire supprime un actif encore utilisé par une autre branche ou par un autre produit.
Rappel important : un fichier de certificat
.cerne remplace pas une clé privée. Pour une signature manuelle, l’identité exploitable doit être présente dans le trousseau avec la clé privée correspondante. Un export protégé de type.p12peut être nécessaire lors d’une transmission autorisée, mais il ne doit pas être déposé sans protection dans un espace partagé.
[ SECTION_02 ] Première étape : choisir la bonne branche de récupération
Le choix se fait dans les réglages de signature du projet Xcode, et non à partir du seul nom du certificat.
Branche A : signature automatique
Si l’option de gestion automatique de la signature est active, vérifiez successivement :
- le compte Apple connecté dans Xcode ;
- l’équipe sélectionnée pour la cible ;
- l’identifiant d’application utilisé par le projet ;
- les droits du membre qui tente de créer l’archive ;
- la présence éventuelle d’un certificat géré dans le cloud.
Apple explique le fonctionnement des certificats gérés dans le cloud. Cette option peut simplifier la distribution lorsque l’organisation, le compte et les droits sont correctement configurés. Elle ne permet toutefois pas de contourner une équipe incorrecte, une autorisation absente ou un identifiant d’application mal renseigné.
Après la vérification, l’équipe doit lancer un nouvel Archive et ouvrir l’étape de distribution. Si Xcode propose une signature valide et que le contrôle de distribution passe, il est inutile de révoquer en masse les certificats existants.
Branche B : signature manuelle
Si le projet utilise des profils ou des certificats sélectionnés manuellement, la récupération comporte davantage de dépendances :
- un certificat Apple Distribution encore valide ;
- la clé privée associée ;
- un profil App Store Connect correspondant ;
- la bonne équipe ;
- le bon identifiant de l’application ;
- un Mac contenant les actifs nécessaires dans son trousseau.
La création d’un nouveau certificat n’actualise pas automatiquement tous les profils déjà téléchargés sur les postes de l’équipe. Le profil doit être vérifié, puis régénéré ou téléchargé à nouveau selon le cas. Apple détaille la création d’un profil App Store Connect et les opérations permettant de modifier ou télécharger les profils.
[ SECTION_03 ] Deuxième étape : reconstruire proprement une signature manuelle
La procédure suivante convient lorsqu’un certificat a réellement expiré et que la signature automatique n’est pas utilisée.
1. Identifier l’ancien actif avant de le remplacer
Notez le nom du certificat, le projet qui l’utilise, le responsable de la chaîne de publication et le Mac concerné. Cette trace est importante lorsqu’une entreprise possède plusieurs applications, plusieurs prestataires ou plusieurs pipelines de construction.
Il ne faut pas supprimer immédiatement tous les certificats visibles. Un autre projet peut encore dépendre d’un actif différent, et la suppression complique l’analyse si le problème initial venait seulement d’un profil obsolète.
2. Créer une nouvelle demande de signature si nécessaire
Lorsque le Mac ne possède pas l’identité attendue, créez une demande de signature de certificat depuis le trousseau. La procédure officielle de création d’un fichier CSR est décrite par Apple dans ce guide de demande de signature.
La demande doit être créée par le responsable autorisé, sur le Mac destiné à construire l’application ou dans un environnement sécurisé prévu pour cette fonction. Le point essentiel est la conservation de la clé privée créée avec la demande. Sans elle, le certificat téléchargé ensuite ne permettra pas de signer les archives.
3. Créer le certificat de distribution
Dans l’espace Apple Developer, sélectionnez le type de certificat de distribution approprié à la méthode de publication. Vérifiez l’équipe et l’usage avant de valider.
Après téléchargement, ouvrez le certificat sur le Mac prévu pour la construction. Dans le trousseau, recherchez une association entre le certificat et sa clé privée. Si le certificat apparaît seul, la réparation n’est pas terminée.
4. Régénérer le profil de provisioning
Le nouveau certificat doit être pris en compte par le profil. Modifiez ou recréez le profil App Store Connect avec le bon identifiant d’application et la bonne équipe, puis téléchargez-le sur le Mac.
Dans Xcode, contrôlez ensuite les réglages de signature de la cible. Le nom affiché peut être proche de l’ancien, mais l’archive doit réellement utiliser le nouveau certificat et le nouveau profil. Une simple présence du fichier dans le dossier de téléchargement ne constitue pas une preuve.
5. Réinstaller les actifs sur le Mac de construction
Installez le certificat et le profil sur le Mac qui produira l’archive. Vérifiez le trousseau de la session réellement utilisée par Xcode, surtout lorsque la construction est lancée par un compte différent de celui qui a réalisé l’installation.
Après cette étape, fermez et rouvrez Xcode si l’identité n’apparaît pas immédiatement. Le projet doit ensuite être nettoyé avec prudence : le nettoyage peut éliminer des artefacts locaux, mais il ne corrige pas une équipe mal sélectionnée ou une clé privée absente.
6. Faire un Archive avant tout envoi
Lancez une archive avec le même schéma que celui prévu pour la mise à jour. Ouvrez le contrôle de distribution et observez le résultat de la signature.
Un échec à ce stade est utile : il reste localisé dans la chaîne de signature. En revanche, si l’archive passe mais que l’envoi échoue, il faut conserver les détails et déplacer l’analyse vers App Store Connect, les droits, le numéro de version ou le traitement du build.
[ SECTION_04 ] Changement de Mac et transmission à un prestataire
Après un changement de Mac, l’erreur la plus fréquente est de transférer uniquement un certificat. La clé privée reste alors sur l’ancien trousseau. Le nouveau poste peut afficher un certificat installé, tout en étant incapable de signer une archive.
Si l’ancien Mac est encore accessible, la transmission doit suivre une procédure contrôlée :
- confirmer le projet et l’équipe concernés ;
- vérifier que le certificat possède sa clé privée ;
- exporter l’identité uniquement avec une protection forte et approuvée ;
- transmettre le fichier par un canal réservé à cette opération ;
- importer l’identité dans le trousseau du Mac de construction ;
- supprimer les copies temporaires après vérification ;
- lancer un Archive de test et conserver le journal.
Le mot de passe du compte Apple, le compte administrateur du Mac et une clé privée non protégée ne doivent jamais être partagés dans une conversation d’équipe. Les rôles disponibles dans l’équipe doivent également être contrôlés avec la table officielle des rôles Apple Developer.
Si la clé privée n’existe plus sur aucun poste accessible, le téléchargement d’un nouveau fichier .cer ne résoudra pas la situation. Un membre disposant des droits requis doit créer une nouvelle identité, régénérer le profil et refaire la validation sur un Mac maîtrisé.
[ SECTION_05 ] Les erreurs qui apparaissent après la création du certificat
Une restauration incomplète se reconnaît généralement à la catégorie du message :
- la vérification de signature échoue dans Xcode : examinez le certificat, la clé privée, le trousseau actif et l’équipe ;
- le profil est invalide : vérifiez son lien avec le nouvel identifiant de signature et l’identifiant de l’application ;
- la mauvaise équipe est utilisée : comparez l’équipe affichée dans Xcode avec celle du compte qui possède l’application ;
- le build est envoyé mais n’apparaît pas : conservez le journal et vérifiez le traitement dans App Store Connect avant de recréer des certificats.
Pour l’envoi, utilisez le flux de distribution Xcode ou une méthode officiellement prise en charge. Apple décrit les étapes d’envoi d’un build depuis Xcode, tandis que la documentation App Store Connect précise le contrôle des builds téléversés.
À partir du moment où l’erreur se déplace vers la version, les autorisations, la conformité ou le traitement du build, il faut arrêter de reconstruire les certificats. Le problème n’est plus nécessairement cryptographique.
[ SECTION_06 ] Questions fréquentes sur la récupération
Une application peut-elle encore recevoir une mise à jour après l’expiration du certificat Apple Distribution ?
Oui, l’expiration du certificat ne signifie pas automatiquement que l’application publiée disparaît de l’App Store. La nouvelle version doit toutefois être signée avec une identité valide et envoyée depuis l’équipe correcte. Vérifiez aussi l’adhésion au Apple Developer Program, car un certificat valide ne remplace pas un compte sans droits opérationnels.
La signature automatique de Xcode renouvelle-t-elle toujours le certificat ?
Non. Elle peut utiliser des certificats gérés dans le cloud lorsque le projet, le compte, l’équipe et les permissions conviennent. Elle ne corrige pas une mauvaise équipe ni une autorisation manquante. Le seul contrôle fiable consiste à produire un nouvel Archive et à vérifier le contrôle de distribution, plutôt qu’à se fier à l’absence d’une alerte locale.
Que faire avec un certificat sans clé privée ?
Contrôlez le trousseau du Mac d’origine. Si le certificat n’est pas associé à sa clé privée, il ne suffit pas pour une signature manuelle. Lorsque l’ancien poste reste disponible, l’équipe peut organiser une exportation protégée. Sinon, la personne autorisée doit créer une nouvelle demande de signature et une nouvelle identité de distribution.
Pourquoi le profil reste-t-il invalide après la création d’un certificat ?
Le profil téléchargé peut encore référencer l’ancien certificat ou la mauvaise équipe. Il peut également cibler un identifiant d’application différent de celui de la cible Xcode. Régénérez le profil après la création du certificat, installez-le sur le Mac de construction, puis vérifiez la sélection effective dans les réglages de signature.
Comment récupérer la signature après un changement de Mac ?
Commencez par déterminer si la signature est automatique ou manuelle. Dans le second cas, recherchez le couple certificat-clé privée dans le trousseau, puis réinstallez le profil correspondant. Si la clé privée est perdue, le nouveau Mac ne peut pas récupérer magiquement l’ancienne identité : une nouvelle création et un nouvel Archive sont nécessaires.
[ SECTION_07 ] La recette d’acceptation avant la publication
La personne responsable de la livraison peut utiliser la liste suivante avec le technicien ou le prestataire :
- [ ] L’équipe sélectionnée dans Xcode correspond à celle qui possède l’application.
- [ ] Le compte Apple utilisé possède les droits nécessaires pour gérer ou employer les actifs de signature.
- [ ] Le mode automatique ou manuel est documenté dans le dossier du projet.
- [ ] En signature manuelle, le certificat est associé à sa clé privée dans le trousseau.
- [ ] Le profil de provisioning correspond à l’identifiant de l’application et au nouveau certificat.
- [ ] Le projet produit un Archive avec le schéma prévu pour la distribution.
- [ ] Le contrôle de signature de l’Archive ne signale plus l’actif expiré.
- [ ] Le build est envoyé avec le flux Xcode ou la méthode approuvée par Apple.
- [ ] App Store Connect reconnaît la bonne application et la bonne version.
- [ ] Le journal d’upload et le statut du build sont conservés.
- [ ] Aucun mot de passe, fichier
.p12non protégé ou identifiant administrateur n’est placé dans un document partagé. - [ ] Le responsable de la prochaine vérification et l’emplacement sécurisé des matériaux sont documentés.
Cette liste distingue la réparation technique de la remise opérationnelle. Une archive valide ne suffit pas si personne ne sait quel Mac, quel rôle et quelle identité seront utilisés pour la prochaine version.
[ SECTION_08 ] Comparaison des environnements pour la prochaine livraison
Le choix du Mac dépend surtout de la continuité d’accès au trousseau, du niveau de contrôle de l’équipe et de la durée du besoin. La note ci-dessous est une évaluation opérationnelle, pas une promesse de fonctionnement automatique.
| Option | Quand la choisir | Risque principal | Évaluation opérationnelle |
|---|---|---|---|
| Mac fixe déjà maîtrisé | L’équipe possède un poste dédié et conserve le trousseau | Dépendance à une seule machine ou à une seule personne | 5/5 |
| Nouveau Mac interne | Le matériel doit rester sous contrôle de l’entreprise | Transmission incomplète de la clé privée ou des profils | 4/5 |
| Mac distant utilisé pour une livraison ponctuelle | Le poste interne est indisponible ou le prestataire doit intervenir à distance | Droits, accès distant et conservation des journaux à formaliser | 4/5 |
| Double environnement documenté | Une équipe veut conserver une solution de secours testée | Risque de divergence entre certificats, profils et versions du projet | 5/5 |
Un environnement distant n’annule ni les règles Apple ni les droits de l’équipe. Il fournit seulement un Mac accessible lorsque le poste habituel est indisponible. Pour une équipe qui doit préserver une session macOS, un trousseau et des journaux de construction, elle peut examiner les environnements Mac distants disponibles aux États-Unis ou comparer une autre implantation avec un Mac distant dans l’ouest des États-Unis.
Le bon test consiste à ne pas louer ou déplacer l’environnement uniquement sur la base d’une promesse d’accès. Le technicien doit d’abord se connecter, ouvrir Xcode, vérifier l’équipe, produire un Archive, passer le contrôle de signature et effectuer un envoi contrôlé. Les journaux et les informations de traitement doivent ensuite être remis au responsable de publication.
La situation actuelle présente souvent trois faiblesses : un Mac unique non accessible, une clé privée conservée par un ancien prestataire et une documentation qui ne distingue pas certificat, profil et compte. Une solution distante peut améliorer la continuité pour une mise à jour ponctuelle, mais elle ne remplace pas une gouvernance des accès. Si l’équipe doit publier régulièrement, elle a intérêt à conserver un environnement principal documenté et à tester l’environnement de secours avant l’incident.
Pour une livraison isolée, une période de transition ou l’attente d’un poste interne, NOVAKVM peut donc servir de Mac de construction distant à valider par un Archive et un upload réels. Si le projet exige une charge continue, des interfaces physiques particulières ou une conservation matérielle à long terme, l’achat et la gestion d’un Mac appartenant à l’entreprise resteront plus cohérents.
Questions fréquentes
Une application peut-elle encore recevoir une mise à jour après l’expiration du certificat Apple Distribution ?
Oui, l’expiration du certificat de distribution ne signifie pas automatiquement que l’application déjà publiée est retirée de l’App Store. En revanche, une nouvelle version doit être signée avec des actifs valides. Vérifiez d’abord l’état du compte Apple Developer Program, le mode de signature du projet et l’accès à l’équipe avant de recréer un certificat.
La signature automatique de Xcode renouvelle-t-elle toujours le certificat de distribution ?
La signature automatique peut permettre à Xcode d’utiliser des certificats gérés dans le cloud, mais elle dépend du compte connecté, de l’équipe sélectionnée, des droits accordés et de la configuration du projet. Elle ne corrige pas un mauvais identifiant d’équipe ni une autorisation manquante. Un nouvel Archive doit confirmer que la chaîne fonctionne réellement.
Que faire avec un fichier de certificat de distribution sans clé privée ?
Un certificat téléchargé ne contient pas nécessairement la clé privée créée avec la demande de signature. Dans le trousseau, le certificat utilisable doit apparaître avec sa clé privée correspondante. Si l’ancien Mac ou son responsable est encore accessible, organisez une transmission protégée de l’identité de signature. Sinon, un nouveau certificat doit être créé par un rôle autorisé.
Pourquoi le profil de provisioning reste-t-il invalide après la création d’un nouveau certificat ?
Le profil peut encore référencer l’ancien certificat, le mauvais identifiant d’application ou une équipe différente. Il faut donc régénérer ou modifier le profil App Store Connect après la création du nouveau certificat, le télécharger sur le Mac de construction et vérifier la sélection effective dans les réglages de signature du projet.
Comment récupérer la signature d’une application après un changement de Mac ?
Commencez par vérifier si le projet utilise la signature automatique. Pour une signature manuelle, contrôlez la présence du certificat et de sa clé privée dans le trousseau, puis réinstallez le profil correspondant. Si la clé privée est perdue, l’ancien certificat ne suffit pas : un membre autorisé doit créer une nouvelle identité et refaire un Archive de validation.