iOS-Entwicklerzertifikate migrieren: Mac-Checkliste

📋 Inhaltsverzeichnis

Importiertes Zertifikat, aber Xcode meldet „privater Schlüssel fehlt“?
Schnellste Lösung: Übertragen Sie die vollständige Signaturidentität mit privatem Schlüssel oder erstellen Sie auf dem neuen Mac eine neue Identität. Prüfen Sie danach Provisioning Profile, App ID, Capabilities und den echten App-Store-Upload, bevor Sie den alten Mac abschalten.

Diese Anleitung ist für Sie gedacht, wenn Sie eine iOS-Build-Umgebung auf einen neuen oder entfernten Mac verschieben. Sie hilft unabhängigen Entwicklern beim kontrollierten Umzug und kleinen Teams beim Aufbau einer wiederholbaren Übergabe. Wenn der alte Mac beschädigt ist, erfahren Sie außerdem, welche Assets neu erstellt werden können und welche Zugangsschlüssel separat behandelt werden müssen.

Der kritische Unterschied: Zertifikat gegen Signaturidentität

Beim iOS-Entwicklerzertifikate migrieren ist der häufigste Fehler eine unvollständige Sicherung. Ein Zertifikat enthält den öffentlichen Teil der Identität. Zum Signieren benötigt Xcode zusätzlich den passenden privaten Schlüssel. Erst beide Komponenten bilden die verwendbare Signaturidentität. Apple erklärt diesen Zusammenhang in der technischen Übersicht zu Code-Signing-Zertifikaten.

Das erklärt die typische Fehlermeldung nach einem Mac-Wechsel:

Die Datei Apple Distribution.cer wurde auf den neuen Mac kopiert.
Xcode erkennt das Zertifikat oder das Entwicklerteam.
In Keychain Access fehlt aber der zugehörige private Schlüssel.
Das Projekt kann möglicherweise kompilieren, doch Archive oder Export scheitern bei der Signatur.

Prüfen Sie auf dem alten Mac in Keychain Access unter „Meine Zertifikate“, ob das Zertifikat aufklappbar ist und darunter ein privater Schlüssel erscheint. Eine reine Ansicht unter „Zertifikate“ genügt nicht. Für den Export sollten Sie eine verschlüsselte Entwicklerkontosicherung oder ein passwortgeschütztes PKCS#12-Format verwenden. Die dafür vorgesehenen Xcode-Funktionen beschreibt die Apple-Dokumentation zur Übertragung von Entwicklerkonten.

Achtung: Eine .cer-Datei, ein .mobileprovision-File und ein App Store Connect API Key sind unterschiedliche Assets. Sie ersetzen einander nicht und sollten nicht ohne Zugriffstrennung in derselben ungeschützten Ablage liegen.

Für die Migration sollten Sie mindestens diese Bestandteile erfassen:

Team ID und zugeordnetes Entwicklerteam
Bundle ID jedes Targets
App ID und aktivierte Capabilities
Entwicklungs- und Distributionszertifikate
passende private Schlüssel
Provisioning Profile für App, Extensions und zusätzliche Targets
Xcode-Projekt- und Build-Konfigurationen
App Store Connect API Keys oder Upload-Zugang
APNs-Schlüssel, falls Push-Benachrichtigungen verwendet werden
Build-Benutzer und Keychain-Einstellungen

Damit vermeiden Sie einen zweiten typischen Fehler: Der Haupt-Target funktioniert, aber ein Widget, eine Share Extension oder eine Notification Extension scheitert, weil sie eine eigene Bundle ID, ein eigenes Profile oder abweichende Entitlements besitzt.

Vor dem Umzug: Signaturmodell und Abnahmekriterium festlegen

Bevor Sie Dateien kopieren, bestimmen Sie, wie das Projekt signiert wird. Automatische Xcode-Signatur, manuelle Signatur und eine CI/CD-Pipeline haben unterschiedliche Abhängigkeiten.

Bei automatischer Signatur verwaltet Xcode viele Entwicklungs- und Distributionsressourcen über das angemeldete Entwicklerkonto. Das bedeutet jedoch nicht, dass der private Schlüssel beliebig neu erzeugt werden darf. Die lokal gespeicherten Schlüssel bleiben für die vorhandene Identität relevant. Exportieren Sie Entwicklerkonten und lokale Signing Assets daher vor jeder Änderung an der alten Umgebung.

Bei manueller Signatur müssen Sie für jede Build-Konfiguration nachvollziehen können, welches Zertifikat und welches Provisioning Profile verwendet werden. Prüfen Sie insbesondere:

CODE_SIGN_STYLE
DEVELOPMENT_TEAM
PRODUCT_BUNDLE_IDENTIFIER
CODE_SIGN_IDENTITY
PROVISIONING_PROFILE_SPECIFIER
Entitlements-Dateien
Einstellungen für App Extensions und weitere Targets

Als endgültiges Abnahmekriterium gilt nicht „Xcode zeigt keinen roten Hinweis“. Der neue Mac ist erst dann produktionsfähig, wenn das echte Projekt ein Release-Archive erstellt, die Signaturprüfung besteht, ein exportierbares Artefakt erzeugt und von App Store Connect angenommen wird. Apple behandelt Upload und Verarbeitung als getrennte Schritte. Die offiziellen Voraussetzungen und Statusinformationen finden Sie in der Anleitung zum Hochladen von Builds in App Store Connect.

Wenn Sie die Zielumgebung noch auswählen, können Sie die Auswahl eines entfernten Mac-Rechenknotens als ergänzende Orientierung verwenden. Für die Signaturmigration bleiben Projektkonfiguration, Schlüsselverwaltung und die wiederholbare Abnahme jedoch wichtiger als die reine Hardwareauswahl.

Schritt 1: Auf dem alten Mac sicher exportieren

Wenn der alte Mac noch verfügbar ist, führen Sie die Sicherung vor jeder Änderung an Zertifikaten oder Profiles durch.

Entwicklerkonten mit Xcode sichern

Öffnen Sie in Xcode die Account-Einstellungen und verwenden Sie die Funktion zum Exportieren der Entwicklerkonten. Vergeben Sie ein starkes, nicht wiederverwendetes Passwort. Xcode speichert die Sicherung verschlüsselt und nimmt die lokalen Signing Assets mit, einschließlich der privaten Schlüssel, die im Schlüsselbund liegen. Apple beschreibt diesen Ablauf in der Xcode-Hilfe für Entwicklerkonten und Signing Assets.

Beim Import auf dem Ziel-Mac benötigen Sie genau dieses Passwort. Bewahren Sie die Exportdatei nicht dauerhaft im Projektverzeichnis auf. Für ein kleines Team ist eine verschlüsselte Ablage mit begrenztem Zugriff sinnvoller als ein gemeinsamer Ordner, aus dem jeder Projektmitarbeiter die Datei herunterladen kann.

Protokollieren Sie:

wer Zugriff erhalten darf
wann die Sicherung erstellt wurde
welche Targets enthalten sind
wo die Sicherung verschlüsselt liegt
wann die Datei nach erfolgreicher Migration gelöscht oder neu verschlüsselt wird

Keychain Access zusätzlich kontrollieren

Öffnen Sie Keychain Access und suchen Sie nach den relevanten Einträgen. Kontrollieren Sie:

Zertifikatsname und Team-Zuordnung
Vorhandensein des privaten Schlüssels
Ablaufdatum
verwendeten Schlüsselbund
Zugriffsberechtigungen der Signaturtools

Wenn Sie eine einzelne Identität exportieren müssen, wählen Sie das Zertifikat zusammen mit dem privaten Schlüssel und exportieren Sie es in ein geschütztes PKCS#12-Format. Das Exportpasswort darf nicht im Skript, in einer .env-Datei im Repository oder in einer Build-Logzeile stehen. Zertifikat und privater Schlüssel müssen gemeinsam exportiert werden; eine öffentliche .cer-Datei ist für diesen Zweck unvollständig.

Profile und Projektzustand separat sichern

Kopieren Sie die verwendeten Provisioning Profiles zusätzlich in eine klar benannte Sicherung. Ein Profile verknüpft Signaturberechtigung, App ID, Ziel und Entitlements. Apple erklärt diese Zusammenhänge in der technischen Übersicht zu Provisioning Profiles.

Sichern Sie außerdem:

das Projekt inklusive .entitlements-Dateien
Export-Optionen für Archive
verwendete Build-Skripte
Fastlane- oder CI/CD-Konfigurationen, falls vorhanden
Dokumentation der Bundle IDs und Capabilities
getrennte Upload-Anmeldedaten

Behandeln Sie einen App Store Connect API Key nicht wie ein Apple-Distribution-Zertifikat. Solche privaten Schlüssel dienen der API-Authentifizierung und müssen separat verwaltet werden. Apple weist darauf hin, dass ein privater API-Schlüssel nach seiner Erstellung nicht einfach erneut aus dem Account heruntergeladen werden kann. Die entsprechende Vorgehensweise beschreibt die Apple-Hilfe zu privaten API-Schlüsseln.

Schritt 2: Wenn der alte Mac defekt ist

Ist der alte Mac nicht mehr erreichbar, teilen Sie die Assets in drei Gruppen auf.

Neu erstellbar

Je nach Teamrolle und Berechtigung können Sie neue Entwicklungs- oder Distributionszertifikate erzeugen. Ein neuer Zertifikatsantrag erzeugt eine neue Schlüsselbeziehung; die alte private Schlüsseldatei wird dadurch nicht wiederhergestellt. Ohne den ursprünglichen privaten Schlüssel können Sie die alte Signaturidentität nicht aus dem öffentlichen Zertifikat rekonstruieren.

Prüfen Sie vor der Erstellung die Rollen Ihres Entwicklerkontos. Apple beschreibt die verfügbaren Zertifikatstypen, Zuständigkeiten und Verwaltungsoptionen in der Übersicht zu Certificates, Identifiers & Profiles.

Neu zu generieren

Provisioning Profiles können Sie neu erzeugen, wenn App ID, Capabilities und das neue Zertifikat feststehen. Ein App-Store-Profil muss zur verwendeten App ID und zum ausgewählten Distributionszertifikat passen. Wenn Sie eine Capability ändern oder ein Zertifikat ersetzen, ist die Neugenerierung meistens der sauberere Weg.

Ob ein Profile allein wegen des Mac-Wechsels ersetzt werden muss, hängt deshalb nicht vom Rechner ab. Entscheidend ist, ob sich Zertifikat, App ID, Entitlements, Plattform oder Gültigkeit geändert haben. Für die Erstellung eines neuen App-Store-Profils können Sie die offizielle Anleitung für Provisioning Profiles heranziehen.

Zu rotieren oder separat zu prüfen

APNs-Schlüssel, App Store Connect API Keys und andere Dienstschlüssel sind keine Bestandteile der Code-Signaturidentität. Prüfen Sie deren Verbleib separat. Wenn ein Schlüssel möglicherweise auf einem nicht mehr kontrollierten Mac gespeichert war, sollten Sie die Rotation nach Ihren Teamrichtlinien vorbereiten, statt nur ein neues Zertifikat auszustellen.

Erfahrungsregel: Widerrufen Sie ein altes Zertifikat nicht reflexartig. Ein Widerruf kann die damit verbundenen Provisioning Profiles unbrauchbar machen. Erst wenn das neue Zertifikat und ein erfolgreich getestetes Profile vorhanden sind, sollte der Widerruf als kontrollierte Maßnahme erfolgen. Die möglichen Auswirkungen beschreibt Apple in der Dokumentation zur Verwaltung von Provisioning Profiles.

Entscheidungswerkzeug: Migrations-Checkliste zum Abhaken

Arbeiten Sie diese Liste in der angegebenen Reihenfolge ab. Setzen Sie ein Häkchen erst dann, wenn der jeweilige Nachweis auf dem neuen Mac vorliegt.

Vor dem Kopieren

[ ] Team ID, Bundle ID und alle Targets dokumentiert
[ ] Automatische oder manuelle Signatur eindeutig festgelegt
[ ] Apple Distribution und weitere Zertifikatstypen erfasst
[ ] Zu jedem benötigten Zertifikat der private Schlüssel in Keychain Access sichtbar
[ ] Provisioning Profiles für App und Extensions gesichert
[ ] App Store Connect API Keys und APNs-Schlüssel separat inventarisiert
[ ] Alter Mac bleibt bis zur erfolgreichen Abnahme verfügbar

Nach dem Import

[ ] Zertifikat und privater Schlüssel erscheinen gemeinsam in Keychain Access
[ ] Neues Xcode-Projekt verwendet die richtige Team ID
[ ] Bundle IDs und Capabilities stimmen mit der App ID überein
[ ] Provisioning Profiles wurden installiert und dem richtigen Target zugeordnet
[ ] Build-Benutzer kann auf den vorgesehenen Schlüsselbund zugreifen
[ ] Keine privaten Schlüssel, Passwörter oder API-Secrets liegen im Repository
[ ] Entitlements wurden für Haupt-App und Extensions geprüft

Vor dem Abschalten des alten Macs

[ ] Echtes Release-Archive wurde erfolgreich erstellt
[ ] Signatur, Team ID, Bundle ID und Profile wurden geprüft
[ ] Export für den geplanten Vertrieb war erfolgreich
[ ] Build wurde zu App Store Connect hochgeladen
[ ] Verarbeitung in App Store Connect wurde abgeschlossen
[ ] Ein zweiter Build nach Neustart oder als unbeaufsichtigter Prozess war erfolgreich
[ ] Wiederherstellungsdokumentation ist für mindestens eine weitere berechtigte Person verfügbar

Entscheidungsregel: Fehlt ein Häkchen in „Nach dem Import“, bleibt die Migration im gelben Bereich. Fehlt ein Häkchen in „Vor dem Abschalten“, bleibt der alte Mac produktiv. Erst wenn alle drei Blöcke vollständig sind, wechseln Sie auf den neuen Build-Mac.

Schritt 3: Auf dem neuen oder entfernten Mac wiederherstellen

Installieren Sie zunächst die zum Projekt passende Xcode-Version und melden Sie das richtige Entwicklerkonto an. Prüfen Sie danach in Xcode den Team-Eintrag jedes Targets. Ein angemeldetes Konto allein beweist noch nicht, dass der benötigte private Schlüssel importiert wurde.

Wiederherstellung in dieser Reihenfolge

Importieren Sie die verschlüsselte .developerprofile-Sicherung oder die geschützte PKCS#12-Datei.
Öffnen Sie Keychain Access und bestätigen Sie, dass Zertifikat und privater Schlüssel gemeinsam erscheinen.
Installieren Sie die benötigten Provisioning Profiles.
Öffnen Sie das Projekt und prüfen Sie Team ID sowie Bundle ID.
Kontrollieren Sie Signing & Capabilities für jedes Target.
Vergleichen Sie die Entitlements mit dem erwarteten App-Store-Zustand.
Prüfen Sie, ob Xcode das gewünschte Zertifikat tatsächlich auswählt.

Capabilities sind besonders wichtig. Dienste wie iCloud, App Groups, Sign in with Apple, Push Notifications oder In-App Purchase verändern die Entitlements und können eine neue Profilgenerierung verlangen. Prüfen Sie deshalb nicht nur das Hauptziel, sondern auch jede Erweiterung. Eine Übersicht zu aktivierbaren App-ID-Funktionen finden Sie in Apples Dokumentation zu Capabilities.

Für einen entfernten Mac kommt eine zusätzliche Ebene hinzu: Der Build-Benutzer muss Zugriff auf den korrekten Schlüsselbund haben. Ein interaktiver Xcode-Test kann erfolgreich sein, während ein geplanter Prozess nach einem Neustart scheitert, weil der Schlüsselbund gesperrt bleibt oder eine Zugriffserlaubnis nicht bestätigt werden kann.

Konfigurieren Sie keine dauerhafte Automatisierung, indem Sie den privaten Schlüssel ungeschützt ablegen. Der richtige Weg ist, Build-Benutzer, Schlüsselbund-Sperrung, Importrechte und Neustartablauf zu dokumentieren und anschließend mit einem kontrollierten Test zu verifizieren. Für eine datenschutzbewusste Übergabe sollten Sie Zugriffsrechte nach dem Prinzip der geringsten Berechtigung vergeben und unnötige Fernzugänge entfernen.

Der Abgleich für Apple Distribution und Provisioning Profile

Bei der manuellen Prüfung muss die Kette von oben nach unten passen:

Apple Distribution: Das Zertifikat muss zur importierten privaten Schlüsselkomponente gehören.
Provisioning Profile: Das Profile muss die passende App ID und das passende Zertifikat enthalten.
Bundle ID: Der Wert im Projekt muss mit der registrierten App ID übereinstimmen.
Capabilities: Die Entitlements im Projekt dürfen nicht über die autorisierten Profile hinausgehen.
Team ID: Alle Targets müssen dem erwarteten Entwicklerteam zugeordnet sein.
Version und Build-Nummer: Der Upload muss dem korrekten App-Store-Datensatz zugeordnet werden.

Ein Provisioning Profile ist daher kein bloßes Konfigurationsfile. Es autorisiert eine konkrete Kombination aus Team, App ID, Signatur und Entitlements. Wenn eine dieser Beziehungen nicht passt, kann Xcode trotz installierter Dateien nicht zuverlässig signieren.

Schritt 4: Archive, Export und Upload getrennt abnehmen

Führen Sie die Prüfung in vier Ebenen durch. Vermischen Sie diese Ergebnisse nicht:

Compile: Der Quellcode wird erfolgreich gebaut.
Archive: Xcode erstellt ein Release-Archive mit der vorgesehenen Konfiguration.
Export und Signaturprüfung: Das Archive lässt sich für den geplanten Vertrieb exportieren und die enthaltenen Signaturen entsprechen der Erwartung.
Upload und Verarbeitung: App Store Connect nimmt den Build an und verarbeitet ihn erfolgreich.

Starten Sie mit einem Clean Build des echten Projekts. Verwenden Sie keine vereinfachte Demo-App, denn Extensions, App Groups und zusätzliche Entitlements werden sonst nicht geprüft. Kontrollieren Sie im Archive die Signaturdetails, das verwendete Profile, Team ID und Bundle ID.

Bei Bedarf können Sie mit macOS-Werkzeugen wie codesign und security prüfen. Sensible Werte müssen in jeder Dokumentation und jedem Log vollständig maskiert werden. Logdateien sollten dennoch genügend Kontext enthalten, um fehlende private Schlüssel, Profile-Mismatch, falsche Team IDs und Berechtigungsfehler zu unterscheiden.

Für den Upload müssen Sie außerdem die Berechtigungen des verwendeten Kontos prüfen. Der Build ist erst wirklich angenommen, wenn App Store Connect ihn verarbeitet hat und der Status nicht bei „Processing“ oder „Failed“ stehen bleibt. Eine lokale IPA-Datei ist nur ein Zwischenprodukt.

FAQ für die Übergabe an einen neuen Build-Mac

Wie übertrage ich meine iOS-Signatur auf einen anderen Mac?

Sichern Sie nicht nur die Zertifikatsdatei, sondern die vollständige Signaturidentität einschließlich passendem privaten Schlüssel. Xcode kann Entwicklerkonten verschlüsselt exportieren; alternativ verwenden Sie in Keychain Access ein geschütztes PKCS#12-Exportformat. Danach importieren Sie die Identität, Profile und Projektkonfiguration auf dem Ziel-Mac und prüfen ein echtes Release-Archive.

Warum meldet Xcode trotz importiertem Zertifikat einen fehlenden privaten Schlüssel?

Eine .cer-Datei enthält nur das öffentliche Zertifikat. Xcode kann damit nicht signieren, solange der zugehörige private Schlüssel fehlt oder nicht im verwendeten Schlüsselbund liegt. Öffnen Sie Keychain Access, prüfen Sie unter „Meine Zertifikate“, ob Zertifikat und Schlüssel gemeinsam erscheinen, und importieren Sie bei Bedarf die vollständige .p12- oder .developerprofile-Sicherung.

Was bleibt möglich, wenn der alte Mac nicht mehr startet?

Ohne Zugriff auf den privaten Schlüssel lässt sich eine bestehende Signaturidentität nicht aus dem öffentlichen Zertifikat zurückgewinnen. Sie müssen eine neue, berechtigte Signaturidentität erstellen und die betroffenen Provisioning Profiles aktualisieren. App Store Connect API Keys und APNs-Schlüssel werden separat behandelt und müssen bei Verlust oder möglicher Offenlegung ebenfalls geprüft beziehungsweise rotiert werden.

Muss ich nach dem Wechsel des Macs ein Provisioning Profile neu erstellen?

Nicht automatisch. Ein unverändertes Profile kann weiter funktionieren, wenn App ID, Capabilities, Zertifikat und Zielplattform weiterhin passen. Nach einem neuen Zertifikat, geänderten Capabilities oder abgelaufenen Profilen ist jedoch eine Neugenerierung erforderlich. Entscheidend ist nicht der Mac-Wechsel selbst, sondern ob sich die darin autorisierte Signatur- und Entitlement-Kette geändert hat.

Wie beweise ich, dass der neue Build-Mac veröffentlichen kann?

Führen Sie mit dem echten Projekt ein sauberes Release-Archive aus, prüfen Sie Signatur, Team ID, Bundle ID, Provisioning Profile und Entitlements und exportieren Sie anschließend die geplante Distribution. Danach laden Sie den Build zu App Store Connect hoch und warten auf den Status „Complete“. Ein erfolgreich erzeugtes IPA allein reicht als Nachweis nicht aus.

Schritt 5: Alten Mac erst nach der Wiederholungsprüfung abschalten

Nach dem ersten erfolgreichen Upload sollte der Umzug noch nicht sofort beendet werden. Starten Sie den neuen Mac oder die entfernte Umgebung neu und führen Sie mindestens einen weiteren unbeaufsichtigten Build aus. Damit prüfen Sie, ob der Build-Benutzer nach einem Neustart auf den Schlüsselbund, die Profile, Abhängigkeiten und Upload-Anmeldedaten zugreifen kann.

Dokumentieren Sie dabei nur notwendige Informationen:

Zeitpunkt und Build-Nummer
verwendete Xcode-Konfiguration
Ergebnis von Archive und Export
App-Store-Verarbeitungsstatus
anonymisierte Fehlermeldungen
Name der verwendeten, nicht aber der geheimen Schlüsselreferenz
verantwortliche Person und Wiederherstellungsweg

Entfernen Sie private Schlüssel, API-Dateien und temporäre Archive vom alten Mac erst, wenn der neue Prozess wiederholbar funktioniert. Bei einem entfernten Mac gehören außerdem Zugriffskontrolle, Löschfristen und die Frage in die Dokumentation, wer den Host administrieren darf.

Die technische Migration ist erfolgreich, wenn Sie die Signaturkette nachvollziehen können, nicht wenn möglichst viele Dateien kopiert wurden. Halten Sie die alte Umgebung so lange bereit, bis mindestens ein realer Veröffentlichungsdurchlauf und ein Wiederholungstest nach dem Neustart erfolgreich waren.

Aktuelle Umgebung gegen MacDate: Wann ein gemieteter Mac sinnvoll ist

Ein dauerhaft selbst verwalteter Mac hat drei reale Nachteile: Sie müssen Hardware, Speicherzustand und Stromversorgung selbst überwachen; ein defekter Rechner blockiert den Build; und die Signatur- und Zugangsdokumentation bleibt häufig an eine einzelne Person gebunden. Bei einem entfernten Mac kommen zusätzlich Netzwerkzugriff, Benutzerrechte und der Schutz des Schlüsselbunds hinzu.

Wenn Ihr alter Mac ausfällt oder nur für eine Übergangsphase benötigt wird, kann ein kurzfristig gemieteter Mac von MacDate die risikoärmere Zwischenlösung sein. Sie können die Migration, ein echtes Archive und den App-Store-Upload zunächst wiederholbar testen und erst danach entscheiden, ob die Umgebung als dauerhafte Build-Maschine bestehen bleibt.

Für langfristig hohe Dauerlast oder spezielle physische Schnittstellen kann ein eigener Mac weiterhin sinnvoller sein. Für einen zeitlich begrenzten Umzug zählt dagegen vor allem, dass Sie die Signaturkette kontrolliert übernehmen und den alten Rechner erst nach einer belastbaren Abnahme aus dem Prozess entfernen. Prüfen Sie vorab auch die Unterschiede zwischen Bare-Metal- und virtualisierten macOS-Umgebungen, wenn Stabilität, Zugriffskontrolle oder reproduzierbare Builds zu Ihren wichtigsten Kriterien gehören.