iOS-Zertifikate und Bereitstellungsprofile erklärt

iOS code Signierung verwendet zwei Teile. Ein Zertifikat beweist, wer das App erstellt hat, und ein Zertifikatsprofil besagt, welches App es ist, welche Geräte es ausführen dürfen und welche Funktionen es nutzen kann. Xcode lehnt die Erstellung für ein Gerät ab und App Store Connect lehnt Uploads ab, es sei denn, das Zertifikat, seine private Schlüssel und ein passendes Profil passen alle zusammen.

Diese Anleitung erklärt jeden Teil, welche Combination Sie für die Entwicklung, Ad-hoc, TestFlight, App Store und Unternehmensbuilds benötigen, wie Sie sie mit oder ohne Mac erstellen und wie Sie die Fehler beheben, die Sie treffen werden.

Warum Apple eine code-Signierung erfordert

Apple lässt nur iPhones code laufen, die Apple zurückverfolgen kann auf einen bekannten Entwickler. Die Signierung gibt Apple drei Gewährleistungen:

1. IdentitätDie binäre Datei wurde von einem Mitglied eines bestimmten Apple-Entwickler-Teams signiert.
2. IntegritätKein Byte wurde nach dem Signieren geändert. Ein einzelner Byte-Wechsel bricht das Signatur.
3. AutorisierungDie App ist auf diesem Gerät mit diesen Berechtigungen (Push, iCloud, Anmeldung mit Apple, App-Gruppen usw.) erlaubt.

Zertifikate liefern die ersten beiden. Zertifikatsprofile liefern die dritte.

Die Grundbausteine

Die häufigste Verwechslung: ein .cer Datei ist auf sich selbst nicht verwertbar. Die Signierung benötigt den privaten Schlüssel, der das CSR erstellt hat. Wenn Sie diesen Schlüssel verlieren, erstellen Sie ein neues Zertifikat.

Zertifikatstypen

Apple-Entwicklung

Für die Ausführung von Builds auf eigenen Geräten aus Xcode während der Entwicklung. Entwicklungszertifikate gehören einem einzelnen Entwickler und werden von Apple mit dem Computer-Namen gekennzeichnet. Jeder Entwickler auf dem Team kann sein eigenes haben.

Apple-Verteilung

zur Signierung von Builds für Ad Hoc-Verteilung, TestFlight und den App Store verwendet. Verteilungszertifikate gehören zum Team und können nur vom Account-Halter oder Admin-Rollen erstellt werden. Apple beschränkt die Anzahl der Zertifikate, die ein Team halten kann, daher sollten Sie eines über einen sicheren Speicher teilen, anstatt jedem Entwickler ein eigenes zu erstellen.

Sie sehen möglicherweise immer noch iOS-Entwicklung und iOS-Verteilung im älteren Konten. Das sind die vor-Xcode-11-Typen. Apple-Entwicklung und Apple-Verteilung ersetzen sie und funktionieren auf iOS, iPadOS, macOS, tvOS, watchOS und visionOS.

andere Zertifikatstypen, die Sie treffen können

• Entwickler-ID-Anwendung/Installer: für Mac-Apps, die außerhalb des Mac App Store verteilt werden. Nicht für iOS verwendet.
• Apple Push Notification-Dienst SSL-Zertifikat: veraltete Push-Zertifikate. Vorzuziehen ist ein APNs-Auth-Schlüssel (.p8), das nicht jährlich abläuft und für jede App im Team funktioniert. Sehen Sie sich unsere Apple Pay-Merchant-Identität.
• Apple Pay Händleridentität, Website-Push-Id, : spezifische Dienste.Zertifikatstypen

Zertifikatsprofile-Typen

Eine Profile ist mit Einem App ID. Wenn Ihre App Erweiterungen (ein Widget, eine Benachrichtigungs-Service-Erweiterung, eine Teilen-Erweiterung) hat, benötigt jede Zielgruppe ihren eigenen Bundle-Id und benötigt seinen eigenen Profil.

Wie die Teile zusammenpassen

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

1. Die Bundle-ID in Ihrem Ziel (z.B. com.example.app) entspricht der App-ID im Profil.
2. Das zum Signieren verwendete Zertifikat ist eines der im Profil aufgeführten Zertifikate.
3. Die private Schlüssel für dieses Zertifikat sind im Schlüsselkasten verfügbar.
4. Für Entwicklung und Ad-hoc-Builds ist die Geräte-UDID im Profil enthalten.
5. Das Entitlements-File (push, assoziierte Domains, App-Gruppen) ist ein Teil dessen, was der App-ID und das Profil zulassen.

Wenn eine Überprüfung fehlschlägt, erhältst du einen Signierungsfehler, nicht eine Laufzeitfehler, was gut ist: Du erfährst es, bevor du es verschickst.

Welche Combination benötige ich?

TestFlight verwendet same signing as the App Store. There is no separate TestFlight profile. You upload one build and decide in App Store Connect whether it goes to testers, to review, or both.

Erstellung von Zertifikaten und Profilen

Zertifikate und Profile erstellen

Option 1: Lassen Sie Xcode das Zertifikat verwalten ios/App/App.xcworkspace (oder die) .xcodeproj wenn Ihr Capacitor 8-Projekt den Swift Package Manager verwendet) wählen Sie App Ziel, geöffnet Signierung & Fähigkeiten, geprüft Automatisch die Signierung verwalten und wählen Sie Ihr Team. Xcode erstellt das Entwicklerzertifikat, registriert das verbundene Gerät und generiert Profile für Sie.

Automatische Signierung wird bei CI schmerzhaft, weil der Build-Maschine Zugriff auf das Team-Konto und Zertifikate auf eigene Faust benötigt. Die meisten Teams wechseln zu manueller Signierung oder zu einem Build-Dienst mit API-Schlüssel-basierten Signierungen für Release-Builds.

Option 2: Erstellen Sie sie manuell auf einem Mac

1. Öffnen Zertifikats-Assistent > Zertifikat von einer Zertifizierungsstelle anfordernE-Mail-Adresse eingeben, wählen Sie Speichern Sie auf der Festplatte. Dies erstellt die private Schlüssel in Ihrem Schlüsselkasten und ein .certSigningRequest .
2. Gehen Sie in der Apple-Entwickler-Portal zu Zertifikate, Identifikatoren und Profile > Zertifikate > +, wählen Sie Apple Distribution (oder Apple Development) und laden Sie das CSR hoch.
3. Laden Sie das .cer herunter und doppelklicken Sie darauf. Keychain Access pairt es mit der privaten Schlüssel.
4. Um es für CI zu exportieren: In Keychain Access, unter Meine Zertifikate , right-click the certificate, choose ExportierenSpeichern als .p12 mit einem starken Passwort.

Option 3: Ohne einen Mac erstellen

Sie können den gesamten Workflow mit OpenSSL auf Linux oder Windows durchführen:

# 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 flag matters mit OpenSSL 3: ohne es, der .p12 verwendet Verschlüsselungsalgorithmen, die von den macOS-Schlüsselkette-Tools mit einem "falsches Passwort"-Fehler abgelehnt werden, selbst wenn das Passwort korrekt ist.

Wenn Sie OpenSSL nicht installieren möchten, können Sie iOS-Zertifikatsgenerator erstellt den CSR und die private Schlüssel für Sie. Sie stammen aus einem stateless Capgo-Endpunkt, der sie nicht speichert und nur seinen .cer to .p12 Der Converter läuft vollständig in Ihrem Browser. Wenn Ihre Richtlinie die Erzeugung der Schlüssel auf Ihrem Computer erfordert, verwenden Sie die OpenSSL-Befehle oben.

Erstellung des Profils

1. Identifikatoren > +: Registrieren Sie ein App-ID mit Ihrem genauen Bundle-Id und aktivieren Sie die verwendeten Funktionen (Push-Benachrichtigungen, Anmeldung mit Apple, verbundene Domains…).
2. Geräte > +: Für Entwicklung- und Ad-hoc-Profilen registrieren Sie die UDID jedes Testers. Testern können sie auf dem Telefon selbst mit dem iOS-UDID-Finder, kein Mac oder Kabel erforderlich.
3. Profile > +: Wählen Sie das Profiltyp, das App-ID, die Zertifikate und die Geräte aus. Benennen Sie es klar, zum Beispiel com.example.app AppStore 2026.
4. Holen Sie sich das .mobileprovision file.

Wenn Sie ein Gerät oder eine Funktion später hinzufügen, müssen Sie das Profil neu generieren und neu herunterladen. Bestehende Profile aktualisieren sich nicht selbst.

Ein Profil betrachten

Ein .mobileprovision Ein Datei ist eine signierte plist. Auf macOS können Sie sie 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

Auf Linux, openssl smime -inform der -verify -noverify -in App_Store.mobileprovision druckt die plist.

Um zu überprüfen, was ein gebautes .ipa mit einem Zertifikat signiert wurde:

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

Ablaufdatum und Wiederherstellung

• Zertifikate sind für ein Jahr von der Erstellung gültig.
• Zertifizierungsprofile gelten ein Jahr, oder früher, wenn das in ihnen enthaltene Zertifikat abläuft oder widerrufen wird.
• App Store-Anwendungen funktionieren weiterhin nach dem Ablauf des Verteilungszertifikats. Apple unterzeichnet App Store-Downloads erneut. Sie benötigen nur ein neues Zertifikat, um neue Builds hochzuladen.
• Ad Hoc- und Entwicklungsbauten stoppen mit der Ausführung sobald ihr Profil abläuft. Tester sehen den App-Startcrash.
• TestFlight-Bauten gelten 90 Tage nach dem Hochladen, unabhängig vom Zertifikat.
• Unternehmensanwendungen funktionieren nicht mehr auf jedem Gerät, wenn das Unternehmenszertifikat abläuft oder widerrufen wird. Erneuern Sie vor Ablauf.
• Geräteslots werden einmal pro Mitgliedschaftsjahr zurückgesetzt. Das Entfernen eines Geräts befreit seinen Slot nicht, bis das nächste Mitgliedschaftsjahr beginnt.

Setzen Sie die Zertifikatsablaufdatum in einem gemeinsamen Kalender. Unser Zertifikatsverwaltungshandbuch beschäftigt sich mit der Überwachung und Rotation in mehr Details.

Häufige Fehler und Lösungen

„Kein Signierzertifikat ‚iOS Distribution‘ gefunden“ oder „Das Signierzertifikat ist ungültig“: the private key is not in this keychain. Import the .p12, oder erstellen Sie ein neues Zertifikat, wenn niemand den Schlüssel hat.

„Das Provisionierungsprofil enthält kein Signierzertifikat“Das Profil wurde mit einem anderen Zertifikat erstellt. Bearbeite das Profil im Portal, markiere das aktuelle Zertifikat, regenereiere es und laden Sie es herunter.

„Das Provisionierungsprofil enthält nicht das derzeit ausgewählte Gerät“: Registrieren Sie die UDID, dann regenerieren Sie das Profil. Nicht erforderlich für TestFlight oder App Store.

“Provisioning-Profil unterstützt die Push-Nachrichten-Fähigkeit nicht”: Aktivieren Sie die Fähigkeit auf dem App-ID, dann regenerieren Sie das Profil. Profil sind Snapshots.

“Ein gültiges Provisioning-Profil für diesen Ausführbaren wurde nicht gefunden” auf Installieren: Das Gerät ist nicht im ad-hoc-Profil oder das Profil ist abgelaufen.

App-Installation schließt sich sofort: auf iOS 16 und später benötigen Entwicklung und ad-hoc-Builds den Entwicklermodus auf dem Gerät. Siehe wie Entwicklermodus auf iOS zu aktivieren.

Erweiterungen scheitern beim Signieren: Jeder Erweiterungszielbedarf benötigt seinen eigenen App-ID und Profil. Überprüfen Sie alle Ziele in Signing & Capabilities, nicht nur das App.

“Ungültiger Passwort” beim Importieren eines .p12 erstellt auf Linux: Erstellen Sie es neu mit openssl pkcs12 -export ... -legacy.

Hochladen abgelehnt für SDK Version: seit April 2026 erfordert App Store Connect Builds, die mit Xcode 26 und iOS 26 erstellt wurden, SDK. Aktualisieren Sie Xcode oder Ihr CI-Bild. Capacitor 8 erfordert bereits Xcode 26.

Gute Praktiken für Teams

• Ein Apple-Distributionssiegel pro Team, gespeichert als .p12 in einem Passwort-Manager oder Secrets-Store, mit dem Passwort separat gespeichert.
• Nie .p12 Dateien oder commit sie nicht in Git.
• Verwenden Sie App Store Connect API-Schlüssel (.p8) für Uploads anstatt Apple-ID-Passwörter.
• Benennen Sie Profile mit Bundle-ID, Typ und Jahr.
• Ziehen Sie Zertifikate von Personen, die das Team verlassen.
• Halten Sie eine schriftliche Liste von jedem Bundle-ID, Erweiterung und Fähigkeit, die die App verwendet.

Cloudsigning für Capacitor-Apps

Sie benötigen keinen Mac auf jedem Entwickler-Desk, um iOS-Builds zu liefern. Capgo Build buildt Capacitor Apps auf Capgo's macOS-Maschinen mit einem .p12 und das Profil, das Sie bereitstellen. Die Zugangsdaten werden nur für die Erstellung verwendet und nicht auf Capgo-Servern gespeichert. Speichern Sie sie einmal von 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 .

The Capgo iOS-Dokumentation erstellen listiere die genauen Authentifizierungsoptionen, einschließlich App Store Connect API-Schlüssel für die TestFlight-Uploads ad_hoc Modus für Tester-Builds.

Mit Ihrem ersten Build in TestFlight können Sie JavaScript- und Asset-Änderungen an Benutzer weitergeben Capgo Live-Updates ohne ein neues Binär für jeden Fix neu zu signieren. Native code-Änderungen und neue Funktionen erfordern jedoch immer noch einen signierten Build durch den Store.

Nächste Schritte

• Benötigen Sie Konten erst? Wie erstellen Sie Apple- und Google Play-Entwicklerkonten?.
• Bereit, Builds an Testern zu verteilen? Wie verteilen Sie iOS- und Android-Apps an Testern?.
• Bei der Einreichung? Lesen Sie unseren Leitfaden zur Einreichung von iOS-Apps.