La rotation des certificats iOS CI en entreprise doit commencer par l’identification du type de certificat et des limites du compte Apple, puis par la mise à jour des profils et une validation complète sur un nœud Mac isolé. Ne basculez les tâches de production qu’après cette validation ; si une clé privée est suspectée compromise, traitez l’incident sans attendre la fin du cycle normal.
Ce guide s’adresse aux responsables IT qui gèrent les comptes Apple Developer et les actifs de signature.
Il concerne aussi les équipes plateforme chargées des profils, des nœuds Mac CI et des publications.
Les responsables sécurité et publication y trouveront les critères permettant de distinguer une rotation planifiée d’une urgence.
[ SECTION_01 ] Avant la rotation : cartographier les actifs et les dépendances
Une rotation ne concerne pas uniquement le fichier du certificat. Une publication dépend de plusieurs éléments distincts : le certificat de signature, sa clé privée, le Provisioning Profile associé, les droits du compte Apple Developer, les secrets de publication et les autorisations du nœud CI. Remplacer un seul élément sans vérifier les autres peut laisser une chaîne incohérente.
Commencez par établir un inventaire par application et par pipeline. Pour chaque cible, consignez l’identifiant d’application, le mode de signature, le profil utilisé, l’identité de signature attendue, l’emplacement de la clé privée et le nœud qui exécute la compilation. Notez également qui peut créer ou révoquer les certificats et qui peut modifier les profils. La documentation des rôles Apple Developer décrit les autorisations associées aux rôles du compte ; il faut comparer ces droits à la répartition réelle des responsabilités de l’équipe.
L’inventaire doit être accompagné d’une référence de fonctionnement : dernier pipeline ayant réussi, journal de compilation correspondant, archive produite et chemin d’export ou de distribution utilisé. Ce sont ces éléments vérifiables qui permettent de distinguer une défaillance de signature d’une erreur d’accès, d’un profil périmé ou d’un problème de publication.
Avant de lancer les changements, désignez un responsable de décision, une personne chargée de l’opération et un approbateur sécurité. Définissez aussi la fenêtre de changement, les applications prioritaires et les conditions qui imposent une pause. Un simple « le build passe » ne suffit pas : la preuve de référence doit couvrir la signature et la destination réelle de l’archive.
Comment rétablir une publication après l’expiration d’un certificat de signature ?
Il faut d’abord identifier le certificat concerné et vérifier que sa clé privée, le profil utilisé et les autorisations de publication sont encore disponibles. Si le certificat est expiré, ne supposez pas que le profil et la chaîne de signature restent valides : examinez leurs états, créez ou activez l’actif de remplacement selon les règles applicables, puis reconstruisez et validez le chemin de livraison sur un nœud isolé avant de reprendre la production.
[ SECTION_02 ] Préparer la rotation selon le type de certificat
Apple décrit plusieurs certificats de développement et de distribution, notamment Apple Development, Apple Distribution, Developer ID Application et Developer ID Installer. Ces catégories répondent à des usages différents ; elles ne sont donc pas interchangeables dans un plan de rotation. La vue d’ensemble officielle des certificats permet de vérifier leur finalité avant toute action.
| Actif à examiner | Usage à confirmer | Point de vigilance pour la rotation |
|---|---|---|
| Apple Development | Développement et tests selon le mode de signature de l’application | Vérifier les profils et les appareils ou environnements de test concernés |
| Apple Distribution | Signature d’une application iOS destinée à la distribution ou à la soumission | Vérifier le profil de distribution associé et le chemin d’export |
| Developer ID Application | Signature d’une application distribuée hors des circuits iOS habituels | Ne pas l’assimiler à un certificat Apple Distribution |
| Developer ID Installer | Signature d’un paquet d’installation macOS | Vérifier le type de livrable ; un paquet macOS n’est pas un binaire iOS |
| Certificat géré dans le nuage | Gestion du certificat de distribution selon les mécanismes Apple disponibles pour le compte | Contrôler les conditions et le flux de signature décrits par Apple avant de modifier l’automatisation |
Un certificat géré dans le nuage ne doit pas être traité comme un certificat local simplement parce que son nom contient « distribution ». Apple documente ses conditions d’utilisation et son fonctionnement dans la page sur les certificats gérés dans le nuage. L’équipe doit confirmer que la méthode de signature de ses nœuds et ses outils sont compatibles avec le mécanisme réellement activé.
Il n’existe pas de garantie générale que tous les types de certificats puissent coexister ou être remplacés sans interruption. Les possibilités dépendent de la catégorie, de l’état du compte et des actifs déjà créés. Vérifiez les limites affichées dans le compte et la documentation correspondante avant de prévoir une validation parallèle. Si le remplacement parallèle n’est pas possible, planifiez une fenêtre contrôlée et documentez les conséquences d’un retour arrière.
La matrice des rôles et autorisations sert également à vérifier qui peut effectuer chaque étape. Évitez de donner des droits élevés à tous les opérateurs CI pour contourner un blocage : les droits de compte et les permissions locales du nœud sont deux périmètres différents.
[ SECTION_03 ] Mettre à jour le Provisioning Profile et l’environnement de signature
Le Provisioning Profile lie des éléments nécessaires à la signature, dont l’application et les conditions de distribution applicables. Un nouveau certificat peut donc exiger un profil mis à jour ou régénéré. Le remplacement du certificat dans le trousseau ne met pas automatiquement à jour le profil déjà utilisé par le pipeline.
Après le remplacement d’un certificat Apple Distribution, faut-il régénérer le Provisioning Profile ?
Il faut vérifier le certificat effectivement associé au profil. Si le nouveau certificat n’y figure pas, mettez à jour ou recréez le profil selon le mode de signature et les règles du compte. Apple détaille la création d’un profil de provisionnement App Store, ainsi que les opérations permettant de modifier, télécharger ou supprimer un profil.
| Mode de signature | Vérifications à effectuer | Preuve attendue |
|---|---|---|
| Signature manuelle | Identifiant d’application, certificat autorisé, capacités et profil explicitement sélectionné | Profil téléchargé correspondant à la configuration prévue et identité de signature attendue |
| Gestion de signature par Xcode | Équipe sélectionnée, état de la signature automatique et profil résolu pour la cible | Journal de compilation montrant les actifs effectivement retenus |
| Plusieurs cibles ou extensions | Profil et autorisations propres à chaque cible, y compris les extensions | Archive inspectée pour confirmer la cohérence de chaque composant signé |
Les capacités de l’application doivent être revérifiées après modification du profil. Un changement d’identifiant, d’entitlements ou de certificat associé peut rendre le profil inadapté au binaire que le pipeline tente de signer. La documentation Apple sur les mises à jour des profils de provisionnement précise les cas où un profil doit être actualisé ; le contrôle doit être réalisé pour le type de profil réellement utilisé, et non déduit d’une configuration voisine.
La distribution App Store, les essais internes et la distribution d’une application macOS n’ont pas nécessairement les mêmes conséquences en cas de révocation ou d’expiration. Avant d’agir, identifiez le canal et les versions déjà distribuées. La page Apple consacrée à la révocation d’un certificat indique que la révocation peut affecter les profils associés. Cela rend indispensable le recensement des profils et des applications dépendantes avant la révocation d’un actif encore utilisé.
Sur chaque nœud, contrôlez séparément le trousseau, la présence de la clé privée, les droits d’accès du compte de service et les secrets de publication. Le certificat public peut être visible sans que la clé privée correspondante soit disponible. Inversement, une clé privée importée dans un trousseau n’accorde pas à elle seule les autorisations nécessaires pour créer un profil ou effectuer une opération dans le compte Apple Developer.
[ SECTION_04 ] Valider sur un nœud isolé avant la production
Le nœud de validation doit utiliser une copie contrôlée de la configuration CI, sans remplacer directement les tâches de publication actives. Sélectionnez une application représentative et son pipeline réel ; une compilation locale ne prouve pas que l’agent CI peut accéder au trousseau, résoudre le profil et produire le livrable attendu.
La validation couvre toute la chaîne : résolution du certificat, accès à la clé privée, signature des différentes cibles, création de l’archive, export et dépôt dans la destination prévue. Examinez les journaux et le résultat signé pour confirmer que l’ancien certificat ou l’ancien profil n’est pas encore sélectionné par une configuration mise en cache. Vérifiez aussi les identifiants utilisés par la publication : une archive valide peut encore échouer au transfert si les accès correspondants sont incorrects.
| Contrôle d’acceptation | Résultat attendu | Motif de refus de bascule |
|---|---|---|
| Identité de signature | Le certificat retenu correspond à l’actif approuvé | Le journal indique un certificat ancien, absent ou inattendu |
| Clé privée | Le processus CI peut l’utiliser sans exposer son contenu | Accès refusé, clé manquante ou secret transmis hors du périmètre prévu |
| Profil | Le profil correspond à l’application, au certificat et aux capacités | Profil périmé, mauvaise cible ou association non confirmée |
| Archive et export | Le livrable passe par le chemin prévu pour sa destination | Signature incomplète ou export impossible |
| Publication | Les droits et identifiants utilisés sont ceux autorisés | Échec de livraison ou permission de compte non validée |
| Traçabilité | Résultats, approbations et décision de bascule sont conservés | Absence de journal ou de responsable identifié |
Comment valider le nouveau certificat sans perturber les publications officielles ?
Faites tourner une tâche de validation sur un nœud isolé, avec une configuration qui n’écrit pas dans la file de publication de production. Utilisez une application représentative, conservez les journaux de signature et confirmez l’export attendu. La bascule n’est autorisée que lorsque l’équipe peut relier le résultat à la configuration, au profil et au certificat approuvés.
Un environnement Mac distant peut servir à isoler cet essai du poste d’un développeur, à condition que les accès au compte, au trousseau et aux secrets soient eux-mêmes maîtrisés. Pour situer cette option par rapport à une machine détenue par l’équipe, la page consacrée à la commande d’un Mac mini fournit un point de comparaison sur le choix d’un nœud Mac. Le choix matériel ne remplace toutefois ni l’isolation des secrets ni la preuve de signature. Les équipes qui souhaitent étudier les options d’environnement Mac distant de NOVAKVM doivent les évaluer au regard de leurs propres exigences d’accès, d’isolement et de publication.
[ SECTION_05 ] Bascule de production et traitement des anciens actifs
Après validation, basculez les tâches par application ou par pipeline, et non par remplacement global sans contrôle. La première livraison de chaque lot doit être observée avant d’étendre la modification. Définissez à l’avance les critères d’arrêt : signature inattendue, profil rejeté, archive différente du résultat accepté ou échec de publication.
La procédure de retour arrière doit préciser ce qui peut effectivement être restauré. Réactiver une ancienne configuration ne restaure pas une clé privée supprimée, ne rétablit pas un certificat révoqué et ne rend pas valide un profil devenu inutilisable. Il faut donc consigner les actifs encore disponibles, leur état et les dépendances avant la bascule. La décision de révoquer l’ancien certificat intervient après confirmation de la stabilité du nouvel actif, sauf événement de sécurité qui impose une action immédiate.
Quand faut-il révoquer l’ancien certificat ?
Dans une rotation planifiée, attendez que les pipelines concernés aient réussi avec le nouvel actif et que les profils dépendants aient été vérifiés. Ensuite, appliquez la procédure correspondant au type de certificat et supprimez les copies inutilisées de clés privées et de profils mis en cache selon les règles internes. En cas de suspicion de compromission, ne conservez pas le certificat en service dans le seul but de préserver une transition confortable.
Que faire si la clé privée paraît divulguée ?
Traitez la situation comme un incident de sécurité : limitez l’exposition, informez les responsables habilités, déterminez quels certificats et profils sont concernés, puis appliquez la révocation et la réparation des profils conformément aux indications Apple. La documentation sur les privilèges de révocation aide à identifier les autorisations nécessaires. N’attendez pas que toutes les files CI aient été migrées si ce délai prolonge une compromission active ; sécurisez la clé, puis rétablissez les publications avec un actif sain.
Les anciens fichiers peuvent rester présents sur des agents, dans des caches ou dans des sauvegardes. Après la bascule, inventoriez ces emplacements et retirez les copies qui ne sont plus nécessaires selon la politique de conservation de l’entreprise. Contrôlez aussi les journaux d’accès et l’historique des changements : une clé privée ne doit pas être copiée dans les journaux de compilation ni distribuée à des comptes qui n’en ont pas besoin.
[ SECTION_06 ] Liste de contrôle de mise en production
- [ ] L’équipe a identifié le type de certificat et le canal de distribution concernés.
- [ ] Les applications, cibles, pipelines, nœuds Mac, profils et emplacements de clés privées sont inventoriés.
- [ ] Les rôles Apple Developer et les responsables de création, approbation et révocation sont confirmés.
- [ ] Les contraintes de création ou de coexistence ont été vérifiées pour l’état réel du compte.
- [ ] Le profil a été actualisé lorsque le nouveau certificat ou les capacités de l’application l’exigent.
- [ ] Le nœud isolé a terminé la signature, l’archivage, l’export et le contrôle de la destination.
- [ ] Les critères de pause, de retour arrière et de reprise sont documentés avant la bascule.
- [ ] Le premier lot de production a été contrôlé avant l’extension aux autres pipelines.
- [ ] Les anciens certificats, clés privées et profils mis en cache ont été traités selon leur état et les règles applicables.
- [ ] Toute suspicion de fuite a déclenché le processus d’incident, sans attendre la fin d’une rotation ordinaire.
Une rotation maîtrisée repose sur une chaîne de preuves, pas sur le seul remplacement d’un certificat : inventaire vérifiable, profil cohérent, essai isolé et bascule avec seuils d’arrêt. Une machine déjà achetée peut être adaptée si elle est disponible, correctement isolée et administrée ; elle implique toutefois l’achat du matériel, son entretien et la gestion de sa capacité. Une infrastructure CI partagée peut réduire l’investissement matériel initial, mais elle demande une séparation rigoureuse des identités et des secrets, ainsi qu’une vérification des accès et des dépendances. Pour un essai ou une capacité Mac temporaire, la location d’un Mac auprès de NOVAKVM peut fournir un environnement distant à évaluer avant d’y confier des tâches de publication. Le choix doit suivre les exigences de sécurité, la durée du besoin et les contraintes d’accès physique de l’équipe, et non une promesse générale de bascule sans interruption.