Wie erfolgt die Rotation von Unternehmens-iOS-CI-Zertifikaten? Release-Plan 2026

Da ein widerrufenes Zertifikat zugehörige Provisioning Profiles ungültig machen kann, muss die Zertifikatsrotation für Unternehmens-iOS-CI mit der Prüfung des Zertifikatstyps und der Kontoregeln beginnen. Aktualisieren Sie danach die betroffenen Profile, testen Sie die vollständige Signatur- und Bereitstellungskette isoliert und schalten Sie Produktionsjobs erst nach bestandener Abnahme um. Bei Verdacht auf einen kompromittierten privaten Schlüssel hat die Sicherheitsreaktion Vorrang vor einer geplanten Umstellungsphase. Apple erläutert die Folgen eines Zertifikatswiderrufs.

Dieser Ablauf richtet sich an IT-Verantwortliche, die Apple-Developer-Konten und Signatur-Assets verwalten.
Plattformteams erhalten Prüfpunkte für Profile, Build-Knoten und Produktionsumstellungen.
Release- und Sicherheitsverantwortliche können normale Rotation und Notfallreaktion voneinander abgrenzen.

[ SECTION_01 ] Unternehmens-iOS-CI-Zertifikatsrotation: erst den Asset-Typ bestimmen

Vor dem Erstellen eines Ersatz-Assets muss feststehen, was tatsächlich rotiert wird. „Zertifikat“ bezeichnet nicht automatisch denselben Verwendungszweck: Apple unterscheidet Entwicklungs- und Distributionszertifikate sowie Zertifikate für die Verteilung von Mac-Apps. Cloud-verwaltete Zertifikate folgen wiederum einem eigenen Bereitstellungsweg. Die Apple-Übersicht zu Zertifikatstypen und Verwendungszwecken sollte deshalb gemeinsam mit dem aktuellen Kontostatus geprüft werden.

Asset oder Mechanismus	Wofür es steht	Was vor der Rotation geprüft werden muss
Apple Distribution-Zertifikat	Signierung für die Verteilung von iOS-Apps, etwa im App-Store-Veröffentlichungsprozess	Welche App-IDs und Profile es verwenden und ob das neue Zertifikat in den benötigten Profilen enthalten ist
Entwicklungszertifikat	Signierung für Entwicklung und Tests	Welche Entwicklungsprofile und Testabläufe das Zertifikat voraussetzen
Developer ID-Zertifikat	Signierung von Mac-Apps für Verteilung außerhalb des Mac App Store	Ob tatsächlich ein Mac-Verteilungsprozess betroffen ist; nicht mit iOS-Distribution gleichsetzen
Cloud-verwaltetes Zertifikat	Von Apple verwalteter Zertifikatsweg für unterstützte Veröffentlichungsabläufe	Ob der Kontotyp und der vorgesehene Xcode- beziehungsweise Upload-Prozess diesen Weg verwenden
Provisioning Profile	Verknüpft Signaturinformationen mit App-ID und weiteren Berechtigungen	Ob Profilinhalt und Ablauf mit dem neuen Zertifikat und der tatsächlichen Signaturmethode übereinstimmen

Die Tabelle ist eine Prüfhilfe, kein Versprechen, dass alle Typen parallel ersetzt werden können. Apple führt die Typen und ihre Zwecke getrennt auf; Kontostatus, Rollen und konkrete Signaturmethode entscheiden über den möglichen Ablauf. Für cloud-verwaltete Zertifikate gelten eigene Hinweise zu Verwendung und Rotation. Apples Dokumentation zu cloud-verwalteten Zertifikaten ist daher keine allgemeine Anleitung für manuell verwaltete Zertifikate.

Auch die Verteilung verändert die Folgen eines Widerrufs. Ein Vorgang für App-Store-Uploads ist nicht automatisch mit einem Developer ID-Verteilungspfad gleichzusetzen. Prüfen Sie daher für jede betroffene Anwendung, ob ein Fehler den Build, den Export, die Übermittlung oder bereits verteilte Installationen betrifft. Eine pauschale Aussage wie „alte Zertifikate können immer bis nach dem Release bestehen bleiben“ ist nicht belastbar.

[ SECTION_02 ] Bestandsaufnahme vor dem Wechsel

Erstellen Sie eine nachvollziehbare Zuordnung zwischen Anwendungen, CI-Jobs und Signatur-Assets. Der Zweck ist nicht, eine ideale Inventardatenbank zu entwerfen, sondern vor einer Änderung festzustellen, welche Produktionswege tatsächlich auf das zu ersetzende Zertifikat angewiesen sind.

Halten Sie für jedes betroffene Vorhaben fest:

• App-ID und zugehörige Anwendung;
• CI-Pipeline, Build- und Veröffentlichungsjob sowie zugeordneter Mac-Knoten;
• Zertifikatstyp, Ablaufstatus und Ablageort des privaten Schlüssels;
• Provisioning Profile, Signaturmodus und verwendete Entitlements;
• zuständige Person für Apple-Developer-Kontoberechtigungen und Freigabe;
• letzter dokumentierter erfolgreicher Build, Export und Veröffentlichungsschritt.

Die Ausgangsbasis muss aus tatsächlichen Teamunterlagen stammen: Kontoeinträgen, vorhandenen Profilen, CI-Konfigurationen und dem Protokoll eines erfolgreichen Laufs. Schätzen Sie weder die Anzahl betroffener Anwendungen noch die Verfügbarkeit eines Ersatzprofils. Wenn die Zuordnung nicht verlässlich ist, ist zunächst die Bestandsaufnahme unvollständig; eine produktive Rotation sollte dann nicht als routinemäßige Änderung behandelt werden.

Trennen Sie außerdem vier Dinge, die in Fehleranalysen häufig vermischt werden: das Zertifikat, den privaten Schlüssel, das Provisioning Profile und die Zugriffsrechte auf Konto und CI-Knoten. Ein installiertes Zertifikat ohne passenden privaten Schlüssel ermöglicht nicht automatisch die vorgesehene Signierung. Umgekehrt bedeutet eine funktionierende Anmeldung am Mac nicht, dass die verwendete Kontorolle Zertifikate erstellen oder widerrufen darf.

Apple weist unterschiedliche Berechtigungen für Kontorollen aus. Prüfen Sie deshalb vor dem Wartungsfenster, ob die handelnde Person den konkreten Vorgang im Entwicklerkonto ausführen darf; verlassen Sie sich nicht allein auf die Rolle im CI-System. Die Apple-Tabelle zu Rollen und Berechtigungen dient dabei als Referenz. Legen Sie zudem eine verantwortliche Person für Freigabe, Ausführung und Rückfallentscheidung fest. So wird im Störungsfall nicht erst während des Releases nach einer zuständigen Kontorolle gesucht.

Hinweis: Ein sauberer CI-Lauf vor dem Wechsel ist die Vergleichsbasis, aber kein Nachweis dafür, dass ein Ersatzprofil bereits korrekt ist. Dokumentieren Sie die konkret eingesetzten Zertifikats- und Profilinformationen.

[ SECTION_03 ] Vorbereitung und Erstellung des Ersatz-Assets

Wählen Sie den Rotationsweg anhand des ermittelten Zertifikatstyps und des aktuellen Kontostands. Prüfen Sie verfügbare Zertifikate, bestehende Profile, Rollenberechtigungen und die von Apple beschriebenen Einschränkungen, bevor ein neues Asset erstellt oder ein altes widerrufen wird. Verlassen Sie sich nicht auf die Annahme, dass ein neues und ein altes Zertifikat in jedem Kontozustand gleichzeitig verwendbar sind.

Falls parallele Validierung nach den tatsächlichen Kontoregeln nicht möglich ist, planen Sie ein kontrolliertes Wartungsfenster. Kommunizieren Sie vorab, welche Jobs pausiert werden, wer die Umschaltung freigibt und welche Bedingungen einen Abbruch auslösen. „Ohne Unterbrechung“ darf nicht zugesagt werden, wenn die nötige Koexistenz der Assets nicht nachgewiesen wurde.

Achten Sie beim Erstellen eines Ersatzes besonders auf den privaten Schlüssel. Dokumentieren Sie, wo er erzeugt wird, wie er geschützt zum Build-Knoten gelangt und welche Personen oder Prozesse darauf zugreifen können. Beschränken Sie den Zugriff auf den erforderlichen Signaturpfad. Ein Zertifikatsexport ohne sichere Behandlung des zugehörigen Schlüssels kann ein neues Sicherheitsproblem schaffen, obwohl die Rotation technisch erfolgreich aussieht.

Wenn ein Cloud-verwaltetes Zertifikat infrage kommt, prüfen Sie den entsprechenden Apple-Prozess separat. Übertragen Sie dabei keine Schritte aus der manuellen Zertifikatsverwaltung, ohne zu bestätigen, dass sie für diesen Mechanismus gelten. Apple beschreibt für cloud-verwaltete Zertifikate einen eigenen Einsatz- und Rotationskontext; maßgeblich sind das konkrete Konto und die gewählte Veröffentlichungsmethode.

[ SECTION_04 ] Profile und Signierkonfiguration aktualisieren

Ein Austausch im Schlüsselbund allein aktualisiert keine Konfiguration, die weiterhin auf ein altes Profil oder eine alte Signaturidentität verweist. Prüfen Sie jedes betroffene Provisioning Profile auf App-ID, eingebundenes Zertifikat und benötigte Berechtigungen. Apple dokumentiert sowohl das Erstellen von App-Store-Profilen als auch deren Bearbeitung und Aktualisierung. Die Anleitung zum App-Store-Profil und Apples Hinweise zum Bearbeiten, Herunterladen oder Löschen von Profilen helfen, den Profilweg korrekt zu bestimmen.

Bei manueller Signierung muss die Pipeline explizit das vorgesehene Profil und die passende Identität verwenden. Prüfen Sie, ob der CI-Job nach einem Download tatsächlich die neue Profilversion referenziert und nicht eine lokal gespeicherte Kopie aus einem Cache. Kontrollieren Sie außerdem, ob die verwendete App-ID und die benötigten Entitlements mit der Profilkonfiguration übereinstimmen.

Bei Xcode-verwalteten Profilen darf die Annahme „Xcode kümmert sich darum“ die Prüfung nicht ersetzen. Überprüfen Sie den verwendeten Team-Kontext, die im Build gewählte Signaturkonfiguration und das Profil, das beim Archivieren tatsächlich herangezogen wird. Die Apple-Dokumentation zu Aktualisierungen von Provisioning Profiles ist relevant, wenn Zertifikatsänderungen oder Profiländerungen eine erneute Bereitstellung erforderlich machen.

Sichern Sie die bisherige Konfiguration so, dass ein Rückfall möglich ist, ohne alte private Schlüssel unkontrolliert weiterzuverwenden. Kennzeichnen Sie alte Dateien und Cache-Einträge eindeutig. Aktualisieren Sie die Pipeline-Referenzen und den Schlüsselbundzugriff in einem nachvollziehbaren Änderungsschritt; vermischen Sie diesen Vorgang nicht mit einer gleichzeitigen Änderung von App-ID, Entitlements oder Upload-Zugangsdaten. Sonst lässt sich ein Fehler später schwer einer Ursache zuordnen.

[ SECTION_05 ] Isolierte Mac-CI-Abnahme vor dem Produktionswechsel

Die neue Signierung sollte zuerst auf einem vom regulären Produktionsjob getrennten Mac-CI-Knoten oder in einer isolierten Testpipeline geprüft werden. Der Test muss die Release-Kette abbilden, nicht nur die erfolgreiche Installation eines Zertifikats. Verwenden Sie dafür eine repräsentative Anwendung, ohne die produktive Signaturkonfiguration zu überschreiben.

Gehen Sie in dieser Reihenfolge vor:

1. Identität prüfen: Lassen Sie den Build die erwartete Signaturidentität erkennen. Verifizieren Sie, dass der private Schlüssel für den tatsächlichen CI-Prozess verfügbar ist und der Zugriff nicht von einer interaktiven Sitzung abhängt.
2. Profilzuordnung prüfen: Kontrollieren Sie, welches Provisioning Profile der Build verwendet. Stimmen App-ID, Zertifikat und benötigte Berechtigungen mit dem vorgesehenen Veröffentlichungsweg überein?
3. Archivierung und Export ausführen: Erzeugen Sie ein Archiv und exportieren Sie es mit der Konfiguration, die dem Zielpfad entspricht. Ein erfolgreicher Compile-Schritt allein belegt keine erfolgreiche Signierung.
4. Übergabe testen: Prüfen Sie den vorgesehenen nächsten Schritt, zum Beispiel die Übergabe an den festgelegten Veröffentlichungsprozess. Lassen Sie die Pipeline dabei keine ungeprüfte Veröffentlichung auslösen.
5. Artefakte und Protokolle prüfen: Vergewissern Sie sich, dass weder Build-Ausgabe noch Profil- oder Cache-Referenzen unerwartet auf das alte Asset zeigen. Halten Sie die tatsächlich verwendeten Assets und das Testergebnis fest.
6. Abnahme und Rückfall freigeben: Dokumentieren Sie, wer den Test geprüft hat, welche Abbruchbedingungen gelten und wie die vorherige Pipeline-Konfiguration wiederhergestellt wird.

Diese Prüfschritte sind ein bewusstes Entscheidungstor: Solange Signatur, Archivierung, Export und Übergabe nicht erfolgreich nachgewiesen sind, bleibt der Produktionsjob unverändert. Ein grüner Build allein genügt nicht. Prüfen Sie auch, ob der Test auf dem vorgesehenen Knotentyp und mit dem tatsächlichen Agentenkontext ausgeführt wurde.

Bewerten Sie den Test als bestanden, wenn die Ausgabe nachvollziehbar dem neuen Asset zugeordnet ist, der vorgesehene Bereitstellungspfad funktioniert und die Rückfallmöglichkeit dokumentiert bleibt. Schlägt ein Teil fehl, ändern Sie nicht gleichzeitig weitere Signaturparameter, um „irgendwie“ ein grünes Ergebnis zu erhalten. Isolieren Sie die Ursache zuerst: Profil, Schlüsselzugriff, Kontoberechtigung, Build-Konfiguration oder Knotenidentität.

[ SECTION_06 ] Produktionsumstellung und Behandlung alter Assets

Schalten Sie nach bestandener Abnahme nicht alle Anwendungen und Pipelines blind gemeinsam um. Gruppieren Sie die Änderung nach tatsächlicher Abhängigkeit und Veröffentlichungspriorität. Beginnen Sie mit einem kontrollierbaren Produktionspfad, beobachten Sie dessen Ergebnis und setzen Sie die übrigen Umstellungen erst fort, wenn die zuvor definierten Freigabebedingungen erfüllt sind.

Halten Sie während der Umstellung einen klaren Stopp-Punkt fest. Ein unerwartetes Profil, eine fehlende Signaturidentität oder eine Abweichung zwischen Test- und Produktionsausgabe sind Gründe, den nächsten Schritt auszusetzen. Falls der alte Asset-Zustand nicht mehr nutzbar ist, sollte die Rückfallplanung auf einer geprüften Ersatzkonfiguration beruhen, nicht auf dem ungeprüften Wiedereinsetzen eines alten Schlüssels.

Entscheiden Sie über Widerruf und Bereinigung nach Zertifikatstyp, Sicherheitslage und Apple-Regeln. Ein altes Zertifikat sollte nicht allein deshalb weiter zugänglich bleiben, weil es noch irgendwo in einem Schlüsselbund liegt. Andererseits kann ein unbedachter Widerruf Profile beeinträchtigen. Apple erläutert den Widerrufsprozess und die erforderlichen Berechtigungen gesondert: Prüfen Sie sowohl die Auswirkungen beim Widerruf als auch die Berechtigungen für den Widerruf, bevor Sie den Schritt ausführen.

Bei einem vermuteten Schlüsselverlust ist die Lage anders als bei einer planmäßigen Rotation. Eskalieren Sie den Vorfall an die zuständige Sicherheits- und Kontoverantwortung, begrenzen Sie den Zugriff auf betroffene CI-Knoten und folgen Sie dem vorgesehenen Widerrufs- und Wiederherstellungsverfahren. Warten Sie nicht auf ein reguläres Release-Fenster, wenn der Schlüssel tatsächlich kompromittiert sein könnte. Planen Sie danach die Reparatur betroffener Profile und die erneute Abnahme der betroffenen Veröffentlichungspfade.

Prüfliste für die Freigabe

• [ ] Zertifikatstyp und Veröffentlichungsweg für jede betroffene Anwendung sind dokumentiert.
• [ ] Kontorolle und Berechtigung für Erstellung, Änderung oder Widerruf sind geprüft.
• [ ] Betroffene App-IDs, Pipelines, Mac-Knoten, Profile und Schlüsselablagen sind zugeordnet.
• [ ] Letzter erfolgreicher Produktionspfad und Rückfallbedingungen sind festgehalten.
• [ ] Ersatz-Asset und privater Schlüssel werden kontrolliert erstellt und bereitgestellt.
• [ ] Profile wurden auf App-ID, Zertifikat und erforderliche Berechtigungen geprüft.
• [ ] Isolierter Mac-CI-Test umfasst Signierung, Archivierung, Export und Übergabe.
• [ ] Protokolle und Artefakte zeigen die erwarteten neuen Assets.
• [ ] Produktionsfreigabe und Stopp-Kriterien sind einer verantwortlichen Person zugeordnet.
• [ ] Widerruf und Bereinigung alter Assets berücksichtigen deren tatsächliche Auswirkungen.

Wenn die meisten Punkte nicht belegbar abgehakt werden können, ist die Änderung noch nicht produktionsreif. Fehlt nur der Nachweis der isolierten Signaturkette, sollte zunächst die Testpipeline ergänzt und nicht der Produktionsjob als Versuchsumgebung verwendet werden.

[ SECTION_07 ] Häufige Fragen zur Zertifikatsrotation

Wiederherstellung nach einem abgelaufenen Zertifikat

Nach Ablauf eines Signaturzertifikats ist zunächst der betroffene Zertifikatstyp festzustellen. Ermitteln Sie dann, welche Profile und Jobs daran gebunden sind, und erstellen oder aktivieren Sie ein passendes Ersatz-Asset nach den Kontoregeln. Aktualisieren Sie die Profile, prüfen Sie Schlüsselzugriff und Signatur auf einem isolierten Mac-Knoten und schalten Sie erst nach erfolgreichem Export und Übergabetest um.

Neues Apple Distribution-Zertifikat und Profil

Ein neues Apple Distribution-Zertifikat bedeutet nicht automatisch, dass jedes Profil identisch behandelt werden muss. Entscheidend ist, ob das konkrete Provisioning Profile das neue Zertifikat enthält und für die tatsächliche App-ID sowie den Release-Pfad gültig ist. Fehlt die Zuordnung, bearbeiten oder erstellen Sie das Profil nach dem dokumentierten Apple-Verfahren und testen Sie anschließend den realen CI-Export.

Test ohne Eingriff in den laufenden Release

Trennen Sie die Validierung technisch vom produktiven Veröffentlichungsjob. Ein isolierter Mac-CI-Knoten oder eine gesonderte Testpipeline sollte dieselbe Signierkonfiguration verwenden, aber keine produktive Umstellung auslösen. Prüfen Sie Zertifikatserkennung, Profil, Archiv, Export und Übergabe. Bewahren Sie Protokolle und Rückfallkonfiguration auf und definieren Sie vor dem Test, bei welchem Fehler die Freigabe stoppt.

Verdacht auf einen kompromittierten privaten Schlüssel

Bei einem glaubwürdigen Verdacht hat die Eindämmung Vorrang vor einem planmäßigen Wechsel. Stimmen Sie die erforderliche Sperrung mit der zuständigen Kontorolle ab, begrenzen Sie den Schlüsselzugriff und bestimmen Sie, welche Profile und Veröffentlichungswege betroffen sind. Da ein Widerruf Profile beeinträchtigen kann, müssen Ersatz-Assets und deren Abnahme folgen. Verzögern Sie eine notwendige Sicherheitsmaßnahme nicht, um eine Parallelphase einzuhalten.

Für Teams, die keinen dedizierten Mac-Knoten für eine abgeschottete Abnahme vorhalten möchten, ist ein gemieteter Remote-Mac eine mögliche Testumgebung – sofern Zugriffsschutz, Schlüsselübergabe und Zuständigkeiten zum eigenen Sicherheitsmodell passen. Ein lokaler, bereits kontrollierter Mac kann für seltene Tests geeigneter sein; bei dauerhaft hoher, verlässlich planbarer Build-Last ist ein eigener Knoten ebenfalls zu prüfen. Für einen befristeten Pilotbetrieb kann NOVAKVM als weitere Option bewertet werden: Die Übersicht zu NOVAKVM und die Angaben zum Mac mini M4 können in die Beschaffungsprüfung einbezogen werden. Vor einer produktiven Nutzung sollten die Verantwortlichen die tatsächlichen Zugriffs-, Datenschutz- und Betriebsanforderungen gegen die angebotenen Bedingungen abgleichen.

Häufige Fragen

Wie lässt sich eine iOS-CI-Pipeline nach einem abgelaufenen Signaturzertifikat wieder in Betrieb nehmen?

Prüfen Sie zuerst, welche Zertifikatsart abgelaufen ist und welche App-IDs und Profile davon abhängen. Erstellen oder aktivieren Sie das passende Ersatz-Asset nach den Regeln des Entwicklerkontos, aktualisieren Sie betroffene Profile und importieren Sie Zertifikat samt privatem Schlüssel kontrolliert auf einen isolierten Mac-CI-Knoten. Erst wenn Archivierung, Export und der vorgesehene Bereitstellungspfad funktionieren, sollte die Produktionspipeline umgestellt werden.

Muss nach dem Austausch eines Apple-Distribution-Zertifikats auch das Provisioning Profile erneuert werden?

Prüfen Sie das konkrete Profil, statt von einer pauschalen Regel auszugehen. Ein App-Store-Profil ist an bestimmte Signaturinformationen gebunden; ist das neue Zertifikat dort nicht enthalten, muss das Profil passend bearbeitet oder neu erstellt und anschließend auf dem Build-Knoten eingesetzt werden. Apple beschreibt die Bearbeitung und Aktualisierung von Profilen in der offiziellen Kontodokumentation. Eine bloße Installation des neuen Zertifikats reicht nicht aus.

Wie kann ein neues Zertifikat getestet werden, ohne den offiziellen iOS-Release zu unterbrechen?

Führen Sie den Test auf einem isolierten Mac-CI-Knoten oder in einer getrennten Testpipeline durch, ohne die produktive Signaturkonfiguration zu überschreiben. Verwenden Sie eine repräsentative Anwendung und prüfen Sie Zertifikatserkennung, Profilzuordnung, Archivierung, Export und den vorgesehenen Übergabepfad. Protokollieren Sie die verwendeten Assets und legen Sie vor dem Test fest, bei welchen Fehlern die Produktionsumstellung gestoppt wird.

Was hat bei einem Verdacht auf einen gestohlenen privaten Signaturschlüssel Vorrang?

Behandeln Sie den Verdacht als Sicherheitsereignis und verzögern Sie eine notwendige Sperrung nicht, nur um eine geplante Parallelphase einzuhalten. Stimmen Sie die Sperrung mit der zuständigen Kontorolle ab, ermitteln Sie betroffene Zertifikate und Profile und stellen Sie gültige Ersatz-Assets bereit. Da eine Sperrung Profile beeinträchtigen kann, müssen betroffene Anwendungen und Veröffentlichungswege anschließend gezielt geprüft und wiederhergestellt werden.