Wie läuft die Rotation von iOS-CI-Zertifikaten im Team ab? Fastlane Match 2026

Apple weist darauf hin, dass ein widerrufenes Zertifikat die damit verbundenen Provisioning Profiles ungültig machen kann (Hinweise zum Widerruf von Zertifikaten). Behandeln Sie die iOS-CI-Zertifikatsrotation deshalb nicht als bloßen Austausch einer Datei: Erfassen Sie zuerst Zertifikate, private Schlüssel, Profile und abhängige Release-Aufgaben, synchronisieren Sie neue Signatur-Assets schrittweise und prüfen Sie Build, Archiv und Signatur auf einem echten Mac-CI-Knoten. Erst nach erfolgreicher Abnahme entscheiden Sie über alte Assets.

Diese Woche sollten Sie zunächst die Asset-Liste und den Verantwortlichen je Produktionsworkflow festhalten.
Für IT-Verantwortliche: Sie legen Freigabe, Zuständigkeit und Rückfallkriterien fest.
Für Plattformingenieure und iOS-Release-Teams: Sie steuern Fastlane Match und weisen nach, dass die neue Signatur im tatsächlichen Build funktioniert.

Vor dem Wechsel: Abhängigkeiten erfassen statt Zertifikate blind austauschen

Eine Rotation beginnt mit der Frage, was ein Produktionsbuild tatsächlich verwendet. Ein Zertifikat allein reicht für eine belastbare Bestandsaufnahme nicht: Der private Schlüssel muss verfügbar sein, das Profil muss zum App-Kennzeichen und zur Signatur passen, und die CI-Umgebung muss die nötigen Geheimnisse und Berechtigungen erhalten.

Führen Sie die Inventur pro App und Release-Pfad durch. Trennen Sie Entwicklungs-, Verteilungs- und gegebenenfalls interne Signaturabläufe. Ein Apple Distribution-Zertifikat ist nicht mit einem Entwicklungszertifikat gleichzusetzen; die verfügbaren Zertifikatstypen und ihre Verwaltung beschreibt Apple in der Zertifikatsübersicht. Erfassen Sie außerdem, welche Aufgaben einen App-Store-Upload, eine interne Verteilung, einen Testbuild oder lediglich einen lokalen Entwicklungsbuild erzeugen.

Prüfen Sie die Einträge gegen Entwicklerkonto, Keychain und CI-Konfiguration. Ein vorhandenes Zertifikatsobjekt beweist nicht, dass der zugehörige private Schlüssel auf dem Build-Knoten nutzbar ist. Ebenso belegt ein gespeichertes Profil nicht, dass es für das aktuelle App-Kennzeichen und den vorgesehenen Release-Weg passt.

Welche Vorbereitungen braucht ein Apple Distribution-Zertifikat vor dem Ablauf?

Legen Sie zuerst fest, welche Builds von der betroffenen Identität abhängen und wer die Änderung genehmigen darf. Prüfen Sie dann den aktuellen Status im Entwicklerkonto, die Verfügbarkeit des privaten Schlüssels und die Profile, die mit der Identität verwendet werden. Planen Sie den Austausch so, dass ein Testbuild mit der neuen Kombination möglich ist, bevor Sie den bisherigen Produktionspfad verändern.

Klären Sie auch, ob das zuständige Konto die erforderlichen Verwaltungsrechte besitzt. Apple unterscheidet Rollen und Berechtigungen im Developer Program; prüfen Sie die konkrete Zuständigkeit anhand der Apple-Rollenbeschreibung. Ein technischer Zugriff auf ein Repository ersetzt keine organisatorische Freigabe, und eine Freigabe allein stellt noch nicht sicher, dass der Schlüssel im CI verfügbar ist.

Halten Sie als Baseline vor dem Wechsel fest:

• Welche Xcode-Version und welche Build-Aufgabe den Produktionsworkflow ausführen.
• Welche Signaturidentität und welches Profil der aktuelle Build verwendet.
• Ob der Build archiviert und den vorgesehenen Verteilungs- oder Veröffentlichungsweg erreicht.
• Welche relevanten Meldungen in Pipeline-Log und Signaturprüfung erscheinen.
• Wie Sie den letzten bekannten funktionierenden Workflow wiederherstellen können.

Xcode kann Signaturmaterial zwischen Teammitgliedern teilen. Verwenden Sie die in Xcode verwalteten Teamidentitäten als Abgleich, nicht als Ersatz für den Nachweis, dass Ihr CI-Knoten die benötigte Identität samt privatem Schlüssel einsetzen kann. Dokumentieren Sie die tatsächlich verwendete Identität im Build und vergleichen Sie sie mit dem freigegebenen Stand.

Vor der Synchronisierung: Neue Assets passend zum Release-Weg erstellen

Erstellen oder aktualisieren Sie Zertifikate und Profile mit dem Verfahren, das Ihr Team tatsächlich verwaltet. Das kann die Arbeit über Xcode, das Apple-Entwicklerkonto oder einen bereits etablierten Fastlane-Match-Prozess einschließen. Legen Sie vorab fest, wer das neue Material erzeugt und wer die Änderung prüft. Wenn Sie ein Profil bearbeiten oder neu erzeugen, prüfen Sie anschließend, ob App-Kennzeichen, Signatur und Verwendungszweck weiterhin zum Workflow passen. Apple beschreibt das Bearbeiten, Herunterladen und erneute Erzeugen von Provisioning Profiles.

Behandeln Sie diese Bestandteile als getrennte Vertrauensobjekte:

• Zertifikat: identifiziert die Signaturidentität.
• Privater Schlüssel: ermöglicht die Signatur mit dieser Identität und benötigt entsprechend begrenzten Zugriff.
• Provisioning Profile: verbindet die für den konkreten Verteilungsweg nötigen Angaben.
• CI Secret: ermöglicht dem Workflow gegebenenfalls, ein verschlüsseltes Repository oder andere geschützte Werte zu verwenden.
• Mac-Host-Berechtigungen: bestimmen, welche Prozesse und Benutzer auf dem Build-Knoten arbeiten können.

Diese Trennung verhindert einen häufigen Fehlschluss: Wer das Match-Repository lesen darf, sollte nicht automatisch auch administrative Rechte auf dem Mac erhalten. Umgekehrt kann ein stark eingeschränkter Hostzugriff ein zu breit vergebenes Repository-Secret nicht ausgleichen. Prüfen Sie für jede Berechtigung, ob sie für den jeweiligen Workflow notwendig ist, und dokumentieren Sie, wer sie ändern oder entziehen darf.

Rufen Sie ein altes Zertifikat nicht vorsorglich als ersten Rotationsschritt zurück. Apple erklärt, dass der Widerruf die mit dem Zertifikat verbundenen Provisioning Profiles ungültig machen kann. Prüfen Sie daher zuerst, welche laufenden oder noch benötigten Arbeitsabläufe davon abhängen, und legen Sie eine genehmigte Maßnahme für den Altbestand fest. Die Apple-Hinweise zum Widerrufen eines Zertifikats sollten Sie bei dieser Entscheidung unmittelbar heranziehen.

Im Pilot: Fastlane Match kontrolliert mit der CI synchronisieren

Testen Sie Fastlane Match zunächst in einer begrenzten Mac-Umgebung mit einem repräsentativen Projekt. Prüfen Sie, ob der gewünschte Zertifikatstyp und das passende Profil synchronisiert werden und ob der Build-Knoten die Signatur ausführen kann. Die Fastlane-Match-Dokumentation beschreibt den Synchronisierungsablauf sowie den Read-only-Modus. Für einen normalen Build sollte die CI vorhandene Assets kontrolliert einlesen, statt beiläufig neue Signaturmaterialien zu erzeugen oder bestehende Daten zu ändern.

Die Read-only-Einstellung ist eine Schutzmaßnahme gegen unerwartete Änderungen aus dem Buildprozess, aber kein Ersatz für eine Zugriffsprüfung. Legen Sie fest, welche freigegebenen Personen Änderungen am Match-Speicher vornehmen dürfen, wie das Verschlüsselungsgeheimnis verwaltet wird und welcher CI-Kontext es abrufen kann. Bei GitHub Actions erläutert die Dokumentation, wie Secrets in Workflows geschützt und verfügbar gemacht werden. Übernehmen Sie die Grundsätze für minimale Berechtigungen und begrenzte Verfügbarkeit auch dann, wenn Ihre Organisation eine andere CI-Plattform nutzt.

Berücksichtigen Sie auch, dass ein Runner eine Vertrauensgrenze ist. Ein unerwünschter Workflow oder ein kompromittierter Runner könnte auf verfügbare Geheimnisse zugreifen. Die Sicherheitsdokumentation zu Risiken kompromittierter Runner ist deshalb relevant, wenn Sie Secrets auf einem CI-Knoten bereitstellen. Ergänzend können Sie für unterstützte CI-Umgebungen die Umgebungs- und Deployment-Schutzregeln prüfen. Diese Funktionen belegen jedoch weder die physische Isolation eines Mac noch die Einhaltung Ihrer internen Freigabeprozesse.

Bei der Abnahme: Echte Mac-Builds und Signaturergebnisse vergleichen

Ein grüner Pipeline-Status allein reicht nicht aus. Lassen Sie repräsentative Produktionsaufgaben mit dem neuen Material durchlaufen und prüfen Sie sowohl den erzeugten Build als auch das Archiv. Die Abnahme muss die tatsächliche Signaturidentität und das eingebettete Profil betreffen, nicht nur die Verfügbarkeit von Dateien im Match-Speicher.

Führen Sie die Prüfung in dieser Reihenfolge durch:

1. Wählen Sie ein Projekt, das die betroffene Identität und den relevanten Verteilungsweg nutzt.
2. Starten Sie den Build auf dem Mac-Knoten, der später die Aufgabe übernehmen soll.
3. Prüfen Sie im Pipeline-Log, welche Identität und welches Profil tatsächlich verwendet wurden.
4. Kontrollieren Sie das Archiv und die eingebetteten Signaturinformationen.
5. Lassen Sie den vorgesehenen Test-, Verteilungs- oder Veröffentlichungsweg ausführen, soweit dieser für die Änderung relevant ist.
6. Vergleichen Sie die Ergebnisse mit Ihrer dokumentierten Baseline und halten Sie Abweichungen fest.

Wenn ein Profil nicht eingebettet oder die Signatur nicht wie erwartet eingesetzt wird, untersuchen Sie zunächst den Profilbezug und die Keychain-Nutzung. Apple beschreibt in seiner technischen Dokumentation, wie Provisioning-Profile und Signaturmeldungen zusammenhängen; verwenden Sie dafür TN2415 zu Provisioning Profiles und Signaturprotokollen. Nutzen Sie die dort beschriebenen Hinweise zusammen mit den konkreten Logs Ihres Builds. Ein erfolgreicher Match-Download ist kein Beleg dafür, dass der Build korrekt signiert ist.

Woran erkennen Sie, dass der Mac-CI-Knoten die neuen Signatur-Assets verwendet?

Vergleichen Sie die im Build verwendete Signaturidentität mit der freigegebenen neuen Identität. Prüfen Sie außerdem das eingebettete Profil im erzeugten Archiv und bestätigen Sie, dass der vorgesehene Verteilungsweg damit funktioniert. Wenn eines dieser Ergebnisse fehlt oder widersprüchlich ist, erweitern Sie den Rollout nicht. Bewahren Sie Logs und Prüfergebnisse auf, damit ein späterer Fehler nicht mit einer bloßen Vermutung über die Zertifikatsdatei erklärt werden muss.

Legen Sie vor dem Pilot fest, wann Sie zurückrollen. Ein geeigneter Rückfall ist nicht „irgendein älteres Zertifikat“, sondern die Wiederherstellung des dokumentierten, bekannten Zustands, soweit dieser noch gültig und organisatorisch freigegeben ist. Stoppen Sie die Ausweitung, wenn Signaturidentität, Profil oder Release-Ergebnis nicht eindeutig belegt sind. Halten Sie fest, welche Änderung zurückgenommen wurde und welche offenen Punkte eine erneute Abnahme verhindern.

Nach bestandener Abnahme: Altbestand mit dokumentierter Freigabe behandeln

Erst wenn alle betroffenen Produktionsworkflows und relevanten Mac-Knoten geprüft sind, entscheiden Sie über den alten Bestand. Die Entscheidung kann je nach Abhängigkeiten lauten, ihn vorerst kontrolliert aufzubewahren, ihn aus einem Workflow zu entfernen oder den Widerruf nach Genehmigung auszuführen. Löschen Sie nicht das einzige wiederherstellbare Signaturmaterial, solange nicht geklärt ist, ob ein noch benötigter Prozess davon abhängt.

Dokumentieren Sie für die Revision mindestens:

• Eigentümer und verantwortliche Freigabestelle für die neue Signaturidentität.
• Geänderte Zertifikate, private Schlüssel, Profile und CI-Secrets.
• Die betroffenen Apps, Release-Aufgaben und Mac-Knoten.
• Build-, Archiv- und Signaturprüfungen als Abnahmenachweis.
• Rückfallbedingung und Ergebnis der Altbestandsentscheidung.

Wann darf das alte Zertifikat widerrufen werden?

Widerrufen Sie es erst, wenn Sie den Einsatz in allen relevanten Workflows geprüft und die Folgen für verknüpfte Profile bewertet haben. Vor der Freigabe sollten die neue Identität und das zugehörige Profil auf dem tatsächlichen Mac-CI-Knoten erfolgreich geprüft, die Release-Aufgabe abgenommen und eine Wiederherstellungsentscheidung dokumentiert sein. Ist die Abhängigkeit eines Produktions- oder Ersatzworkflows unklar, bleibt der Widerruf offen, bis die Zuständigkeit und der Einflussbereich geklärt sind.

Nutzen Sie für die Entscheidung eine klare Verzweigung:

• Wenn alle relevanten Builds mit der neuen Signaturidentität erfolgreich erstellt und die Profile geprüft wurden, dann kann die zuständige Stelle die Stilllegung des alten Materials freigeben.
• Wenn ein Produktionsworkflow, ein Ersatzknoten oder ein App-Kennzeichen nicht geprüft ist, dann stoppen Sie den Widerruf und ergänzen die Abnahme.
• Wenn die neue Signatur funktioniert, aber ein CI-Secret oder Hostzugriff zu weit vergeben ist, dann korrigieren Sie zuerst die Berechtigungen und wiederholen die Sicherheitsprüfung.
• Wenn ein Build fehlschlägt oder die Signaturidentität nicht eindeutig ist, dann rollen Sie nicht weiter aus und kehren Sie zum dokumentierten, bekannten Zustand zurück.

Den passenden Mac-Knoten als Teil der Signaturverantwortung bewerten

Die Zertifikatsrotation löst keine Fragen zur Hostverwaltung. Sie müssen weiterhin festlegen, wer auf dem Mac arbeitet, wie CI-Secrets zugänglich sind, welche Arbeitslasten auf dem Knoten laufen und welche Nachweise Ihre Datenschutz- und Sicherheitsvorgaben verlangen. Ein Remote Mac kann eine Option sein, wenn zusätzliche macOS-Kapazität für einen begrenzten Pilot oder einen klar abgegrenzten Buildprozess fehlt. Root-Zugriff, Remote-Verbindungen und die konkrete Zugriffskonfiguration müssen dabei in Ihre eigene Sicherheitsbewertung einfließen; eine Mietlösung ersetzt weder die Verwaltung der Signatur-Assets noch Ihre Freigabe- und Auditverantwortung.

Vergleichen Sie die Alternativen anhand derselben Kriterien. Ein bereits vorhandener Team-Mac vermeidet einen zusätzlichen Bereitstellungspfad, kann aber bei unklarer Zuständigkeit, wechselnden Benutzern oder uneinheitlicher Keychain-Konfiguration die Abnahme erschweren. Ein neu beschaffter eigener Knoten bietet direkte Kontrolle über die Hardware, bindet jedoch Beschaffung und Geräteverwaltung. Ein gemieteter Remote Mac kann zusätzliche Kapazität bereitstellen, doch Zugriff, Geheimnisse, Wiederherstellung und Nachweisführung müssen weiterhin von Ihnen geplant werden.

Wenn Ihre aktuelle Build-Umgebung auf Entwicklergeräten oder einem gemeinsam genutzten Mac beruht, prüfen Sie vor einer Änderung, ob Sie Eigentümer, Zugriffsweg, Xcode-Stand und Wiederherstellung eindeutig nachweisen können. Unklare Benutzerzuständigkeiten, verstreute Signaturmaterialien und fehlende CI-Abnahme sind konkrete Risiken – nicht Probleme, die durch einen anderen Abrechnungsmodus automatisch verschwinden. Benötigen Sie für eine begrenzte Rotationsprüfung einen zusätzlichen Mac-Knoten, können Sie die Remote-Mac-Angebote von VMSPIN und die Preisübersicht mit den eigenen Beschaffungs- und Betriebsanforderungen abgleichen. Entscheiden Sie erst nach Prüfung, ob Mietzugriff und Sicherheitsprozess zu Ihrer Umgebung passen; für dauerhaft hohe, planbare Auslastung oder Anforderungen an physische Schnittstellen kann ein eigener Mac die passendere Lösung bleiben.