Comment faire la rotation des certificats iOS CI d’équipe ? Fastlane Match 2026

Apple précise qu’un certificat révoqué invalide les profils de provisionnement qui le contiennent (règles de révocation d’Apple). Pour la rotation des certificats iOS CI, retenez donc cette séquence : inventaire des certificats, des clés privées et des profils, synchronisation contrôlée avec Fastlane Match, validation sur un vrai Mac de CI, puis seulement mise à l’écart des anciennes ressources. Cette semaine, commencez par documenter les dépendances et les conditions de retour arrière ; ne révoquez rien pour « faire le ménage ».

Cette procédure s’adresse aux responsables IT qui fixent les règles d’approbation et de retour arrière.
Elle aide aussi les ingénieurs de plateforme à limiter ce que la CI peut modifier.
Les équipes de publication y trouveront les contrôles nécessaires pour accepter une nouvelle signature.

Avant la rotation : inventorier les dépendances

Le nom d’un certificat ne suffit pas pour déterminer son impact. Pour chaque application, reliez l’identité de signature au type de distribution, au profil de provisionnement utilisé et à la tâche qui produit l’archive. Distinguez les signatures de développement, la distribution destinée à l’App Store et les profils réservés à la distribution interne. Apple documente les types de certificats et leur gestion dans son aperçu des certificats.

Constituez un inventaire lisible par l’équipe, plutôt qu’une collection de fichiers déposés dans un répertoire partagé. Pour chaque ressource, consignez son propriétaire, son usage, son état vérifié et l’emplacement où elle est référencée. Indiquez également qui peut approuver une modification et qui est chargé de la mise en production. Les rôles du compte développeur ne sont pas interchangeables : vérifiez les capacités associées à chaque rôle dans la documentation Apple sur les rôles, puis attribuez les actions selon les responsabilités réelles de votre organisation.

L’inventaire doit séparer des éléments souvent confondus :

• Le certificat fournit l’identité de signature publique et son état dans le compte développeur. Une copie du certificat, à elle seule, ne prouve pas que le Mac peut signer.
• La clé privée permet d’utiliser l’identité correspondante pour signer. Vérifiez qu’elle est présente dans le trousseau approprié, qu’elle correspond au certificat et que son accès est réservé aux comptes autorisés.
• Le profil de provisionnement associe des informations nécessaires à la signature et à la distribution. Notez l’application et le type de flux auxquels il est destiné ; un profil de développement n’est pas un substitut à un profil de distribution.
• Le secret CI peut déverrouiller un dépôt chiffré ou un environnement de compilation. Il ne remplace ni le certificat ni la clé privée, et son accès doit être évalué séparément.
• L’accès au Mac détermine qui peut consulter le trousseau, modifier les outils de signature ou récupérer des fichiers. Le mode lecture seule de Match ne prouve pas, à lui seul, que l’hôte est isolé.

Relevez les noms utilisés par les tâches CI et les paramètres Xcode, puis comparez-les aux ressources visibles dans le compte développeur et dans le trousseau du Mac. Lorsque les libellés divergent, consignez le lien entre l’identifiant utilisé par la tâche, le certificat réel et le profil embarqué dans le produit. La note technique d’Apple sur les profils de provisionnement et les journaux de signature aide à comprendre quels éléments vérifier dans les diagnostics.

Enfin, identifiez chaque voie de publication qui dépend de ces ressources : compilation de validation, archivage, distribution de test ou publication. Une liste de projets sans leurs tâches de diffusion est incomplète. Elle risque de laisser un ancien profil en service sur une branche de publication ou sur un Mac de secours, alors que le pipeline principal paraît correctement migré.

Avant le changement : figer une base de comparaison

Avant de créer ou de synchroniser de nouvelles ressources, consignez la configuration actuellement acceptée : version de Xcode sélectionnée, paramètres de signature, identité attendue, profil utilisé et résultat des tâches représentatives. Cette base ne sert pas à imposer une version unique à toutes les équipes. Elle permet de comparer le comportement réel avant et après la rotation.

Conservez des preuves provenant de la chaîne de build, pas uniquement d’un document de procédure. Les journaux peuvent indiquer l’identité choisie par la tâche ; les informations de l’archive permettent de contrôler ce qu’elle contient réellement. Relevez aussi les éventuels paramètres particuliers d’un projet, par exemple une configuration distincte pour la distribution de test. Si un projet ne peut pas être reconstruit à partir de son état accepté, arrêtez la rotation pour ce projet et rétablissez d’abord une base reproductible.

Vérifiez ensuite que le Mac de CI dispose bien de la clé privée correspondante et que l’utilisateur exécutant la tâche peut l’utiliser. Une identité visible dans le trousseau, sans clé privée utilisable, peut laisser croire à tort que la signature est prête. Contrôlez aussi les autorisations du compte CI, l’accès au dépôt de certificats et les secrets nécessaires au déchiffrement. Si votre flux s’appuie sur la synchronisation des identités de signature d’une équipe, comparez-le à la documentation Xcode sur le partage des certificats de signature.

Figez enfin le périmètre de changement. Une rotation peut toucher plusieurs applications, mais vous ne devez pas supposer qu’elles partagent le même profil ou le même chemin de publication. Associez chaque application à un propriétaire de validation, à une preuve attendue et à une condition d’arrêt. Ainsi, un échec sur une voie secondaire ne se transforme pas en modification silencieuse de toutes les autres.

Création des nouvelles ressources : préparer sans révoquer

Choisissez le mécanisme de création selon le processus déjà approuvé par votre organisation : Xcode, le compte développeur Apple ou une opération Fastlane Match autorisée. Il n’y a pas de bénéfice à ajouter un nouvel outil au moment même où vous modifiez une chaîne de signature, sauf si votre méthode actuelle ne permet pas de contrôler les responsabilités ou de reproduire le résultat.

Vérifiez le rôle du compte qui crée ou gère le certificat et conservez la trace de l’approbation. La personne qui exécute l’opération technique n’a pas nécessairement à posséder tous les droits administratifs. Séparez les étapes de préparation des ressources de celles exécutées par la CI de production, afin qu’un build ordinaire ne puisse pas créer des certificats ou modifier les profils sans décision explicite.

Après la création ou le renouvellement du certificat, examinez les profils associés aux applications concernées. Selon le changement, un profil doit être modifié, téléchargé à nouveau ou régénéré. Apple décrit ces opérations dans son guide pour modifier, télécharger ou supprimer des profils. Ne déduisez pas qu’un profil est prêt parce qu’un fichier du même nom existe déjà sur le Mac : vérifiez son contenu et son association avec la nouvelle identité.

Une rotation n’est pas une révocation différée décidée à l’avance. Gardez l’ancienne identité disponible tant que les nouvelles ressources n’ont pas passé les vérifications prévues et que les dépendances résiduelles ne sont pas connues.

La distinction est particulièrement importante pour un certificat Apple Distribution. Le certificat, la clé privée et le profil forment une chaîne d’usage, mais ne constituent pas un objet unique à supprimer puis recréer. La révocation agit sur les profils qui contiennent le certificat concerné, comme le précise Apple dans ses instructions de révocation. Considérez donc la révocation comme une décision de retrait à part entière, soumise à une vérification d’impact, et non comme le geste normal qui ouvre toute rotation.

Synchronisation Fastlane Match : limiter les changements de la CI

Validez d’abord le résultat de la synchronisation dans un environnement Mac isolé du flux de publication courant. Ciblez l’application, le type de signature et le profil correspondant ; confirmez que Match a installé les ressources attendues et que la clé privée est utilisable par la tâche de build. La documentation officielle de Fastlane Match décrit la synchronisation des certificats et des profils ainsi que son mode de lecture seule.

Dans la CI ordinaire, configurez la synchronisation de façon à lire les ressources déjà préparées plutôt qu’à en créer ou en modifier. Dans une configuration Fastlane, l’option documentée readonly: true exprime cette intention pour Match. Cette option encadre l’action de Match ; elle ne rend pas le Mac invulnérable, ne bloque pas nécessairement les autres scripts et ne remplace pas les contrôles d’accès au système.

Délimitez clairement les secrets :

• Le dépôt chiffré contenant les ressources de signature ne doit être accessible qu’aux tâches et personnes qui en ont besoin.
• Le secret de déchiffrement doit être stocké dans le mécanisme de secrets du système CI, pas dans le dépôt de code ni dans un script versionné.
• Les tâches de publication ne doivent recevoir leurs secrets que dans un environnement approuvé et selon les règles d’approbation de votre équipe.
• Les journaux doivent être examinés pour éviter d’y exposer des données sensibles ; masquage automatique et absence de fuite ne sont pas synonymes.

Si votre plateforme CI est GitHub Actions, utilisez sa documentation sur la gestion des secrets et sur les risques liés à un exécuteur compromis pour examiner où les secrets sont disponibles et quelles tâches peuvent les demander. Les environnements et règles de protection des déploiements peuvent également servir à encadrer l’accès à une étape sensible. Ces mécanismes ne prouvent pas que le Mac est isolé ; évaluez séparément les comptes, les accès distants, les processus persistants et les autres projets présents sur l’hôte.

Validation sur Mac : accepter le résultat réel

La validation doit porter sur le résultat livré par une tâche réelle, pas seulement sur la présence des fichiers ou le statut du pipeline. Construisez un projet représentatif, produisez son archive, puis vérifiez l’identité de signature et le profil inclus. Pour une équipe qui distribue par plusieurs voies, répétez le contrôle sur les flux effectivement utilisés : un build réussi pour les tests ne valide pas automatiquement le flux de publication.

Comparez les preuves avec la base de référence établie avant le changement. Confirmez que l’identité attendue est utilisée, que le profil correspond à l’application et au mode de distribution, et que l’archive peut suivre le chemin prévu. Examinez les journaux lorsqu’une tâche choisit une identité inattendue ou échoue à accéder à une clé. La couleur verte du pipeline indique seulement que la tâche s’est terminée selon ses propres critères ; elle ne démontre pas que chaque artefact porte la signature attendue.

Liste de contrôle avant extension

Cochez chaque point à partir d’une preuve conservée. Une case non validée signifie que vous ne devez pas étendre la rotation à d’autres tâches de publication ni retirer l’ancienne identité.

• [ ] Le certificat attendu et sa clé privée correspondante sont disponibles dans le trousseau utilisé par la tâche CI.
• [ ] Le profil de provisionnement correspond à l’application, à l’identité de signature et à la voie de distribution testée.
• [ ] Fastlane Match a synchronisé les ressources attendues en lecture seule dans la tâche CI ordinaire.
• [ ] L’archive d’un projet représentatif porte la signature attendue et contient le profil vérifié.
• [ ] Les tâches de production, les Mac de secours et les chemins de publication concernés ont été testés.
• [ ] Les journaux, les résultats d’inspection et la configuration acceptée sont conservés sans divulguer les secrets.

Décision : si toutes les cases sont cochées, autorisez une extension progressive selon le périmètre approuvé. Si une case reste vide, suspendez le changement, gardez l’ancienne configuration disponible et recherchez la cause à partir des journaux et des éléments de signature. Si une tâche critique échoue, revenez à la configuration connue comme fonctionnelle ; ne compensez pas l’échec en révoquant ou en supprimant une ressource non vérifiée.

Cette démarche limite un piège fréquent : traiter chaque tâche verte comme une preuve suffisante. Dans un environnement d’équipe, l’acceptation doit couvrir les Mac actifs et de secours, les applications concernées et les flux de distribution réellement maintenus. Une validation locale réussie ne remplace pas l’essai dans la CI, car l’accès au trousseau, les secrets disponibles et les profils installés peuvent différer entre les environnements.

Retrait des anciennes ressources : clôturer après les preuves

N’envisagez le retrait qu’après la validation des tâches de production, des Mac de secours et de toutes les applications identifiées dans l’inventaire. Vérifiez qu’aucun pipeline planifié, processus de publication secondaire ou environnement d’urgence ne dépend encore de l’ancien profil. La présence d’une nouvelle identité dans le trousseau ne prouve pas que toutes les anciennes références ont disparu.

Décidez ensuite, avec l’approbation prévue par votre organisation, si l’ancienne ressource doit être conservée temporairement, renouvelée ou révoquée. Avant une révocation, contrôlez les profils qui la contiennent, les applications auxquelles ils sont associés et les procédures de récupération disponibles. Puisque la révocation peut invalider les profils concernés, ne supprimez pas en même temps les seuls éléments qui permettraient de diagnostiquer ou de restaurer la chaîne de signature.

Terminez par une trace d’audit compréhensible par l’équipe suivante : propriétaire des ressources, motif du changement, approbations, tâches de validation, résultats d’inspection des archives, décision prise sur les anciens certificats et conditions de retour arrière. Conservez cette trace avec les informations nécessaires pour retrouver la configuration acceptée, sans y exposer les clés privées ou les secrets de déchiffrement.

Pour les tâches de signature, votre choix de Mac compte aussi après la rotation. Un poste déjà mobilisé par plusieurs usages peut rendre l’accès au trousseau, la maîtrise des comptes et la disponibilité des compilations plus difficiles à coordonner ; gérer chaque machine achetée ajoute, de son côté, le suivi du matériel et de sa maintenance. Si vos ressources sont insuffisantes pour un besoin temporaire de validation ou de publication, un Mac distant loué peut offrir un environnement de travail plus prévisible, à condition que vous gardiez la responsabilité des certificats, des profils, des secrets et des règles d’accès. Vous pouvez examiner les offres Mac distantes de VMSPIN et leurs conditions tarifaires, puis vérifier si le mode d’accès et les exigences de votre équipe conviennent. Pour une charge de signature permanente et soutenue, comparez aussi cette option à l’achat et à l’exploitation d’un Mac dédié ; la location n’est pas automatiquement le meilleur choix.