Deux heures du matin : la troisième personne de l'équipe lance un fastlane build sur le même Cloud Mac, et la CI échoue immédiatement — certificat invalide. Chacun des trois avait exécuté match en local sans remarquer que son opération venait d'évincer, de la Keychain système par défaut, le certificat de signature que le collègue venait d'importer. Ce genre d'incident est presque inévitable dès que plusieurs personnes partagent un même Cloud Mac pour builder des packages. Cet article documente comment nous avons centralisé la gestion des certificats avec fastlane match, et résolu le problème des demandes répétées de mot de passe de la Keychain en session distante sans surveillance.
Le problème : pourquoi un Cloud Mac partagé multiplie les incidents de certificats
En développement local, un Mac ne sert généralement qu'à une seule personne, donc les certificats déposés dans la Keychain par défaut ne se disputent jamais la place. Mais un Cloud Mac loué à la journée est souvent partagé par toute l'équipe : aujourd'hui vous vous connectez pour builder, demain un collègue se connecte à distance pour modifier une configuration et relancer un build. Si chacun exécute fastlane match development de son côté, ou importe manuellement un p12, les entrées de certificat dans la Keychain par défaut se retrouvent sans cesse écrasées, supprimées puis recréées — jusqu'à l'erreur classique « le certificat existe mais la clé privée introuvable au moment de signer ».
La cause profonde tient au mélange de deux choses distinctes : le stockage et la distribution des certificats, d'un côté, et leur autorisation temporaire dans la Keychain locale, de l'autre. La première doit être centralisée ; la seconde doit être isolée par session.
Le principe central de fastlane match
match chiffre les certificats de développement et de distribution ainsi que les profils de provisioning correspondants, et les stocke de façon centralisée dans un dépôt Git dédié. Toute l'équipe — ainsi que l'utilisateur d'automatisation sur le Cloud Mac — récupère les mêmes certificats depuis ce dépôt, au lieu de les régénérer chacun de son côté dans le portail Apple Developer. Cela garantit un résultat de signature identique pour un même Bundle ID sur n'importe quelle machine, et évite le vieux problème du « nombre de certificats dépassant la limite Apple ».
La valeur de match n'est pas de « générer automatiquement des certificats », mais de faire en sorte que « personne n'ait plus besoin de générer ses propres certificats » — cette phrase détermine son usage correct : une seule personne (ou une tâche d'initialisation CI unique) doit effectuer les écritures, tous les autres cas d'usage doivent se contenter d'un mode lecture seule.
Initialiser le dépôt de certificats sur le Cloud Mac
Dans le répertoire du projet sur votre Cloud Mac, vérifiez d'abord que le Matchfile pointe vers un dépôt privé et non une adresse publique :
git_url("git@github.com:your-org/certs-private.git")
storage_mode("git")
type("appstore")
L'initialisation initiale ne s'exécute qu'une seule fois, sur une machine de confiance :
fastlane match appstore --readonly false
Ensuite, toutes les opérations de récupération sur les Cloud Mac doivent inclure --readonly true, afin de garantir qu'elles se limitent à lire les certificats existants sans jamais tenter d'en régénérer :
fastlane match appstore --readonly true
Attribuez à l'utilisateur de déploiement une deploy key Git en lecture seule dédiée, plutôt que d'entasser les clés SSH personnelles de tous les membres de l'équipe sur le Cloud Mac — les frontières de permission sont plus claires, et il n'est pas nécessaire de révoquer les accès un par un à chaque changement d'effectif.
Déverrouillage sans mot de passe de la Keychain en session distante headless
Les Cloud Mac sont le plus souvent pilotés à distance via SSH ou VNC, sans personne physiquement devant l'écran pour saisir un mot de passe. La Keychain de connexion par défaut se retrouve donc fréquemment verrouillée entre les sessions, et dès qu'on exécute codesign, une boîte de dialogue d'autorisation apparaît — ce qui bloque net les scénarios de déclenchement CI sans surveillance.
La solution consiste à créer une Keychain de signature dédiée, distincte de la Keychain de connexion :
security create-keychain -p "$KEYCHAIN_PWD" signing.keychain
security set-keychain-settings -lut 21600 signing.keychain
security unlock-keychain -p "$KEYCHAIN_PWD" signing.keychain
security import cert.p12 -k signing.keychain -P "$P12_PWD" -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PWD" signing.keychain
list=$(security list-keychains -d user | tr -d '"')
security list-keychains -d user -s signing.keychain $list
L'étape set-key-partition-list est facile à oublier ; sans elle, codesign continue de réclamer une autorisation via boîte de dialogue, même une fois la Keychain déverrouillée. Cette Keychain dédiée devrait ne contenir que les certificats nécessaires à la signature, sans y mélanger des mots de passe du quotidien : lors de la restitution de l'instance louée ou du transfert du projet, il est bien plus simple de la supprimer entièrement que de nettoyer la Keychain par défaut.
Récupération des certificats et nettoyage après déclenchement CI
Pour un flux automatisé, il est recommandé de suivre l'ordre ci-dessous, chaque échec devant arrêter immédiatement le pipeline plutôt que de laisser la suite s'exécuter silencieusement :
| Étape | Commande/action | Traitement en cas d'échec |
|---|---|---|
| Déverrouiller la Keychain dédiée | security unlock-keychain |
Arrêt immédiat, ouverture d'un ticket plutôt qu'une nouvelle tentative silencieuse |
| Récupérer les certificats en lecture seule | fastlane match … --readonly true |
Arrêt, indiquer qu'une écriture doit d'abord être exécutée sur la machine principale |
| Exécuter le build | xcodebuild archive |
Conserver les logs de build pour investigation |
| Nettoyer les références de Keychain temporaires | security delete-keychain signing.keychain (selon besoin) |
Enregistrer si le nettoyage a réussi |
Si le Cloud Mac est loué à la journée puis transféré à une autre tâche ou restitué en fin de location, cette dernière étape de nettoyage est particulièrement importante : la Keychain de signature dédiée, les fichiers p12 téléchargés temporairement, et les profils de provisioning dans ~/Library/MobileDevice/Provisioning Profiles doivent tous être supprimés à la fin de la tâche — ne comptez pas sur le fait que la période de location suivante héritera automatiquement d'un environnement propre. Pour vérifier si un modèle et un nœud donnés correspondent aux besoins de build concurrent de votre équipe, mieux vaut confirmer les configurations disponibles dans la console avant de planifier : les écarts de vitesse de compilation entre puces différentes affectent directement le temps d'attente lorsque plusieurs personnes font la queue.
Collaboration d'équipe et frontières de permission
Bien séparer les responsabilités évite beaucoup de temps de dépannage par la suite :
- Droit d'écriture sur les certificats : à confier à une seule personne ou à un pipeline d'initialisation unique ; les membres au quotidien et les comptes d'automatisation sur les Cloud Mac utilisent uniformément
--readonly true. - Droit d'accès au dépôt : le dépôt de certificats utilise des deploy keys plutôt que des clés de compte personnelles, ce qui permet une révocation ciblée par personne ou par machine.
- Isolation des Keychain locales : chaque utilisateur ou chaque ligne de build parallèle dispose de son propre fichier Keychain et de son propre répertoire de build, pour éviter que la Keychain par défaut ne soit écrasée mutuellement.
- Stockage des mots de passe et tokens :
KEYCHAIN_PWD,P12_PWDet les deploy keys Git sont injectés via des variables d'environnement ou des variables chiffrées de la CI, jamais écrits en dur dans les scripts.
Liste de vérification avant mise en production
- [ ] Le
Matchfilepointe vers un dépôt privé, et personne dans l'équipe n'a jamais stocké d'historique de certificats dans un dépôt public ; - [ ] Toutes les commandes match exécutées sur les Cloud Mac incluent
--readonly true; - [ ]
set-key-partition-lista été exécuté sur la Keychain de signature dédiée, etcodesignne fait plus apparaître de boîte de dialogue ; - [ ] Chaque utilisateur ou ligne de build parallèle dispose d'un fichier Keychain et d'un répertoire de build indépendants ;
- [ ] Un script de nettoyage supprime la Keychain dédiée et les profils de provisioning temporaires avant la fin de la tâche ou de la période de location.
Une fois la gestion des certificats et le déverrouillage de la Keychain traités séparément, les builds alternés de l'équipe sur un même Cloud Mac ne se marchent plus dessus. Les nouveaux membres du projet n'ont plus qu'à cloner le dépôt une fois et exécuter la commande en lecture seule, sans jamais avoir à redemander de certificats.
Questions fréquentes
Le dépôt de certificats match peut-il être un dépôt Git public ?
Non. match chiffre les certificats p12 et les profils de provisionnement avant stockage, mais un dépôt public expose quand même la structure et les métadonnées. Utilisez un dépôt privé et délivrez un jeton en lecture seule à l'utilisateur de déploiement sur le Cloud Mac.
Dois-je retaper le mot de passe Keychain à chaque redémarrage du Cloud Mac ?
Non. Créez un keychain de signature dédié avec security create-keychain et un mot de passe fixe, désactivez le verrouillage automatique avec security set-keychain-settings, autorisez codesign avec -A sans confirmation, puis exécutez le script de déverrouillage une fois après chaque nouvelle connexion de session.
Les certificats se bloquent-ils si plusieurs personnes buildent sur le même Cloud Mac ?
Oui, si chacun exécute match séparément, le keychain par défaut est importé et exporté à répétition, ce qui crée des conflits. Attribuez à chaque personne un répertoire de build et un fichier keychain dédiés, et utilisez le mode readonly de match pour ne lire que les certificats existants sans les régénérer.
HireVPS
Essayez dès aujourd'hui un Mac mini dédié dans le cloud
Location à la journée, identifiants SSH/VNC en 2 minutes, configuration évolutive à tout moment.