Le pipeline refuse soudainement l’archive ou l’envoi vers App Store Connect parce que l’identité de signature arrive à expiration.
La solution la plus sûre consiste à créer la nouvelle identité avec un rôle contrôlé, mettre à jour les profils, tester une publication réelle sur un nœud Mac isolé, puis seulement retirer l’ancien certificat. Si une clé privée est probablement exposée, vous inversez la priorité : confinement et révocation immédiate, même si la continuité de construction devient temporairement plus difficile.
Cet article s’adresse aux administrateurs IT responsables du compte Apple Developer et des droits de signature, aux équipes plateforme qui maintiennent Xcode, Keychain et les nœuds Mac de CI/CD, ainsi qu’aux responsables release, sécurité ou audit qui doivent autoriser la bascule et conserver les preuves.
SECTION 01 Le calendrier de rotation à appliquer dès cette semaine
Ne traitez pas la rotation comme une simple tâche de renouvellement dans le portail. Il s’agit d’un changement de chaîne de confiance qui touche le certificat, la clé privée, le Provisioning Profile, les entitlements, le projet Xcode et chaque nœud capable de produire une archive.
Jalon 1 : inventorier avant de créer
Commencez par une table d’actifs contenant, pour chaque application :
- le Bundle ID et le Team associé ;
- le type de certificat utilisé ;
- le nom et l’empreinte du certificat actuel ;
- le profil de provisioning associé ;
- les entitlements attendus ;
- les nœuds Mac qui peuvent signer ;
- le propriétaire technique et le valideur sécurité ;
- la date cible de bascule et l’objet prévu pour révocation.
Ne vous contentez pas d’un inventaire de fichiers .p12 ou .mobileprovision. Une archive peut réussir sur un nœud tout en échouant sur un autre parce que la clé privée manque, que le profil local est ancien ou que le compte d’accès à Certificates, Identifiers & Profiles n’est pas disponible.
Jalon 2 : créer sans exposer le compte principal
Dans une organisation, la capacité à créer ou révoquer un certificat de distribution est réservée à l’Account Holder ou à un Admin disposant des droits correspondants. Le rôle Developer ne doit donc pas être assimilé à un accès complet aux actifs de signature. La matrice officielle des rôles distingue également la gestion des utilisateurs, des profils et des certificats. (developer.apple.com)
La règle opérationnelle est simple : aucun identifiant Apple disposant d’un privilège élevé ne doit être installé directement sur un agent CI permanent. Le nœud reçoit uniquement les secrets nécessaires à la construction, dans une zone contrôlée, avec une durée d’exposition limitée et une journalisation exploitable.
Jalon 3 : valider avant de retirer
La création du nouveau certificat ne prouve rien. Vous devez vérifier que la nouvelle identité permet :
- la compilation ;
- l’archivage ;
- la signature ;
- l’export ;
- l’envoi vers App Store Connect ou le canal de distribution concerné.
Pour un profil manuel, Apple indique qu’un profil de distribution contient un App ID et un certificat de distribution. Si le certificat associé change, le profil doit être régénéré ou modifié avant de pouvoir servir à nouveau à la signature. (developer.apple.com)
Jalon 4 : révoquer selon le risque
Une rotation planifiée autorise une période de coexistence entre l’ancien et le nouveau chemin de signature. Une suspicion de fuite de clé privée ne l’autorise pas nécessairement. Apple rappelle que les certificats et les informations d’authentification sont des actifs sensibles ; la distribution interne de certificats hors du périmètre de confiance doit donc être évitée. (developer.apple.com)
La question à trancher n’est pas « le nouveau certificat existe-t-il ? », mais « avons-nous suffisamment de preuves pour retirer l’ancien sans laisser un nœud inconnu dépendre de lui ? ».
SECTION 02 Qui possède quelle décision dans l’entreprise ?
La rotation échoue souvent pour une raison organisationnelle : chaque équipe pense que l’autre a vérifié la clé privée, le profil ou le dernier nœud de secours. Une répartition par rôle évite cette zone grise.
| Rôle | Responsabilité principale | Preuve à fournir | Condition de passage |
|---|---|---|---|
| Administrateur Apple Developer | Création, téléchargement contrôlé et révocation du certificat | Empreinte, Team, type, demandeur et journal d’action | Le certificat est créé sans compte partagé |
| Équipe plateforme CI/CD | Installation dans le Keychain dédié et configuration de la pipeline | Empreinte détectée, clé privée présente, logs nettoyés | Chaque nœud autorisé est contrôlé |
| Responsable release | Archive, export et envoi de validation | Identifiant de build, archive, résultat d’export et preuve d’envoi | La chaîne réelle fonctionne avec le nouveau profil |
| Responsable sécurité | Analyse de l’exposition, approbation de révocation et conservation des traces | Périmètre touché, décisions, accès retirés et date d’action | Le niveau de risque est accepté ou traité |
| Responsable infrastructure | Disponibilité du Mac de validation, redémarrage et reprise | Résultat après redémarrage, accès distant et capacité de secours | Le nœud reste exploitable après récupération |
Cette organisation ne remplace pas vos procédures internes. Elle indique qui doit répondre lorsqu’un changement est bloqué, qui fournit la preuve et qui peut autoriser l’étape suivante.
SECTION 03 Première étape : choisir le bon mode de signature
Apple propose des certificats gérés dans le cloud, associés à l’adhésion Apple Developer. Avec Xcode 13 ou une version ultérieure, le flux d’archivage et de distribution peut utiliser la signature cloud ; Apple indique aussi qu’un nouveau certificat géré dans le cloud est créé automatiquement 90 jours avant l’expiration lorsqu’une nouvelle demande de signature est reçue. La rotation manuelle peut être déclenchée lorsque le certificat a consommé moins de la moitié de sa période de validité, souvent autour de 180 jours. (developer.apple.com)
Cela ne signifie pas que toute entreprise doit abandonner les identités locales.
Certificat géré dans le cloud
Ce mode convient lorsque :
- le flux de distribution passe réellement par l’Organizer de Xcode ;
- l’équipe veut limiter la circulation des clés privées ;
- les permissions App Store Connect peuvent être attribuées précisément ;
- les besoins de signature locale et de reproductibilité sont limités.
Il faut toutefois vérifier que votre pipeline non interactive, vos scripts d’export et vos contraintes d’audit sont compatibles avec ce mode.
Identité de signature locale
Une identité locale reste pertinente lorsque :
- la CI utilise une signature manuelle ;
- plusieurs projets doivent produire des archives reproductibles ;
- vous devez contrôler explicitement le certificat et le profil ;
- des étapes d’export sont exécutées par des scripts sur un Mac dédié.
Dans ce cas, la clé privée doit entrer dans le Keychain du nœud, mais pas dans un répertoire partagé, un dépôt Git, un ticket ou une conversation d’équipe. Apple précise que la clé privée est indispensable à la signature et qu’un certificat public seul ne permet pas de signer. (developer.apple.com)
SECTION 04 Deuxième étape : mettre à jour les profils et le projet Xcode
Le remplacement du certificat ne suffit pas. Pour une signature manuelle, sélectionnez le nouveau certificat lors de la régénération du profil, téléchargez le fichier, installez-le sur le nœud de validation puis vérifiez qu’il correspond au Bundle ID et aux entitlements du projet.
Le profil doit notamment rester cohérent avec :
- l’App ID explicite ;
- les capacités activées ;
- le type de distribution ;
- le certificat sélectionné ;
- les éventuels appareils enregistrés pour les flux de développement ou Ad Hoc.
Apple documente la séquence de création d’un profil : choix du type, sélection de l’App ID, sélection du certificat, sélection des appareils lorsque nécessaire, génération puis téléchargement. (developer.apple.com)
Pour répondre au cas fréquent du CI/CD après changement de certificat, vérifiez dans la pipeline :
- la variable ou l’identifiant de signature sélectionné ;
- le chemin du profil réellement utilisé ;
- le Team de développement ;
- les entitlements extraits de l’application signée ;
- la date et l’empreinte du profil ;
- l’absence de profil ancien chargé depuis un cache local.
Un cache de profils peut masquer une erreur de configuration. Si vous utilisez la signature automatique, Xcode peut gérer certains profils, mais cela ne dispense pas de vérifier quel profil et quelle identité ont été utilisés par l’archive effectivement envoyée.
SECTION 05 Troisième étape : isoler le Keychain et chaque nœud Mac
Le Keychain de construction doit être distinct du trousseau personnel d’un administrateur. Définissez un trousseau dédié ou un équivalent contrôlé, déverrouillé uniquement pendant la tâche de build, puis verrouillé et nettoyé à la fin.
Contrôlez au minimum :
- les autorisations accordées à l’outil de signature ;
- l’absence de mot de passe dans la ligne de commande ou les logs ;
- la suppression des fichiers temporaires ;
- la présence de la clé privée avec le certificat correspondant ;
- la sélection explicite de l’identité attendue ;
- le comportement après redémarrage ;
- la capacité à reconstruire le nœud sans intervention improvisée.
Sur plusieurs Mac, ne déclarez pas la rotation terminée après un seul succès. Comparez l’empreinte du certificat, la disponibilité de la clé privée et l’état du profil sur chaque machine. Un agent de secours silencieusement resté sur l’ancien certificat peut reprendre une tâche au mauvais moment et produire un échec difficile à reproduire.
Pour des usages audio, vidéo ou design qui partagent le même parc Mac, séparez également les caches lourds, les comptes utilisateurs et les espaces de travail de la CI. Les fichiers de production créative ne doivent pas se retrouver dans le même périmètre que les secrets de signature simplement parce qu’un Mac est puissant.
SECTION 06 Quatrième étape : vérifier la publication réelle et le retour arrière
La validation doit utiliser une branche non critique ou un nœud d’acceptation, mais elle doit reproduire le chemin de production. Une simple compilation locale ne teste pas l’export ni l’envoi.
Conservez :
- le commit source ;
- la version de Xcode ;
- l’identifiant du nœud ;
- l’empreinte du certificat ;
- le nom et l’empreinte du profil ;
- la liste des entitlements ;
- l’identifiant de l’archive ;
- le résultat de validation ;
- la preuve d’envoi ;
- le propriétaire de l’approbation.
Avant de supprimer l’ancien profil ou certificat, faites un test de bascule inverse sur le plan documentaire, même si vous ne réinstallez pas réellement l’ancien secret. Le plan doit préciser quel nœud peut reprendre la production, quelle identité reste disponible, quelle personne peut arrêter la diffusion et comment restaurer une configuration connue.
La révocation d’un certificat Apple Distribution affecte-t-elle l’application déjà publiée ?
Pour une application distribuée sur l’App Store, Apple indique que les versions existantes ne sont pas affectées par l’expiration ou la révocation du certificat de distribution, mais que vous ne pourrez plus envoyer de nouvelle application ou de mise à jour signée avec ce certificat. En revanche, les profils de provisioning qui contiennent le certificat révoqué deviennent invalides et doivent être réparés ou régénérés. (developer.apple.com)
Ne transposez pas cette règle aux applications internes sans vérification. Apple précise que les applications iOS distribuées pour un usage interne peuvent cesser de fonctionner lorsqu’elles ont été signées avec le certificat révoqué ou expiré ; le traitement doit donc être séparé du cas App Store. (developer.apple.com)
SECTION 07 Cinquième étape : traiter séparément l’expiration et la fuite
Rotation planifiée
Pour une expiration connue, utilisez une séquence de coexistence :
- confirmer le périmètre des applications ;
- créer le nouveau certificat avec le rôle autorisé ;
- régénérer les profils concernés ;
- installer le certificat et les profils dans le Keychain dédié ;
- tester archive, export et envoi ;
- contrôler tous les nœuds ;
- basculer la pipeline ;
- conserver une fenêtre de retour arrière ;
- révoquer l’ancien certificat après approbation.
La durée de cette coexistence est une règle interne, pas une exigence universelle d’Apple. Fixez-la selon votre fréquence de publication, votre capacité de secours et le niveau de contrôle de vos secrets.
Fuite présumée
Si la clé privée a été copiée, envoyée dans un dépôt ou rendue accessible à une personne non autorisée, ne retardez pas la révocation uniquement pour préserver la continuité de la CI. Isolez les nœuds concernés, retirez les secrets, recherchez les traces d’utilisation et faites approuver une nouvelle identité.
La question « l’ancien certificat fonctionne-t-il encore ? » devient secondaire. Le risque est que quelqu’un puisse signer ou publier en se faisant passer pour votre équipe. Pour les certificats de distribution, Apple réserve la révocation à l’Account Holder ou à l’Admin selon le type de compte et le certificat. (developer.apple.com)
SECTION 08 Checklist d’acceptation avant mise en production
- [ ] Le certificat, son type, son Team et son empreinte figurent dans l’inventaire.
- [ ] Le demandeur, le valideur et le propriétaire de la révocation sont identifiés.
- [ ] Le nouveau certificat a été créé avec un rôle Apple Developer autorisé.
- [ ] La clé privée correspondante est présente uniquement dans le Keychain contrôlé.
- [ ] Les profils ont été régénérés avec le nouveau certificat lorsque nécessaire.
- [ ] Le Bundle ID, les entitlements et le profil concordent.
- [ ] L’archive a été produite sur un nœud distinct de la production critique.
- [ ] L’export a réussi avec la configuration destinée à la distribution.
- [ ] L’envoi vers App Store Connect ou le canal interne a été validé.
- [ ] Chaque Mac autorisé a été vérifié individuellement.
- [ ] La pipeline ne révèle ni mot de passe, ni clé privée, ni fichier temporaire.
- [ ] Un redémarrage du nœud a été testé.
- [ ] Le plan de retour arrière désigne un nœud et une personne responsables.
- [ ] Les profils dépendant de l’ancien certificat sont identifiés.
- [ ] La révocation de l’ancien certificat a reçu une approbation explicite.
- [ ] Les preuves d’audit sont stockées hors du nœud de construction.
SECTION 09 Comparer les trois façons de fournir un nœud de validation
Le choix du Mac de validation influence directement le risque opérationnel. Modifier le seul nœud de production est rapide, mais concentre la manipulation des secrets et rend le retour arrière plus délicat. Un Mac de secours physique offre une séparation claire, mais il doit rester maintenu. Un Mac distant dédié permet d’ajouter temporairement une capacité sans acheter immédiatement une machine supplémentaire, à condition de vérifier les accès, l’effacement et la procédure de récupération.
| Option | Avantage principal | Risque dominant | À retenir lorsque |
|---|---|---|---|
| Production directement | Aucun nouveau nœud à préparer | Une erreur touche le flux actif | Le changement est mineur et le retour arrière est déjà éprouvé |
| Mac de secours dédié | Séparation nette et contrôle matériel | Coût et maintenance d’un équipement rarement utilisé | Vous avez des audits stricts ou plusieurs applications critiques |
| Mac distant temporaire | Capacité isolée et extensible | Dépendance à la connectivité et à l’exploitation distante | Vous devez tester ou absorber un pic de publication sans achat immédiat |
Un Mac distant exploitable pour ce scénario doit fournir un accès administrateur complet, une connexion SSH ou graphique adaptée, un redémarrage à distance et une séparation claire du nœud de production. VPSNIX présente des machines Mac physiques dédiées, un accès root et une console permettant notamment l’arrêt et le redémarrage du nœud. Ces éléments doivent toutefois être validés contre votre politique de sécurité avant d’y placer des actifs de signature. (vpsnix.com)
SECTION 10 La décision finale : acheter, réutiliser ou louer le Mac de validation
| Situation de votre équipe | Choix généralement cohérent | Pourquoi |
|---|---|---|
| Publications fréquentes et charge stable toute l’année | Mac physique acheté ou déjà détenu | La dépense initiale se justifie par l’utilisation continue |
| Besoin d’un nœud de secours ponctuel | Mac distant loué sur une période limitée | Vous évitez de laisser un appareil inutilisé entre deux rotations |
| Équipe distribuée avec audit des accès | Nœud isolé avec SSH, contrôle d’accès et journalisation | La responsabilité peut être séparée du poste personnel |
| Plusieurs projets à tester avant une fenêtre de release | Plusieurs nœuds temporaires ou une capacité renforcée | Vous réduisez la file d’attente et les manipulations concurrentes |
| Besoin de périphériques physiques spécifiques | Mac local dédié | La location distante ne remplace pas toujours un périphérique USB ou une intégration matérielle |
Les contraintes de votre solution actuelle doivent être écrites avant toute décision : un Mac de production utilisé comme poste personnel mélange les comptes et les secrets ; un seul nœud de secours non maintenu peut échouer après redémarrage ; une capacité achetée pour une rotation annuelle immobilise du budget et du matériel entre deux opérations. À l’inverse, la location distante n’est pas idéale pour une charge permanente très lourde, pour une politique interdisant les secrets hors site ou pour des tests qui exigent des interfaces physiques locales.
Si votre checklist révèle l’absence de nœud d’acceptation isolé, de root complet, de récupération après redémarrage ou de capacité temporaire pendant les publications, vous pouvez examiner les modalités de location d’un Mac distant dédié et consulter les exigences générales de votre environnement avant d’y transférer un secret de signature. Vous pouvez aussi consulter la présentation des nœuds Mac physiques de VPSNIX pour comparer cette option avec l’achat d’un Mac de secours.
Une rotation de certificats iOS réussie se reconnaît donc à ses preuves : chaque rôle sait ce qu’il doit valider, chaque Mac possède la bonne identité, le profil correspond réellement au projet, la publication a été testée et l’ancien certificat n’est retiré qu’après décision documentée.