iOS-Zertifikate und Provisioning Profiles erklärt

Das iOS-code-Signing besteht aus zwei Teilen. Ein Zertifikat bestätigt, wer die App gebaut hat, und ein Provisioning Profile legt fest, um welche App es sich handelt, welche Geräte sie ausführen dürfen und welche Capabilities sie nutzen kann. Xcode verweigert den Build für ein Gerät und App Store Connect lehnt Uploads ab, wenn das Zertifikat, der private Key und das passende Profil nicht exakt zusammenpassen.

Dieser Guide erklärt alle Komponenten, welche Kombination du für Development, Ad Hoc, TestFlight, App Store und Enterprise Builds benötigst, wie du sie mit oder ohne Mac erstellst und wie du die auftretenden Fehler behebst.

Warum Apple code Signing benötigt

Apple lässt auf iPhones nur code laufen, die Apple einem bekannten Developer zuordnen kann. Das Signing gibt Apple drei Garantien:

1. Identität: die Binary wurde von einem Mitglied eines spezifischen Apple Developer Teams signiert.
2. Integrität: niemand die Binary nach dem Signing verändert hat. Schon die Änderung eines einzelnen Bytes bricht die Signatur.
3. Autorisierung: die App auf diesem Gerät mit diesen Entitlements (Push, iCloud, Sign in with Apple, App Groups usw.) erlaubt ist.

Zertifikate liefern die ersten beiden. Provisioning Profiles das dritte.

Die Grundbausteine

Die häufigste Verwechslung: eine .cer Datei allein ist nutzlos. Signing benötigt den Private Key, mit dem der CSR erstellt wurde. Wenn du diesen Key verlierst, erstellst du ein neues Zertifikat.

Zertifikatstypen

Apple-Entwicklung

Wird verwendet, um während der Entwicklung Builds aus Xcode auf eigenen Geräten auszuführen. Development-Zertifikate gehören zu einem einzelnen Entwickler, und Apple versieht sie mit dem Computernamen. Jeder Entwickler im Team kann ein eigenes haben.

Apple Distribution

Wird zum Signieren von Builds für Ad-Hoc-Verteilung, TestFlight und den App Store verwendet. Distribution-Zertifikate gehören zum Team, und nur Account Holder oder Admins können sie erstellen. Apple begrenzt die Anzahl pro Team, daher ein Zertifikat über einen sicheren Store teilen, statt dass jeder Entwickler sein eigenes anlegt.

Du siehst möglicherweise noch iOS-Entwicklung und iOS-Distribution in älteren Accounts. Das sind die Typen vor Xcode 11. Apple Development und Apple Distribution ersetzen sie und funktionieren über iOS, iPadOS, macOS, tvOS, watchOS und visionOS hinweg.

Weitere Zertifikatstypen, die dir begegnen können

• Developer ID Application / Installer: für Mac-Apps, die außerhalb des Mac App Store verteilt werden. Nicht für iOS verwendet.
• SSL für den Apple Push Notification service: Legacy-Push-Zertifikate. Besser einen APNs Auth Key (.p8), der nicht jährlich abläuft und für jede App im Team funktioniert. Siehe unseren APNs-Zertifikate-Guide.
• Apple Pay Merchant Identity, Pass Type ID, Website-Push-ID: bestimmte Dienste.

Provisioning-Profile-Typen

Ein Profil ist an eine App IDgebunden. Wenn Ihre App Erweiterungen hat (Widget, Notification Service Extension, Share Extension), hat jedes Target seine eigene Bundle ID und benötigt ein eigenes Profil.

Wie alles zusammenpasst

Wenn Xcode oder ein Build-Service Ihre Capacitor-App signiert, prüft es:

1. Die Bundle-ID in deinem Target (zum Beispiel com.example.app) entspricht der App-ID im Profil.
2. Das Zertifikat, das zum Signieren verwendet wird, ist eines der im Profil aufgeführten Zertifikate.
3. Der private Schlüssel für dieses Zertifikat ist im Keychain verfügbar.
4. Für Development- und Ad-hoc-Builds ist die UDID des Geräts im Profil hinterlegt.
5. Die Entitlements-Datei (Push, Associated Domains, App Groups) ist eine Teilmenge dessen, was die App-ID und das Profil erlauben.

Scheitert eine Prüfung, erhältst du einen Signing-Fehler statt eines Runtime-Crashs – das ist gut: Du merkst es, bevor du shippst.

Welche Kombination brauche ich?

TestFlight verwendet die gleich Signatur wie der App Store. Es gibt kein separates TestFlight-Profil. Du lädst einen Build hoch und entscheidest in App Store Connect, ob er an Tester geht, zur Prüfung oder beides.

Zertifikate und Profile erstellen

Option 1: Xcode das Signing verwalten lassen

Für die lokale Entwicklung ist das am einfachsten. Öffne ios/App/App.xcworkspace (oder die .xcodeproj , wenn dein Capacitor 8-Projekt Swift Package Manager nutzt), wähle die App hinzu Target, öffne Signing & Capabilities, tick Signierung automatisch verwalten und wähle dein Team. Xcode erstellt das Entwicklungszertifikat, registriert das verbundene Gerät und generiert die Profile für dich.

Automatische Signierung wird in CI mühsam, weil die Build-Maschine Zugriff auf das Team-Konto braucht und selbst Zertifikate erstellt. Die meisten Teams wechseln für Release-Builds zu manuellem Signing oder zu einem Build-Service mit API-Key-basiertem Signing.

Option 2: Manuell auf einem Mac erstellen

1. Öffne Keychain-Zugriff > Zertifikatsassistent > Zertifikat von einer Zertifizierungsstelle anfordern. E-Mail-Adresse eingeben, auswählen Auf Disk speichern. Dadurch wird der private Schlüssel in Ihrem Keychain und eine .certSigningRequest Datei.
2. Gehen Sie im Apple Developer Portal zu Zertifikate, Kennungen & Profile > Zertifikate > +, wähle Apple Distribution (oder Apple Development) und laden Sie die CSR hoch.
3. Laden Sie die .cer und doppelklicken Sie darauf. Keychain Access ordnet es dem privaten Schlüssel zu.
4. Zum Export für CI: In Keychain Access, unter Meine Zertifikate, Rechtsklick auf das Zertifikat und wählen Sie Exportieren, speichern unter .p12 mit einem starken Passwort.

Option 3: Ohne Mac erstellen

Den kompletten Flow kannst du mit OpenSSL unter Linux oder Windows erledigen:

# 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

Der -legacy das Flag ist bei OpenSSL 3 wichtig: Ohne es .p12 werden Verschlüsselungsalgorithmen verwendet, die macOS-Keychain-Tools mit einem „invalid password“-Fehler ablehnen, selbst wenn das Passwort korrekt ist.

Wenn Sie OpenSSL nicht installieren möchten, ist iOS-Zertifikatsgenerator den CSR und den Private Key für dich. Diese stammen von einem stateless Capgo Endpoint, der sie nicht speichert und nur sein .cer zu .p12 Der Converter läuft komplett in deinem Browser. Falls es deine Vorgaben erfordern, dass der Key auf deinem Rechner generiert wird, nutze die oben genannten OpenSSL-Befehle.

Profil erstellen

1. Identifiers > +: Registriere eine App ID mit deiner exakten Bundle ID und aktiviere die Capabilities, die du nutzt (Push Notifications, Sign in with Apple, Associated Domains…).
2. Devices > +: Für Development- und Ad-hoc-Profile musst du die UDID jedes Testers registrieren. Tester können diese direkt am Gerät über den iOS UDID Finderermitteln, ganz ohne Mac oder Kabel.
3. Profiles > +: Wähle den Profiltyp, die App ID, das/die Zertifikat(e) und die Geräte aus. Gib ihm einen klaren Namen, zum Beispiel com.example.app AppStore 2026.
4. Laden Sie die .mobileprovision Datei.

Wenn du später ein Gerät oder eine Capability hinzufügst, musst du das Profil neu generieren und erneut herunterladen. Bestehende Profile aktualisieren sich nicht von selbst.

Ein Profil prüfen

Ein .mobileprovision Die Datei ist eine signierte plist. Unter macOS kannst du sie so lesen:

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

Unter Linux, openssl smime -inform der -verify -noverify -in App_Store.mobileprovision gibt die plist aus.

Um zu prüfen, womit ein Build .ipa signiert wurde:

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

Ablauf und Erneuerung

• Zertifikate sind ab Erstellung ein Jahr lang gültig.
• Provisioning-Profile nach einem Jahr ablaufen oder früher, wenn das darin enthaltene Zertifikat abläuft oder widerrufen wird.
• App-Store-Apps funktionieren weiter nach Ablauf des Distribution-Zertifikats. Apple signiert App-Store-Downloads neu. Du brauchst nur ein neues Zertifikat, um neue Builds hochzuladen.
• Ad-Hoc- und Development-Builds starten nicht mehr sobald ihr Profil abläuft. Tester sehen die App beim Start abstürzen.
• TestFlight-Builds laufen 90 Tage nach dem Upload ab, unabhängig vom Zertifikat.
• Enterprise-Apps funktionieren nicht mehr auf jedem Gerät, wenn das Enterprise-Zertifikat abläuft oder widerrufen wird. Erneuern Sie es vor Ablauf.
• Geräte-Slots werden einmal pro Mitgliedschaftsjahr zurückgesetzt. Das Entfernen eines Geräts gibt seinen Slot erst zum Beginn des nächsten Mitgliedschaftsjahres frei.

Tragen Sie das Ablaufdatum des Zertifikats in einen geteilten Kalender ein. Unser Zertifikatsmanagement-Guide geht auf Monitoring und Rotation näher ein.

Häufige Fehler und Lösungen

„Kein Signierzertifikat ‚iOS Distribution‘ gefunden“ oder „Signierzertifikat ist ungültig“: Der private Schlüssel befindet sich nicht in diesem Keychain. Importieren Sie .p12, oder erstellen Sie ein neues Zertifikat, falls niemand den Schlüssel hat.

„Provisioning Profile enthält kein Signing-Zertifikat“: Das Profil wurde mit einem anderen Zertifikat erstellt. Bearbeiten Sie das Profil im Portal, haken Sie das aktuelle Zertifikat an, generieren Sie es neu und laden Sie es herunter.

„Provisioning-Profil enthält das aktuell ausgewählte Gerät nicht“: Registrieren Sie die UDID und generieren Sie das Profil neu. Für TestFlight oder App Store nicht erforderlich.

„Provisioning-Profil unterstützt die Push-Notifications-Capability nicht“: Aktivieren Sie die Capability für die App ID und generieren Sie das Profil neu. Profile sind Snapshots.

„Für diese ausführbare Datei wurde kein gültiges Provisioning-Profil gefunden“ bei der Installation: Das Gerät ist nicht im Ad-hoc-Profil enthalten oder das Profil ist abgelaufen.

App wird installiert und schließt sich sofort: Ab iOS 16 erfordern Development- und Ad-hoc-Builds auf dem Gerät die Aktivierung des Entwicklermodus. Siehe wie Sie den Entwicklermodus unter iOS aktivieren.

Signieren von Erweiterungen schlägt fehl: Jedes Extension-Target benötigt eine eigene App ID und ein eigenes Profil. Prüfe jedes Target unter Signing & Capabilities, nicht nur die App.

„Invalid password“ beim Importieren einer auf Linux erstellten .p12-Datei: Erstelle sie neu mit openssl pkcs12 -export ... -legacy.

Upload für Version SDK abgelehnt: Seit April 2026 verlangt App Store Connect Builds mit Xcode 26 und dem iOS 26 SDK. Update Xcode oder dein CI-Image. Capacitor 8 setzt bereits Xcode 26 voraus.

Best Practices für Teams

• Ein Apple Distribution Certificate pro Team, gespeichert als .p12 in einem Password Manager oder Secrets Store, wobei das Passwort separat gespeichert wird.
• Verschicke niemals .p12 Dateien per E-Mail oder committe sie in Git.
• Nutze App Store Connect API Keys (.p8) für Uploads statt Apple ID Passwörtern.
• Benenne Provisioning Profiles nach Bundle ID, Typ und Jahr.
• Widerrufe die Zertifikate von Teammitgliedern, die das Team verlassen.
• Führe eine Liste aller Bundle IDs, Extensions und Capabilities der App.

Cloud-Signing für Capacitor-Apps

Um iOS-Builds zu veröffentlichen, muss nicht jeder Entwickler einen Mac auf dem Schreibtisch haben. Capgo Build erstellt Capacitor-Apps auf den macOS-Maschinen von Capgo mit einem .p12 und dem von dir bereitgestellten Profil. Die Credentials werden nur für den Build verwendet und nicht auf Capgo-Servern gespeichert. Einmalig in CLI hinterlegen:

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 .

Der Capgo Build iOS Docs listen die genauen Credential-Optionen auf, inklusive App Store Connect API Keys für den TestFlight-Upload und ad_hoc Modus für Tester-Builds.

Sobald dein erster Build in TestFlight ist, kannst du JavaScript- und Asset-Änderungen an Nutzer ausliefern, Capgo Live Updates ohne für jeden Fix eine neue Binary signieren zu müssen. Native code-Änderungen und neue Capabilities erfordern weiterhin einen signierten Build über den Store.

Nächste Schritte

• Brauchen Sie zuerst Konten? So erstellen Sie Apple- und Google Play-Entwicklerkonten.
• Bereit, Builds an Tester zu übergeben? iOS- und Android-Apps an Tester verteilen.
• Einreichen? Lesen Sie unseren iOS-App-Einreichungsführer.