Certificats iOS et Profils de Provisionnement Expliqués

iOS code de signature utilise deux pièces. Un certificat prouve qui a construit l'application, et un profil de provisionnement détermine laquelle est l'application, lesquels appareils peuvent l'exécuter et lesquels capacités elle peut utiliser. Xcode refuse de construire pour un appareil, et App Store Connect refuse les téléchargements, à moins que le certificat, sa clé privée et un profil correspondant soient alignés.

Cet guide explique chaque pièce, laquelle combinaison vous est nécessaire pour le développement, les builds ad hoc, TestFlight, App Store et les builds d'entreprise, comment les créer avec ou sans Mac, et comment résoudre les erreurs que vous rencontrerez.

Pourquoi Apple exige code de signature

Apple ne permet aux iPhones que de lancer des code que Apple peut relier à un développeur connu.

1. Identité: le fichier binaire a été signé par un membre d'une équipe de développeurs Apple spécifique.
2. Intégrité: personne n'a modifié le code après signature. Changement d'un seul octet brise la signature.
3. Autorisation: l'application est autorisée sur cet appareil, avec ces autorisations (push, iCloud, connexion avec Apple, groupes d'applications et ainsi de suite).

Les certificats fournissent les deux premiers. Les profils de provisionnement fournissent le troisième.

Les blocs de construction

La confusion la plus courante : un .cer Un fichier est inutile en soi. La signature nécessite la clé privée qui a créé le CSR. Si vous perdez cette clé, vous créez un nouveau certificat.

Types de certificats

Apple Développement

Utilisé pour exécuter des builds sur vos propres appareils à partir de Xcode pendant le développement. Les certificats de développement appartiennent à un développeur individuel, et Apple les étiquette avec le nom du ordinateur. Chaque développeur de l'équipe peut en avoir son propre.

Distribution Apple

Utilisé pour signer des builds pour la distribution Ad Hoc, TestFlight et l'App Store. Les certificats de distribution appartiennent à l'équipe, et seuls les rôles d'Administrateur ou de Responsable de compte peuvent les créer. Apple limite le nombre de certificats que peut détenir une équipe, il est donc préférable de partager un seul à travers un magasin sécurisé plutôt que de laisser chaque développeur créer son propre.

On peut encore voir iOS Développement et Distribution iOS in older accounts. Those are the pre-Xcode 11 types. Apple Development and Apple Distribution replace them and work across iOS, iPadOS, macOS, tvOS, watchOS and visionOS.

Other certificate types you may meet

• Identifiant d'application / Installeur: pour les applications Mac distribuées en dehors de l'App Store Mac. Non utilisé pour iOS.
• Service de notification Push d'Apple SSLApple Push Notification service SSL : certificats de push legacy. Préférez un (.p8) qui ne expire pas chaque année et fonctionne pour chaque application de l'équipe. Consultez notre Guide des certificats APNs.
• guide des certificats APNs, ID de type de billet, ID de Push du site: services spécifiques.

Profils de provisionnement

Un profil est lié à one App IDSi votre application a des extensions (une icône, une extension de service de notification, une extension de partage), chaque cible a son propre ID de bundle et nécessite son propre profil.

Comment les pièces s'emboîtent

Lorsque Xcode ou un service de construction signe votre Capacitor application, il vérifie :

1. Que l'ID de bundle de votre cible (par exemple com.example.app) correspond à l'ID d'application du profil.
2. Que le certificat utilisé pour la signature figure parmi les certificats listés dans le profil.
3. Que la clé privée pour ce certificat est disponible dans la clé de chaîne.
4. Pour les builds de développement et ad hoc, l'UDID du dispositif figure dans le profil.
5. Le fichier d'autorisations (push, domaines associés, groupes d'applications) est un sous-ensemble de ce que l'ID d'application et le profil autorisent.

Si une vérification échoue, vous obtenez une erreur de signature, pas une panne au runtime, ce qui est bien : vous découvrez avant la livraison.

Quelle combinaison ai-je besoin ?

TestFlight utilise le même même signage que l'App Store. Il n'y a pas de profil TestFlight séparé. Vous téléchargez une seule version et décidez dans App Store Connect si elle est destinée aux testeurs, à la revue, ou les deux.

Créer des certificats et des profils

Option 1 : laissez Xcode gérer la signature

Pour le développement local, c'est la solution la plus facile. Ouvrez ios/App/App.xcworkspace (ou le .xcodeproj lorsque votre Capacitor 8 projet utilise le gestionnaire de packages Swift), sélectionnez le App target, ouvrez Signage & Capacités, cochez gestion automatique de signature et choisissez votre équipe. Xcode crée le certificat de développement, enregistre le périphérique connecté et génère des profils pour vous.

La signature automatique devient douloureuse en CI, car la machine de build a besoin d'accès au compte d'équipe et crée des certificats par elle-même. La plupart des équipes passent à la signature manuelle, ou à un service de build avec une signature basée sur une clé API pour les builds de production.

Option 2 : les créer manuellement sur un Mac

1. Ouvrez Clés d'accès > Assistant de certificat > Demandez un certificat à une autorité de certification. Entrez votre adresse e-mail, choisissez Enregistré sur le disque. Cela crée la clé privée dans votre clé d'accès et un .certSigningRequest fichier.
2. Allez dans le portail Apple Developer Certificats, identifiants et profils > Certificats > +, choisissez Distribution d'Apple (ou développement d'Apple) et téléchargez le CSR.
3. Téléchargez le .cer et double-cliquez dessus. L'Accès à la clé de cryptage l'associe à la clé privée.
4. Pour exporter pour CI : dans Keychain Access, sous Mes certificats, right-click the certificate, choose ExporterEnregistrez sous .p12 avec un mot de passe fort.

Option 3 : créez-les sans Mac

Vous pouvez effectuer l'ensemble du flux avec OpenSSL sur Linux ou Windows :

# 1. Private key and CSR
openssl genrsa -out ios_distribution.key 2048
openssl req -new -key ios_distribution.key -out ios_distribution.csr \
  -subj "/emailAddress=you@example.com/CN=Example Inc/C=US"

# 2. Upload ios_distribution.csr in the Apple Developer portal,
#    download the certificate as distribution.cer

# 3. Convert the .cer (DER) to PEM
openssl x509 -in distribution.cer -inform DER -out distribution.pem -outform PEM

# 4. Build the .p12 (signing identity)
openssl pkcs12 -export -inkey ios_distribution.key -in distribution.pem \
  -out ios_distribution.p12 -legacy

Le -legacy drapeau compte avec OpenSSL 3 : sans lui, les .p12 utilise des algorithmes d'encryption que les outils de clés de macOS rejettent avec un « mot de passe invalide » même lorsque le mot de passe est correct.

Si vous préférez ne pas installer OpenSSL, le générateur de certificats iOS crée le CSR et la clé privée pour vous. Ils proviennent d'un point de terminaison Capgo sans état qui ne les stocke pas, et seulement son .cer à .p12 convertisseur fonctionne entièrement dans votre navigateur. Si votre politique exige que la clé soit générée sur votre machine, utilisez les commandes OpenSSL ci-dessus.

La création du profil

1. Identifiants > +: enregistrer un ID d'application avec votre ID de bundle exact et activer les capacités que vous utilisez (Notifications Push, Sign in with Apple, Domaines associés…).
2. Appareils > +: pour les profils de développement et ad hoc, enregistrez l'UDID de chaque testeur. Les testeurs peuvent l'obtenir sur leur téléphone lui-même avec le Identificateur UDID iOS, sans Mac ni câble nécessaire.
3. Profils > +: choisissez le type de profil, l'ID d'application, le certificat(s) et les appareils. Nommez-le clairement, par exemple com.example.app AppStore 2026.
4. Téléchargez le .mobileprovision fichier.

Si vous ajoutez un appareil ou une capacité plus tard, vous devez régénérer et rétélécharger le profil. Les profils existants ne se mettent pas à jour automatiquement.

Inspecter un profil

Un .mobileprovision fichier est un plist signé. Sur macOS, vous pouvez le lire :

security cms -D -i App_Store.mobileprovision > profile.plist
/usr/libexec/PlistBuddy -c "Print :Name" profile.plist
/usr/libexec/PlistBuddy -c "Print :ExpirationDate" profile.plist
/usr/libexec/PlistBuddy -c "Print :Entitlements" profile.plist
/usr/libexec/PlistBuddy -c "Print :ProvisionedDevices" profile.plist

Sur Linux, openssl smime -inform der -verify -noverify -in App_Store.mobileprovision affiche le plist.

Pour vérifier ce qu'un bâtiment .ipa était signé avec :

unzip -q App.ipa -d ipa
codesign -dvv ipa/Payload/App.app
codesign -d --entitlements :- ipa/Payload/App.app

Expiry et renouvellement

• Certificats sont valides pendant une année à partir de la création.
• Profils de provisionnement expirent après une année, ou plus tôt si le certificat qu'ils incluent expire ou est révoqué.
• Les applications App Store continuent de fonctionner après que le certificat de distribution expire. Apple re-signe les téléchargements App Store. Vous n'avez besoin que d'un nouveau certificat pour télécharger de nouvelles versions.
• Les builds Ad Hoc et de développement cessent de lancer once their profile expires. Testers see the app crash on launch.
• les builds de TestFlight expirent 90 jours après téléchargement, indépendamment du certificat.
• les applications Enterprise cessent de fonctionner sur chaque appareil lorsque le certificat Enterprise expire ou est révoqué. Renouvelez avant l'expiration.
• les emplacements de dispositif Réinitialiser une fois par an d'adhésion. Supprimer un appareil n'affecte pas son emplacement avant le début de l'année d'adhésion suivante.

Insérez la date d'expiration du certificat dans un calendrier partagé. Notre guide de gestion de certificat aborde en profondeur le suivi et la rotation.

Erreurs et corrections courantes

“Aucun certificat de signature ‘iOS Distribution’ trouvé” ou “Le certificat de signature est invalide” : la clé privée n'est pas dans ce cléchain. Importez-la .p12, ou créez un nouveau certificat si personne n'a la clé.

Le profil de provisionnement ne contient pas de certificat de signature. : le profil a été créé avec un certificat différent. Éditez le profil dans le portail, cochez le certificat actuel, régénérez et téléchargez.

“Le profil de provisionnement ne comprend pas le dispositif sélectionné actuellement” : enregistrez l'UDID, puis régénérez le profil. Pas nécessaire pour TestFlight ou App Store.

“Le profil de provisionnement ne prend pas en charge la capacité de notifications Push” : activez la capacité sur l'ID d'application, puis régénérez le profil. Les profils sont des instantanés.

“Un profil de provisionnement valide pour cet exécutable n'a pas été trouvé” à l'installation : le dispositif n'est pas dans le profil ad hoc, ou le profil a expiré.

L'application s'installe puis se ferme immédiatement: sur iOS 16 et ultérieur, les builds de développement et ad hoc nécessitent le mode développeur activé sur l'appareil. Consultez comment activer le mode développeur sur iOS.

Les extensions échouent à signer: chaque cible d'extension nécessite son propre ID d'application et son profil. Vérifiez chaque cible dans l'onglet Signage & Capacités, et non seulement l'application.

Mot de passe invalide lors de l'importation d'un fichier .p12 créé sous Linux: reconstruisez-l’avec openssl pkcs12 -export ... -legacy.

L'upload est refusé pour la version SDK: depuis avril 2026, App Store Connect exige que les builds soient créés avec Xcode 26 et l'iOS 26 SDK. Mettez à jour Xcode ou votre image CI. Capacitor 8 nécessite déjà Xcode 26.

Bonnes pratiques pour les équipes

• Une seule certification Apple Distribution par équipe, stockée sous la forme d'un .p12 enregistrer le mot de passe séparément dans un gestionnaire de mots de passe ou un magasin de secrets.
• Ne jamais envoyer .p12 des fichiers ou les commiter sur Git.
• Utilisez les clés App Store Connect API (.p8) au lieu de mots de passe Apple ID pour les téléchargements.
• Nommez les profils avec l'ID de l'application, le type et l'année.
• Révoquez les certificats des personnes qui quittent l'équipe.
• Tenez une liste écrite de tous les identifiants de bundle, d'extensions et de capacités que l'application utilise.

Signature de cloud pour les applications Capacitor

Vous n'avez pas besoin d'un Mac sur chaque bureau de développeur pour déployer des builds iOS. Capgo Construction builds Capacitor apps on Capgo’s macOS machines using a .p12 and profile you provide. Credentials are used only for the build and not stored on Capgo servers. Save them once from the CLI:

bunx @capgo/cli@latest build credentials save --appId com.example.app --platform ios
bunx @capgo/cli@latest build request com.example.app --platform ios --path .

Le Capgo Construire les documents iOS liste exactement les options de crédentials, y compris les clés App Store Connect API pour l'envoi vers TestFlight ad_hoc mode pour les builds de testeurs.

Une fois votre première build est dans TestFlight, vous pouvez envoyer des modifications JavaScript et des actifs aux utilisateurs avec Capgo mises à jour en direct sans ré-signer un nouveau binaire pour chaque correction. Les modifications natives code et les nouvelles capacités nécessitent toujours une build signée via l'application.

Étapes suivantes

• Avez-vous des comptes ? Comment créer des comptes développeurs Apple et Google Play.
• Comment créer des comptes développeurs Apple et Google Play Prêt à livrer des builds aux testeurs ?.
• Soumettre ? Lisez notre guide de soumission d'applications iOS.