Commencez par ici, puis contactez-nous

Transférez le .p12 vers la machine par un canal sécurisé, importez-le dans un trousseau utilisé pour le build et vérifiez que le fichier contient la clé privée associée. Un certificat sans clé privée ne permet pas de signer le code. Fournissez le mot de passe d’importation via une variable secrète de la CI ; ne l’inscrivez ni dans le dépôt, ni dans un script de commande, ni dans un ticket.

security find-identity -v -p codesigning

Effectuez cette vérification dans l’environnement utilisateur qui exécute réellement le runner. Le fait que le certificat soit visible pour l’utilisateur du bureau ne signifie pas qu’il le soit aussi pour un autre compte de service. Vérifiez également que le trousseau est déverrouillé, qu’il figure dans la liste de recherche de cet utilisateur et que le processus de signature dispose des autorisations nécessaires.

Utilisez un trousseau dédié aux builds et verrouillez-le conformément à votre procédure une fois la tâche terminée. Si vous demandez de l’aide, fournissez uniquement le résultat expurgé de la vérification d’identité et le texte de l’erreur ; n’envoyez ni .p12, ni clé privée, ni mot de passe d’importation.

Vérifiez la cohérence de ces quatre éléments : Bundle ID, Team ID, usage prévu pour l’export et entitlements. Pour une app avec des extensions, chaque Target à signer doit avoir sa propre configuration correspondante. La configuration de l’app principale ne garantit pas celle des extensions.

Vérifiez ensuite que le profil est valide, qu’il inclut le certificat utilisé et que la méthode de signature sélectionnée pour l’export correspond au projet. Les réglages pour les tests de développement diffèrent de ceux d’une distribution ; ne choisissez pas un profil en vous fiant uniquement à son nom.

Conservez les journaux de l’étape d’exportation et une copie expurgée de ExportOptions.plist. Dans votre ticket, précisez si l’échec survient pendant archive ou exportArchive pour réduire immédiatement le périmètre du diagnostic.

Enregistrez le fichier .p8 dans un répertoire à accès restreint et fournissez le Key ID, l’Issuer ID et le chemin du fichier via des variables secrètes de la CI. Accordez uniquement les autorisations nécessaires aux tâches d’envoi ou d’automatisation ; ne copiez pas directement le contenu de la clé dans un lane et ne le validez pas dans le dépôt.

Une clé API peut servir aux procédures d’envoi et de gestion qui prennent en charge cette méthode d’authentification, mais elle ne remplace pas la clé privée du certificat requise pour signer localement le code. En cas d’échec d’envoi vers TestFlight, distinguez une erreur de signature de l’artefact local d’un problème d’authentification à l’API, d’autorisation sur l’app ou de version.

Après une rotation de clé, mettez à jour la configuration du runner et supprimez les anciennes références. Pour obtenir de l’aide, indiquez le code d’erreur expurgé et l’étape concernée ; n’envoyez pas le fichier .p8.

Vérifiez les droits de lecture du dépôt de signature, la phrase secrète de déchiffrement, le type de distribution, l’identifiant de l’app et la configuration de l’équipe. En CI, privilégiez le téléchargement en lecture seule des éléments de signature déjà préparés afin d’éviter toute tentative de création ou de modification de certificats à chaque exécution.

lane :prepare_signing do
  match(
    type: "appstore",
    readonly: true,
    app_identifier: ENV.fetch("APP_IDENTIFIER"),
    team_id: ENV.fetch("TEAM_ID")
  )
end

Gérez séparément les identifiants d’accès au dépôt et la phrase secrète de déchiffrement. En cas d’échec de lecture, vérifiez l’authentification au dépôt ; en cas d’échec de déchiffrement, vérifiez la phrase secrète. Si l’installation réussit mais que la signature échoue, contrôlez le trousseau et le profil de provisioning. Ne regroupez pas ces trois problèmes sous la seule mention « match ne fonctionne pas ».