Migration des certificats iOS : checklist de validation 2026

📋 Table des matières

Symptôme : après avoir importé un fichier .cer, Xcode indique encore que la clé privée manque ou refuse de signer l’archive.

Solution la plus rapide : migrez l’identité complète avec sa clé privée, ou créez une nouvelle identité sur le Mac cible, puis contrôlez le Bundle ID, les capacités, le Provisioning Profile, les droits du projet et l’envoi réel vers App Store Connect avant d’arrêter l’ancien environnement.

Cet article s’adresse aux développeurs indépendants qui déplacent leur compilation vers un nouveau Mac ou un Mac distant, aux petites équipes qui entretiennent un serveur de build permanent et aux personnes dont l’ancien Mac est inutilisable. Vous y trouverez une procédure chronologique pour transférer les actifs récupérables, recréer ceux qui sont perdus et valider la nouvelle machine sans interrompre une publication en cours.

Ancien environnement contre nouveau Mac : définir la réussite avant le transfert

Un certificat seul ne permet pas de signer une application. Il contient une clé publique, tandis que la clé privée correspondante reste généralement dans le trousseau du Mac qui a généré la demande de certificat. Apple décrit l’association du certificat et de sa clé privée comme une identité numérique ; lorsqu’elle sert à signer du code, il s’agit d’une identité de signature. (Documentation Apple sur les certificats de signature de code)

C’est pourquoi le simple transfert d’un fichier .cer échoue souvent. Vous avez importé le certificat visible dans le compte développeur, mais pas la partie secrète qui permet de produire une signature.

Avant de toucher à l’ancien poste, relevez les éléments suivants :

l’identifiant de l’équipe, ou Team ID ;
le Bundle ID exact de chaque application et extension ;
les capacités activées, notamment les notifications, les groupes d’apps ou les services associés ;
le type de certificat utilisé pour le développement, les tests ou la distribution ;
le nom et le type de chaque Provisioning Profile ;
le mode de signature du projet : automatique, manuel ou piloté par une chaîne d’automatisation ;
les identifiants d’envoi utilisés par Xcode, Transporter ou fastlane ;
les certificats et clés APNs éventuellement employés par le serveur applicatif ;
le compte macOS qui exécute les tâches de compilation.

Ne confondez pas le certificat de signature avec les identifiants d’App Store Connect ou les clés APNs. Ces actifs peuvent être nécessaires au même pipeline, mais ils n’ont ni la même fonction ni le même cycle de révocation.

Trois modes de signature à séparer

Signature automatique avec Xcode. Xcode peut gérer une partie des certificats et des profils associés à votre compte. Cette voie réduit le travail manuel, mais elle ne signifie pas que tous les secrets du projet sont interchangeables entre deux machines.

Signature manuelle. Vous sélectionnez explicitement l’identité, le profil et parfois les réglages de chaque cible. Cette configuration est plus facile à auditer, mais chaque extension peut avoir son propre profil ou ses propres droits.

Pipeline automatisé. Le serveur doit accéder au trousseau, aux profils, aux paramètres de signature et aux identifiants d’envoi sans intervention graphique. Une archive réalisée avec Xcode ouvert ne prouve donc pas qu’une tâche planifiée fonctionnera après un redémarrage.

Le critère de réussite doit rester identique dans les trois cas : une archive Release du vrai projet doit être signable, vérifiable, exportable et envoyable.

La checklist de cadrage avant migration

Utilisez cette liste avant toute modification. Si un élément reste inconnu, conservez l’ancien Mac en état de fonctionnement et complétez l’inventaire avant de poursuivre.

[ ] Le Team ID et tous les Bundle ID sont documentés.
[ ] Chaque cible du projet, y compris les extensions, est recensée.
[ ] Les capacités activées sont comparées avec celles déclarées dans le portail développeur.
[ ] Le certificat utilisé par chaque cible est identifié.
[ ] La présence de la clé privée est confirmée dans Keychain Access.
[ ] Les Provisioning Profile actifs sont téléchargés ou régénérables.
[ ] Les identifiants App Store Connect sont séparés des certificats de signature.
[ ] Une archive Release de référence existe sur l’ancien Mac.
[ ] La procédure de retour temporaire vers l’ancien Mac est connue.
[ ] Les journaux de migration pourront être conservés sans secret.

Cette checklist évite de commencer par l’installation de Xcode alors que le véritable blocage se trouve dans une clé privée absente, un profil lié à un ancien certificat ou une permission App Store Connect insuffisante.

Transfert ou recréation : inspecter l’identité sur l’ancien Mac

Étape 1 — Vérifier le certificat avec sa clé privée

Ouvrez Keychain Access et recherchez le certificat de distribution ou de développement associé au projet. Dans la section My Certificates, l’entrée doit apparaître avec une clé privée rattachée. Le certificat visible seul dans une section générale ne suffit pas.

Vous pouvez également contrôler les identités disponibles avec une commande utilisant un emplacement générique :

security find-identity -v -p codesigning

Ne copiez pas ce résultat dans un ticket ou un dépôt public sans le nettoyer. Il peut révéler le nom de l’équipe, le type d’identité et des informations utiles à un attaquant.

Apple recommande le format PKCS#12, généralement enregistré avec l’extension .p12 ou .pfx, pour transporter une identité protégée par mot de passe. Dans Keychain Access, sélectionnez l’identité complète, puis exportez-la dans un fichier chiffré avec un mot de passe distinct de celui du compte développeur. La demande de certificat repose sur une paire de clés générée dans le trousseau local du Mac. (Créer une demande de signature de certificat)

Attention : si l’entrée n’affiche aucune clé privée associée, l’export du certificat ne restaurera pas l’identité. Arrêtez-vous ici et préparez une nouvelle demande de certificat sur le Mac cible.

Pourquoi Xcode signale-t-il encore l’absence de clé privée ?

Ce message apparaît généralement dans l’un des cas suivants :

seul le fichier .cer a été copié ;
le fichier .p12 a été exporté sans sélectionner l’identité complète ;
la clé privée a été importée dans un autre trousseau ;
le certificat et la clé privée ne forment pas une paire ;
l’utilisateur qui lance le build n’a pas accès au trousseau ;
le trousseau est verrouillé lorsque la tâche automatisée démarre ;
le certificat a été révoqué ou n’est plus accepté par le profil utilisé.

La présence visuelle du certificat dans Keychain Access n’est donc pas une preuve suffisante. Développez l’entrée et vérifiez que la clé privée apparaît comme élément enfant. Sur une machine distante, répétez ce contrôle avec le compte réellement utilisé par le processus de compilation, et non uniquement avec votre compte administrateur.

Étape 2 — Exporter sans créer une nouvelle fuite

Sauvegardez les profils nécessaires dans un emplacement sécurisé. Selon leur type, vous pouvez les télécharger depuis Certificates, Identifiers & Profiles ou demander à Xcode de les récupérer. Apple indique qu’un profil peut devenir invalide après la révocation d’un certificat, la modification d’une capacité ou son expiration. (Modifier, télécharger ou supprimer des profils)

Conservez séparément :

le fichier .p12 chiffré ;
son mot de passe ;
les Provisioning Profile ;
les réglages de signature du projet ;
les paramètres d’exportation ;
les références aux clés d’API App Store Connect ;
les certificats ou clés APNs ;
la procédure de restauration.

Ne placez jamais le fichier .p12, son mot de passe, une clé .p8 ou un jeton d’accès dans le dépôt Git. Certaines clés privées liées aux services Apple ne sont disponibles au téléchargement qu’une seule fois ; elles doivent être conservées dans un emplacement sécurisé. (Créer une clé privée)

Une sauvegarde doit être testée. Un fichier présent dans un stockage distant mais impossible à déchiffrer ou à récupérer n’est pas une sauvegarde opérationnelle.

Ancien Mac indisponible contre nouveau certificat : choisir la voie de récupération

Étape 3 — Quand l’ancien Mac ne peut plus démarrer

Une clé privée ne peut pas être reconstruite à partir du certificat public. Si le trousseau de l’ancien Mac est perdu et qu’aucune exportation protégée n’existe, créez une nouvelle demande de signature depuis le Mac cible, puis demandez un nouveau certificat lorsque votre rôle dans l’équipe vous y autorise.

Apple précise qu’un certificat contient la clé publique ; la capacité de signer dépend de la clé privée correspondante. (Documentation Apple sur les certificats de signature de code)

Avant toute révocation, vérifiez si l’ancien certificat est encore utilisé par :

une autre machine de build ;
une extension ;
une tâche planifiée ;
un collaborateur ;
un outil de distribution ;
une version de secours conservée pour une livraison urgente.

La révocation n’est pas une opération neutre. Apple précise que les profils contenant un certificat révoqué deviennent invalides. Vous devrez ensuite les modifier ou en générer de nouveaux. (Révoquer un certificat)

La séquence recommandée est donc la suivante : créer et tester la nouvelle identité, générer ou mettre à jour les profils, migrer le pipeline, réaliser un envoi réel, puis décider si l’ancien certificat doit être révoqué.

La règle de décision pour chaque actif

Appliquez les conditions ci-dessous plutôt que de recréer tous les éléments sans distinction :

Si le fichier .p12 protégé est disponible et que le certificat possède sa clé privée sur l’ancien Mac, transférez l’identité complète.
Si le certificat est disponible mais que la clé privée est perdue, créez une nouvelle identité au lieu de tenter de réparer le fichier .cer.
Si le Provisioning Profile reste valide, utilise le même certificat, correspond au même App ID et couvre les mêmes capacités, réutilisez-le après vérification.
Si le certificat, une capacité ou l’état du profil a changé, générez un nouveau profil.
Si une clé d’API App Store Connect est compromise, introuvable ou attribuée à un ancien compte, traitez-la séparément et planifiez sa rotation.
Si l’archive Release fonctionne mais que l’envoi échoue, conservez l’ancien Mac et corrigez d’abord l’authentification ou les droits d’envoi.
Si l’envoi est accepté mais que la tâche planifiée échoue après redémarrage, ne déclarez pas la migration terminée.
Si deux exécutions automatisées passent dans les mêmes conditions, planifiez seulement alors la mise hors service de l’ancien Mac.

Cette branche de décision constitue le point de contrôle principal : elle distingue ce qui peut être transféré de ce qui doit être recréé ou renouvelé.

Nouveau Mac contre projet existant : rétablir la relation de signature

Étape 4 — Importer l’identité dans le bon trousseau

Sur le nouveau Mac, importez le fichier .p12 dans le trousseau utilisé par le compte de construction. Vérifiez ensuite dans Keychain Access que le certificat et la clé privée apparaissent ensemble.

Le problème le plus fréquent n’est pas l’absence du fichier, mais son importation dans un mauvais trousseau ou son accès refusé au processus de compilation. Un utilisateur interactif peut réussir une archive après avoir saisi un mot de passe, alors qu’un agent lancé par une tâche planifiée reste bloqué.

Contrôlez :

le compte macOS qui lance la compilation ;
le trousseau effectivement utilisé par ce compte ;
l’autorisation accordée aux outils de signature ;
le comportement après fermeture de session ;
le comportement après redémarrage ;
la présence du profil dans le répertoire attendu.

Pour une configuration automatisée, ne désactivez pas les protections du trousseau simplement pour faire passer un premier build. Préparez plutôt une procédure documentée de déverrouillage contrôlé, avec un compte de build limité et des secrets stockés séparément.

Étape 5 — Reconnecter Xcode, le `Bundle ID` et les capacités

Ouvrez le projet sur le Mac cible et contrôlez chaque cible dans Signing & Capabilities. Le projet doit utiliser la bonne équipe, le bon identifiant d’application et les mêmes capacités que l’ancien environnement.

Un profil de distribution App Store contient un certificat de distribution et doit correspondre à l’App ID utilisé par l’application. Apple décrit cette relation dans sa procédure de création d’un profil App Store Connect. (Créer un profil de provisioning App Store)

Ne supposez pas qu’un profil portant un nom similaire est équivalent. Vérifiez notamment :

le Bundle ID ;
le certificat inclus ;
les capacités autorisées ;
l’environnement de notification ;
les extensions et leurs identifiants propres ;
la date d’expiration ;
le mode automatique ou manuel du projet.

Si vous utilisez la signature automatique, Xcode peut demander un nouveau profil lorsque celui disponible localement ne satisfait plus les exigences connues. Avec une signature manuelle, vous devrez sélectionner ou télécharger explicitement le profil adapté. (Modifier, télécharger ou supprimer des profils)

Le changement de Mac impose-t-il un nouveau profil ?

Non. Le remplacement du Mac, à lui seul, ne rend pas automatiquement chaque profil invalide. Si le profil reste valide, correspond au même App ID, contient un certificat encore utilisable et couvre les mêmes capacités, vous pouvez généralement le télécharger et l’installer sur le nouveau Mac.

Recréez-le toutefois si :

le certificat associé a changé ;
une capacité a été ajoutée ou retirée ;
le profil est expiré ou déclaré invalide ;
le Bundle ID a changé ;
une extension nécessite une configuration différente ;
l’ancien profil ne correspond plus à la méthode de distribution.

La décision dépend donc de la relation entre l’App ID, le certificat, les capacités et l’état du profil, pas simplement de la machine utilisée.

Première archive contre simple compilation : valider toute la chaîne

Étape 6 — Réaliser une véritable archive Release

Ne commencez pas par un simple lancement sur simulateur. Sélectionnez le schéma réel, choisissez une destination adaptée à la distribution et exécutez Product > Archive. Apple précise qu’une archive contient le build et les informations nécessaires à la distribution, puis peut être validée depuis l’organisateur Xcode. (Distribuer une application pour les tests et les versions)

Après l’archive, contrôlez successivement :

la compilation Release ;
la présence de l’archive dans l’organisateur ;
l’identité de signature sélectionnée ;
le profil intégré ;
le Team ID ;
les droits déclarés dans les entitlements ;
l’export de l’IPA ;
la validation locale ;
l’envoi vers App Store Connect ;
le traitement accepté par la plateforme.

Vous pouvez inspecter la signature avec des commandes utilisant uniquement des espaces réservés :

codesign -dvvv --entitlements :- "/chemin/vers/MonApp.app"

Pour examiner le profil intégré :

security cms -D -i "/chemin/vers/embedded.mobileprovision"

Remplacez les chemins, noms d’application, identifiants et valeurs sensibles par des variables dans votre documentation. Les journaux conservés doivent indiquer l’erreur utile sans contenir de mot de passe, de jeton, de clé privée ni de contenu .p8.

Étape 7 — Vérifier l’envoi, pas seulement l’IPA

Une exportation locale réussie ne prouve pas que votre processus de publication fonctionne. App Store Connect associe le build à l’application à partir du Bundle ID et du numéro de version ; le build doit ensuite être traité par les systèmes Apple avant d’apparaître dans l’interface. (Envoyer des builds vers App Store Connect)

Utilisez Xcode, Transporter ou l’outil prévu par votre chaîne, puis vérifiez :

que l’envoi ne s’est pas terminé avec un avertissement bloquant ;
que le build apparaît dans App Store Connect ;
que son traitement est terminé ;
que les symboles ont été transmis lorsque votre procédure l’exige ;
que la version et le numéro de build sont ceux attendus ;
que les informations de conformité demandées sont complétées.

Pour une équipe qui automatise l’envoi, séparez clairement les identifiants de signature des clés d’API App Store Connect. Une clé d’API peut authentifier un service, mais elle ne remplace pas une identité de signature dans le trousseau.

Validation finale contre arrêt immédiat : conserver l’ancien Mac assez longtemps

Ne supprimez pas l’ancien environnement dès que la première archive passe. Exécutez au moins une nouvelle tâche sans intervention manuelle. Redémarrez le Mac cible ou simulez le cycle prévu par votre infrastructure, restaurez les dépendances nécessaires et confirmez que le compte de build retrouve son trousseau sans action graphique.

La migration peut être déclarée réussie uniquement lorsque les cases suivantes sont cochées :

[ ] Le certificat et sa clé privée sont présents dans le même trousseau.
[ ] Le projet utilise le bon Team ID et le bon Bundle ID.
[ ] Les capacités correspondent aux profils installés.
[ ] Le Provisioning Profile est valide et associé au certificat attendu.
[ ] Une archive Release du projet réel a été créée.
[ ] La signature et les entitlements ont été contrôlés.
[ ] L’IPA a été exportée selon le mode de distribution prévu.
[ ] Le build a été envoyé à App Store Connect.
[ ] Le traitement du build a été accepté.
[ ] Une tâche sans interface graphique a fonctionné.
[ ] La procédure reste fonctionnelle après redémarrage.
[ ] Les journaux de test ont été désensibilisés.
[ ] Une procédure de retour est encore disponible.

Ne nettoyez l’ancien Mac qu’après avoir documenté l’identité active, les profils associés, les capacités du projet, les clés d’API utilisées, la procédure de restauration et le résultat de l’envoi. Lorsque vous retirez les secrets, supprimez les copies .p12, les profils inutiles, les clés d’API et les journaux contenant des informations sensibles.

Un Mac acheté localement reste préférable si vous devez conserver des périphériques physiques, travailler hors connexion ou faire tourner une charge lourde et stable pendant une longue période. Il offre aussi une maîtrise directe du matériel et du stockage.

À l’inverse, un Mac distant peut être pertinent lorsque vous devez remplacer rapidement un poste en panne, garder une machine de build disponible à toute heure ou tester une migration sans acheter immédiatement un second ordinateur. Vous pouvez préparer l’environnement via accès distant, conserver l’ancien poste en parallèle et arrêter la location lorsque la bascule est validée. Les modalités de commande d’un environnement Mac distant dépendent ensuite de la durée et du niveau de permanence nécessaires à votre pipeline.

Le modèle local présente toutefois des limites concrètes : le Mac peut rester inutilisé entre deux versions, son remplacement immobilise un budget important et une panne matérielle peut interrompre la publication. Un Mac distant dépend, lui, de la connectivité, exige une gestion rigoureuse des accès et ne remplace pas un appareil physique pour les tests nécessitant des capteurs ou des câbles.

Pour une migration ponctuelle, consultez d’abord le guide des tarifs Mac mini M4, puis choisissez une durée assez longue pour réaliser l’archive, l’envoi réel et le test après redémarrage. Si vous maintenez plusieurs applications ou une chaîne de publication permanente, un environnement distant peut devenir un poste de transition avant une décision d’achat plus durable.

La migration des certificats iOS n’est donc pas terminée quand Xcode cesse d’afficher une alerte. Elle est terminée lorsque le nouveau Mac signe le vrai projet, produit une archive Release vérifiable, l’envoie à App Store Connect et répète cette séquence après redémarrage. Si l’ancien Mac arrive en fin de vie, une location courte chez MacDate peut servir de banc de transition pour effectuer cette validation sans acheter immédiatement une seconde machine ; vous pourrez ensuite décider, sur des résultats vérifiés, s’il faut conserver un Mac distant permanent ou revenir à un poste local.