iOS-Signaturzertifikate rotieren: CI/CD-Checkliste 2026

Wenn ein iOS-Build plötzlich wegen eines abgelaufenen Signaturzertifikats scheitert, ist die Ursache häufig nicht das Zertifikat allein, sondern ein nicht aktualisiertes Provisioning Profile oder ein einzelner veralteter Mac-Buildknoten.

Die schnellste sichere Lösung: Erstellen Sie das neue Signaturzertifikat vor dem Ablauf, aktualisieren Sie die zugehörigen Provisioning Profiles, testen Sie den vollständigen Archivierungs-, Signierungs-, Export- und Upload-Weg auf einem isolierten Mac-Knoten und widerrufen Sie das alte Zertifikat erst nach belegter Umschaltung. Bei einem Verdacht auf kompromittierte private Schlüssel hat die Schadensbegrenzung Vorrang vor einer bequemen Übergangsphase.

Diese Woche sollten Sie die Zertifikatsliste, die verantwortlichen Rollen, die betroffenen Bundle IDs und alle Mac-Buildknoten erfassen. Danach legen Sie einen Verifikationsknoten fest und definieren, welche Belege vor dem Widerruf zwingend vorliegen müssen.

SECTION 01 Für wen diese Checkliste gedacht ist

Diese Anleitung richtet sich an IT-Administratoren, die den Apple Developer-Zugang, Signaturberechtigungen und den Zertifikatslebenszyklus verwalten.

Sie ist außerdem für Plattformteams relevant, die iOS CI/CD, Keychain und Mac-Buildknoten betreiben, sowie für Release-, Sicherheits- und Entwicklungsverantwortliche, die eine Produktionsumschaltung genehmigen müssen.

Wenn Sie lediglich eine einzelne App lokal in Xcode entwickeln, benötigen Sie nicht alle Kontrollpunkte dieses Artikels. Für mehrere Anwendungen, mehrere Entwickler oder gemeinsam genutzte Buildinfrastruktur sollten Sie die vollständige Rollen- und Nachweiskette verwenden.

SECTION 02 Das Entscheidungsmodell für die Zertifikatsrotation

Eine Zertifikatsrotation ist kein einzelner Download-Vorgang. Sie besteht aus vier voneinander abhängigen Entscheidungen:

1. Darf die zuständige Person ein neues Zertifikat erstellen?
2. Sind privater Schlüssel, Zertifikat und Provisioning Profile auf dem vorgesehenen Buildknoten verfügbar?
3. Funktioniert der echte Veröffentlichungsweg mit der neuen Signatur?
4. Darf das alte Zertifikat widerrufen werden, ohne aktive Profile oder laufende Releases zu beschädigen?

Bei einer normalen Ablaufrotation sollten Sie eine kontrollierte Überlappung einplanen. Das alte Zertifikat bleibt so lange verfügbar, bis die neue Signatur auf allen produktiv relevanten Knoten geprüft wurde. Diese Überlappung ist keine Apple-Vorgabe, sondern eine interne Betriebsentscheidung, die Sie in Ihrer Freigaberichtlinie festhalten sollten.

Bei einem Verdacht auf einen kompromittierten privaten Schlüssel gilt eine andere Priorität. Dann dürfen Sie das alte Zertifikat nicht allein deshalb weiterverwenden, damit die Pipeline kurzfristig grün bleibt. Sie müssen zuerst den möglichen Umfang des Vorfalls dokumentieren, den Zugriff einschränken und die zuständige Rolle für einen Notfallwiderruf einbeziehen.

Apple weist darauf hin, dass ein widerrufenes Zertifikat die darin enthaltenen Provisioning Profiles ungültig machen kann. Deshalb ist „neues Zertifikat erstellt“ kein ausreichender Grund für den Widerruf. (developer.apple.com)

SECTION 03 Zuständigkeiten im Apple-Developer-Konto

In einem Unternehmen sollte die Person, die einen privaten Schlüssel in eine CI-Umgebung importiert, nicht automatisch auch über die Berechtigung zum Widerruf des Produktionszertifikats verfügen. Diese Trennung reduziert das Risiko, dass ein kompromittierter Buildknoten unmittelbar die gesamte Signaturkette kontrolliert.

Apple beschreibt für Organisationen insbesondere die Rollen Account Holder, Admin und Developer. Der Account Holder verwaltet unter anderem die Mitgliedschaft und zentrale Kontozugriffe. Für die Erstellung und den Widerruf von Distribution-Zertifikaten sind nach Apples Rollenübersicht Account Holder oder Admin erforderlich; ein Developer besitzt diese Widerrufsberechtigung nicht. (developer.apple.com)

Eine belastbare RACI-Zuordnung kann so aussehen:

Die Anforderung sollte mindestens den Antragsteller, den Zertifikatsfingerprint, das zugehörige Team, den Verwendungszweck und die geplanten Widerrufsobjekte enthalten. Ergänzen Sie außerdem die betroffenen Bundle IDs und die Liste der Buildknoten. Ohne diese Zuordnung kann später niemand zuverlässig feststellen, ob ein fehlgeschlagener Build auf ein falsches Zertifikat, ein falsches Profile oder einen nicht aktualisierten Knoten zurückgeht.

SECTION 04 Vorbereitung durch den Apple-Developer-Administrator

Beginnen Sie nicht mit dem Import auf dem Buildserver. Beginnen Sie mit einer Bestandsaufnahme im Apple Developer-Konto.

Erfassen Sie für jedes relevante Zertifikat:

• Zertifikatstyp und Anzeigename
• Fingerprint oder eindeutige Identifikation
• zugehöriges Apple Developer Team
• betroffene Anwendungen und Bundle IDs
• aktueller Verwendungszweck
• verantwortliche Person
• betroffene Mac-Buildknoten
• zugehörige Provisioning Profiles
• geplanter Status: aktiv, ersetzt, zur Prüfung oder widerrufen

Prüfen Sie danach, ob die verwendete Zertifikatsart tatsächlich zur Pipeline passt. Eine Distribution-Signatur für den App-Store-Upload ist nicht automatisch mit jeder internen Testverteilung oder jedem manuellen Export gleichzusetzen. Die Signaturentscheidung muss mit Exportmethode, App-ID, Entitlements und dem verwendeten Provisioning Profile übereinstimmen.

Wenn Sie cloudverwaltete Zertifikate einsetzen, gelten zusätzliche Besonderheiten. Apple beschreibt, dass Xcode ab Version 13 bei der Organizer-Archivierung und dem Distributionsworkflow cloud signieren kann, wenn kein lokales Signaturzertifikat gefunden wird. Ein cloudverwaltetes Zertifikat wird laut Apple automatisch 90 Tage vor dem Ablauf erneuert, sobald neue Signaturanfragen eingehen. Eine manuelle Rotation kann für Account Holder und Admin möglich sein, wenn weniger als die Hälfte der Gültigkeitsdauer verbleibt, häufig also ab 180 Tagen. Diese Angaben beziehen sich auf cloudverwaltete Zertifikate und dürfen nicht pauschal auf jede lokale Apple Distribution-Identität übertragen werden. (developer.apple.com)

Wie sollte die Erneuerung eines iOS Distribution-Zertifikats vor dem Ablauf erfolgen?

Erstellen Sie zunächst eine genehmigte Anfrage, erzeugen Sie die neue Signaturidentität mit dem vorgesehenen Verantwortlichen und dokumentieren Sie den Fingerprint. Aktualisieren Sie anschließend alle betroffenen Provisioning Profiles und testen Sie den vollständigen Releaseweg. Erst wenn die Nachweise vollständig sind, sollte der Account Holder oder Admin den alten Eintrag widerrufen.

Vermeiden Sie es, ein persönliches Apple-Konto dauerhaft auf einem CI-Knoten zu hinterlegen. Der Buildknoten sollte nicht als Ersatz für ein Rollen- und Berechtigungsmodell dienen. Die Kontozugangsdaten gehören in einen kontrollierten Zugriffsprozess; private Schlüssel gehören in eine geschützte Signaturumgebung.

SECTION 05 Isolation der Signaturumgebung auf Mac-Buildknoten

Auf dem Mac-Buildknoten müssen Zertifikat und privater Schlüssel gemeinsam nutzbar sein, aber nicht unkontrolliert für beliebige Prozesse. Nutzen Sie dafür eine dedizierte CI-Keychain oder eine gleichwertige, zentral kontrollierte Schlüsselumgebung.

Prüfen Sie auf jedem Knoten mindestens diese Punkte:

1. Ist das neue Zertifikat vorhanden?
2. Ist der passende private Schlüssel vorhanden?
3. Stimmen Zertifikat und privater Schlüssel tatsächlich zusammen?
4. Kann der CI-Prozess die Keychain nach einem Neustart kontrolliert entsperren?
5. Sind nur die notwendigen Buildprozesse zugriffsberechtigt?
6. Werden temporäre Zertifikatsdateien nach dem Lauf entfernt?
7. Enthalten Buildlogs keine Passwörter, Export-Import-Phrasen oder privaten Schlüssel?
8. Wird die neue Signatur explizit ausgewählt, statt zufällig aus mehreren Identitäten zu stammen?

Apple warnt ausdrücklich davor, exportierte Signaturidentitäten ungeschützt weiterzugeben. Wer Zugriff auf die exportierte Identität und das Passwort erhält, kann Software signieren, die für Nutzer und Betriebssystem wie Software Ihres Apple Developer-Kontos erscheint. (developer.apple.com)

Die Weitergabe über Chat, öffentliche Projektverzeichnisse oder unverschlüsselte Artefaktablagen ist deshalb keine akzeptable Betriebsroutine. Auch ein verschlüsseltes Archiv ist kein vollständiges Sicherheitskonzept, wenn das Passwort in derselben Pipeline oder in frei lesbaren Umgebungsvariablen liegt.

Bei mehreren Mac-Knoten dürfen Sie nicht von einem erfolgreichen Build auf den Zustand der gesamten Flotte schließen. Vergleichen Sie pro Knoten Zertifikatsfingerprint, private-Key-Verfügbarkeit, Profile-Version, Team-ID, Bundle-ID und Entitlements. Ein einzelner alter Knoten kann sonst erst während eines Produktionsreleases auffallen.

SECTION 06 Aktualisierung der Provisioning Profiles

Das neue Zertifikat muss mit den passenden Provisioning Profiles verbunden werden. Genau hier entstehen viele scheinbare Zertifikatsprobleme: Das Zertifikat wurde korrekt erstellt, aber das Profile referenziert weiterhin die alte Identität oder ist nach einem Widerruf ungültig.

Bei manueller Verwaltung gehen Sie für jede betroffene Anwendung systematisch vor:

1. App-ID und Bundle ID bestätigen.
2. Profiltyp und Plattform bestätigen.
3. Neues Signaturzertifikat auswählen.
4. Notwendige Geräte, App-Dienste und Entitlements prüfen.
5. Neues Profile erzeugen oder ein bestehendes Profile bearbeiten.
6. Profile auf den vorgesehenen Mac-Knoten installieren.
7. Projekt- und Exportkonfiguration auf die neue Datei verweisen.
8. Archivierung und Export mit der neuen Signatur durchführen.

Apple beschreibt, dass ein Profile nach dem Widerruf eines Zertifikats repariert oder neu erzeugt werden muss. Bei manueller Signierung wird das neue Profile anschließend heruntergeladen und in Xcode installiert. Bei automatischer Signierung kann Xcode das Profile beim Export aktualisieren; in komplexen Teamumgebungen sollten Sie trotzdem nachvollziehbar dokumentieren, welches Profile verwendet wurde. (developer.apple.com)

Wie aktualisieren Sie das Provisioning Profile nach dem Zertifikatswechsel in CI/CD?

Erzeugen Sie für jede relevante Bundle ID ein Profile mit dem neuen Zertifikat, installieren Sie es auf jedem betroffenen Mac-Knoten und prüfen Sie anschließend die tatsächlichen Signatur- und Entitlements-Daten des exportierten Artefakts. Das bloße Ablegen einer neuen .mobileprovision-Datei im Arbeitsverzeichnis beweist nicht, dass Xcode oder das verwendete Buildskript diese Datei tatsächlich ausgewählt hat.

Achten Sie besonders auf:

• application-identifier
• Team-Zuordnung
• Bundle ID
• Push- und Background-Entitlements
• App Groups
• Keychain Access Groups
• Export-Methode
• verwendete Signaturidentität

Bei Anwendungen mit sensiblen Entitlements darf die Prüfung nicht auf den erfolgreichen Compile-Schritt beschränkt werden. Ein Projekt kann kompilieren und dennoch beim Export oder beim Upload wegen einer inkonsistenten Signaturkette scheitern.

SECTION 07 Nachweise für die Release-Freigabe

Der Release-Verantwortliche sollte den neuen Signaturweg auf einem nicht kritischen Branch oder einem isolierten Verifikationsknoten prüfen. Der Test muss den realen Prozess abbilden und darf nicht nur aus einem lokalen „Build succeeded“ bestehen.

Führen Sie mindestens diese fünf Schritte aus:

1. Quellstand oder Commit eindeutig festhalten.
2. Archiv mit dem neuen Zertifikat erzeugen.
3. Signiertes Artefakt exportieren.
4. Exportiertes Paket auf Bundle ID, Team und Entitlements prüfen.
5. Upload oder den vorgesehenen Veröffentlichungsweg bis zum verifizierbaren Ergebnis durchführen.

Speichern Sie als Belege den Commit, Buildlauf, Zertifikatsfingerprint, verwendeten Knoten, Profile-Namen, Exportmethode und das Ergebnis des Uploads. Secrets gehören nicht in diesen Nachweis.

Eine Rückfallplanung muss vor der Produktionsumschaltung feststehen. Definieren Sie, wer die Pipeline auf die alte Identität zurückstellen darf, solange das alte Zertifikat noch gültig und sicher ist. Definieren Sie ebenso, wann ein Rückfall nicht mehr zulässig ist, etwa wenn ein Schlüsselverlust oder ein möglicher Missbrauch festgestellt wurde.

Achtung: Ein grüner Test auf einem einzigen Mac beweist weder die Flottenfähigkeit noch die Wiederherstellbarkeit. Prüfen Sie alle produktiv relevanten Knoten und führen Sie mindestens einen Neustart- oder Wiederanlaufnachweis für die Keychain- und CI-Konfiguration durch.

SECTION 08 Freigabe und Widerruf des alten Zertifikats

Der Widerruf sollte eine eigene Freigabeentscheidung sein, nicht der letzte Klick einer technischen Routine. Vor der Freigabe müssen mindestens folgende Belege vorliegen:

• vollständige Zertifikats- und Profile-Zuordnung
• neuer Fingerprint auf jedem relevanten Knoten
• erfolgreicher Archivierungs- und Exportlauf
• erfolgreicher Upload oder gleichwertiger Release-Nachweis
• geprüfte Entitlements und Bundle IDs
• dokumentierter Rückfallweg
• bestätigte Wiederherstellung nach Neustart
• Liste aller Systeme, die noch auf das alte Zertifikat verweisen

Apple dokumentiert, dass nur der Account Holder oder ein Admin Distribution-Zertifikate widerrufen kann. Das sollte in Ihrer internen Freigabeordnung ausdrücklich berücksichtigt werden. (developer.apple.com)

Nach dem Widerruf müssen Sie die zugehörigen Provisioning Profiles erneut prüfen. Ein Profile, das ein widerrufenes Zertifikat enthält, wird ungültig. Erzeugen Sie die benötigten Profile neu und entfernen Sie die alte Identität anschließend kontrolliert aus den Buildumgebungen. (developer.apple.com)

Die häufige Frage, ob der Widerruf eines Apple Distribution-Zertifikats bereits veröffentlichte Apps automatisch aus dem Store entfernt, darf nicht mit einer pauschalen Entwarnung beantwortet werden. Der unmittelbare, von Apple ausdrücklich dokumentierte Effekt betrifft die mit dem widerrufenen Zertifikat verbundenen Provisioning Profiles. Für Ihre Betriebsentscheidung ist deshalb entscheidend, ob bereits veröffentlichte Anwendungen, interne Verteilungen, Testinstallationen und kommende Builds unterschiedliche Signatur- und Profile-Abhängigkeiten besitzen. Prüfen Sie diese Abhängigkeiten vor dem Widerruf anhand Ihrer konkreten Veröffentlichungswege.

SECTION 09 Geeignete Mac-Infrastruktur für die Rotation

Die technische Umgebung entscheidet mit darüber, ob Sie eine Rotation kontrolliert durchführen können. Eine direkt produktiv betriebene Einzelmaschine ist schnell eingerichtet, besitzt aber eine hohe Kopplung: Wenn der Import, die Keychain-Entsperrung oder das Profile fehlschlägt, ist gleichzeitig die Produktionspipeline betroffen.

Ein dedizierter Ersatz-Mac trennt die Validierung besser, verursacht aber zusätzliche Betriebsarbeit. Sie müssen Zugriff, Patchstand, Xcode-Umgebung, Keychain-Wiederherstellung und Artefaktbereinigung synchron halten. Ein kurzfristig zugeschalteter Mac-Knoten kann die Verifikation beschleunigen, wenn Sie nur für ein begrenztes Rotationsfenster zusätzliche Kapazität benötigen. Er ist jedoch nur dann sinnvoll, wenn Identitätsimport, Fernzugriff, Löschung temporärer Daten und Wiederherstellung dokumentiert sind.

Für Unternehmen, die bereits ihre Mac-Buildserver-Sicherheitsprüfung oder ihre iOS-CI/CD-Architektur überarbeiten, sollte die Zertifikatsrotation als wiederholbarer Betriebsprozess und nicht als einmaliger Notfall behandelt werden. Die Anforderungen an Zugriff, Isolation und Wiederanlauf gehören in dieselbe Infrastrukturprüfung wie die übrigen CI/CD-Kontrollen.

SECTION 10 Die prüfbare Onboarding- und Abnahmeliste

Verwenden Sie diese Liste als Übergabepunkt zwischen Apple-Developer-Administration, Plattformteam, Release, Sicherheit und Infrastruktur:

• [ ] Zertifikatstyp, Team und Zweck sind eindeutig dokumentiert.
• [ ] Alle betroffenen Bundle IDs und Provisioning Profiles sind erfasst.
• [ ] Antragsteller, Genehmiger und spätere Widerrufsrolle sind benannt.
• [ ] Fingerprint der neuen Signatur ist im Änderungsnachweis gespeichert.
• [ ] Privater Schlüssel wurde nur in der vorgesehenen CI-Keychain installiert.
• [ ] Keine Signaturdatei wurde über Chat oder öffentliche Verzeichnisse verteilt.
• [ ] Keychain-Zugriff ist auf die erforderlichen Buildprozesse begrenzt.
• [ ] Temporäre Dateien und Exportpasswörter werden nach dem Lauf entfernt.
• [ ] Jeder produktiv relevante Mac-Knoten besitzt Zertifikat und privaten Schlüssel.
• [ ] Jedes betroffene Provisioning Profile wurde aktualisiert oder neu erzeugt.
• [ ] Bundle ID, Team und Entitlements stimmen mit der Anwendung überein.
• [ ] Archivierung, Signierung, Export und Upload wurden vollständig getestet.
• [ ] Testbelege enthalten Knoten, Commit, Fingerprint und Ergebnis.
• [ ] Neustart und Wiederanlauf der Buildumgebung wurden geprüft.
• [ ] Rückfallweg und Eskalationskontakt sind dokumentiert.
• [ ] Sicherheitsprüfung auf Schlüsselverlust oder unberechtigten Zugriff ist abgeschlossen.
• [ ] Widerruf des alten Zertifikats wurde separat genehmigt.
• [ ] Nach dem Widerruf wurden ungültige Profiles ersetzt.
• [ ] Alte Identitäten und nicht mehr benötigte Geheimnisse wurden entfernt.

Abnahmematrix für die technische Umsetzung

Die Tabelle ist keine pauschale Kostenempfehlung. Entscheidend sind Ihre Anforderungen an Isolation, Wiederherstellung, Zugriffskontrolle und Releaseverfügbarkeit. Ein günstiger zusätzlicher Knoten ist keine gute Lösung, wenn private Schlüssel unkontrolliert verteilt werden. Umgekehrt kann ein dauerhaft vorgehaltener Ersatz-Mac für ein kleines Team unnötige Betriebskosten verursachen.

SECTION 11 Die nächste Infrastrukturentscheidung

Wenn Ihre bisherige Umgebung nur aus einem direkt produktiv genutzten Mac besteht, bleiben drei reale Schwächen: Die Zertifikatsprüfung findet am kritischen System statt, ein einzelner Keychain-Fehler kann den Release blockieren, und die Wiederherstellung nach einem Neustart ist oft nicht nachgewiesen. Eine lokale Beschaffung weiterer Macs verbessert die physische Kontrolle, bindet jedoch Kapital, verlängert Beschaffung und Wartung und löst die Rollen- und Profile-Probleme nicht automatisch.

Für ein zeitlich begrenztes Rotationsfenster oder eine zusätzliche Validierung kann ein gemieteter Mac die passendere Ergänzung sein, wenn Sie vollständige Root-Rechte, isolierte Nutzung, Fernzugriff und eine planbare Erweiterung benötigen. Bei VPSNIX können Sie dafür einen dedizierten Remote-Mac zunächst für einen begrenzten Zeitraum prüfen und die passende Mietdauer und verfügbare Option anhand Ihrer internen Freigabe- und Sicherheitsanforderungen auswählen. Für dauerhaft hohe Buildlast oder notwendige physische Schnittstellen bleibt ein eigener Mac im Unternehmen die ehrlichere Wahl.

Der nächste sinnvolle Schritt ist daher nicht der sofortige Widerruf, sondern die Abnahme des Verifikationsknotens: neuer Fingerprint, gültiges Profile, vollständiger Releaseweg, dokumentierter Neustart und eine von der Technik getrennte Widerrufsfreigabe. Wenn diese Nachweise fehlen, sollten Sie die alte Identität bei einer normalen Ablaufrotation noch nicht entfernen; bei einem begründeten Verdacht auf Schlüsselkompromittierung müssen Sie dagegen den Notfallprozess priorisieren und den möglichen Missbrauch eindämmen.

Weiterlesen

• CI/CD-Umgebungen für iOS-Builds und Signierung vergleichen
• Dedizierte Mac-Buildknoten für iOS-Releaseprozesse auswählen