Developer ID-Zertifikat abgelaufen: Wie migrieren Sie Mac CI? 2026

Prüfen Sie zuerst die ausstellende Zertifizierungsstelle von Developer ID Application und Developer ID Installer; ersetzen Sie betroffene Zertifikate durch passende G2-Zertifikate und testen Sie beide Signierpfade auf einer isolierten Mac-CI-Umgebung, bevor Sie Produktionsaufträge umstellen. Apple zufolge lassen sich bereits notarisierten Mac-Anwendungen mit sicherem Zeitstempel weiterverwenden, während betroffene signierte pkg-Pakete ab dem 01.02.2027 nicht mehr installiert werden können (Apple-Ankündigung).

Geeignet ist der Ablauf für Engineering-Verantwortliche, die macOS-Anwendungen oder Installationspakete signieren und veröffentlichen.
Auch IT-, Plattform- und technische Leitungen mit Verantwortung für Mac-CI-Knoten finden hier einen Prüf- und Umstellungsplan.
Kontoinhaber, die Apple-Developer-Team-Zertifikate und private Schlüssel verwalten, können damit die Ersatzbeschaffung vorbereiten.

Zuletzt aktualisiert am 04.10.2026; abgeglichen mit Apples Ankündigung und der Anleitung zum Austausch von Developer-ID-Zertifikaten. Prüfen Sie die Apple-Unterlagen vor der Umsetzung erneut, falls sie seitdem geändert wurden.

Bestandsaufnahme vor der Mac-CI-Migration

Eine ablaufende oder möglicherweise betroffene Zertifikatskette sollte nicht anhand eines Anzeigenamens oder eines Ablaufdatums allein bewertet werden. Entscheidend sind der tatsächliche Zertifikatstyp, die ausstellende Zertifizierungsstelle und die Verwendung in den Signieraufträgen. Erstellen Sie deshalb zuerst eine Übersicht, die Zertifikat, privaten Schlüssel, Mac-CI-Knoten und veröffentlichte Artefakte zusammenführt.

Nehmen Sie jeden Knoten in die Bestandsaufnahme auf, der ein Archiv signiert, eine Anwendung exportiert, ein Installationspaket erstellt oder eine Veröffentlichung durchführt. Berücksichtigen Sie neben aktiven Produktionsknoten auch Testläufe und selten verwendete Release-Aufträge: Ein noch vorhandener Schlüsselbund kann weiterhin ein nicht dokumentiertes Zertifikat enthalten.

Die Bestandsaufnahme sollte mindestens Folgendes festhalten:

• [ ] Mac-CI-Knoten und zugehöriges Betriebssystem beziehungsweise Werkzeugumgebung.
• [ ] CI-Auftrag, ausführendes Dienstkonto und verwendeter Schlüsselbund.
• [ ] Zertifikatstyp: Developer ID Application oder Developer ID Installer.
• [ ] Ausstellerangabe des Zertifikats sowie Zuordnung zum Apple-Developer-Team.
• [ ] Zugehöriger privater Schlüssel und zuständige verwaltende Rolle.
• [ ] Unterzeichnete Anwendung, pkg-Datei oder sonstiges Release-Artefakt.
• [ ] Verwendete Signier-, Notarisierungs- und Verteilungsaufträge.
• [ ] Verantwortliche Person, betroffene Teams und Belege aus den Build-Protokollen.

Sichern Sie die Ergebnisse nicht als ungeschützte Sammlung privater Schlüssel oder exportierter Zertifikate. Für die Inventarisierung reichen zunächst Zertifikatsinformationen, Zuordnungen und Verwendungsnachweise. Der private Schlüssel ist ein separates Geheimnis; seine Erzeugung, Speicherung, Weitergabe und Freigabe müssen weiterhin den internen Regeln für Zugangsdaten und Schlüsselmaterial folgen.

Die Typen dürfen dabei nicht zusammengefasst werden. Developer ID Application dient der Signierung einer Mac-Anwendung, während Developer ID Installer zum Signieren eines Installationspakets verwendet wird. Apple Distribution ist ein anderer Zertifikatstyp und kein austauschbarer Ersatz für Developer-ID-Zertifikate. Apples Übersicht zu Zertifikatstypen hilft bei der Zuordnung; die konkrete Verwendung muss zusätzlich mit dem jeweiligen Build- und Release-Auftrag abgeglichen werden.

Aussteller und betroffene Artefakte unterscheiden

Der alte Sub-CA lässt sich nicht zuverlässig allein am Zertifikatsnamen erkennen. Öffnen Sie die Zertifikatsdetails und kontrollieren Sie die Ausstellerinformationen. Vergleichen Sie diese mit den von Apple veröffentlichten Erkennungs- und Austauschhinweisen. Wenn CI-Aufträge Zertifikate automatisch auswählen, prüfen Sie auch, welche Identität der tatsächliche Build-Prozess verwendet: Eine korrekt benannte Identität im Schlüsselbund beweist noch nicht, dass das CI-Dienstkonto auf sie zugreifen kann.

Wie lässt sich die alte Sub-CA bei Developer ID Application und Installer erkennen?

Prüfen Sie zuerst die Zertifikatsdetails der beiden Typen getrennt und dokumentieren Sie die angezeigte ausstellende Zertifizierungsstelle. Gleichen Sie das Ergebnis anschließend mit Apples Anleitung zum Austausch von Developer-ID-Zertifikaten ab. Verlassen Sie sich nicht auf den Anzeigenamen im Schlüsselbund, denn dieser sagt für sich allein nicht, welche Sub-CA das Zertifikat ausgestellt hat.

Ergänzen Sie die Prüfung durch einen Abgleich mit den Signierprotokollen. Bei einer Anwendung sollte der Auftrag erkennen lassen, welche Developer-ID-Identität zum Signieren verwendet wurde. Für ein pkg muss der Paket-Signierauftrag separat erfasst werden. Werden beide Artefaktarten in einer gemeinsamen Pipeline erzeugt, teilen Sie die Prüfergebnisse trotzdem nach Zertifikatstyp auf; ein erfolgreicher Anwendungstest sagt noch nichts über die Paketinstallation aus.

Apple hat am 01.10.2026 mitgeteilt, dass die ursprüngliche Developer ID Certification Authority (Sub-CA) am 01.02.2027 abläuft. Von ihr ausgestellte Zertifikate werden nach Apples Ankündigung dann nicht mehr funktionieren; von betroffenen Zertifikaten signierte pkg-Dateien lassen sich ab diesem Zeitpunkt nicht mehr installieren (Apple-Ankündigung). Planen Sie daher die Paketmigration nicht erst für den letzten Release-Zyklus vor diesem Datum.

Was geschieht mit bereits signierten pkg-Dateien?

Behandeln Sie betroffene Installer-Zertifikate als Release-Risiko, auch wenn ein Paket früher erfolgreich signiert oder veröffentlicht wurde. Apple weist ausdrücklich darauf hin, dass ein von einem betroffenen Developer ID Installer signiertes pkg nach dem 01.02.2027 nicht mehr installiert werden kann. Bewerten Sie deshalb nicht nur künftige Builds, sondern auch noch angebotene Installationsdateien, interne Softwareverteilung und Wiederherstellungsabläufe anhand der Apple-Angaben (Erläuterungen zum Zertifikatsaustausch).

Für bereits ausgelieferte Mac-Anwendungen gilt eine andere Grenze: Apple erklärt, dass vorhandene Software, die mit einem betroffenen Zertifikat signiert, notarisiert und mit einem sicheren Zeitstempel versehen wurde, weiterhin funktioniert. Das ist keine pauschale Freigabe für jede alte Anwendung: Die Bedingungen „notarisiert“ und „sicherer Zeitstempel“ müssen für das konkrete Artefakt nachweisbar sein.

Müssen notarisierten Anwendungen mit sicherem Zeitstempel neu signiert werden?

Nicht allein wegen des angekündigten Ablaufs, wenn es sich um eine bereits notarisiert freigegebene Anwendung mit sicherem Zeitstempel handelt. Für künftige Updates verlangt Apple dagegen ein neues Zertifikat und einen sicheren Zeitstempel. Prüfen Sie deshalb, ob die bestehende Freigabekette den Zeitstempel tatsächlich erzeugt und ob die Notarisierung für das Artefakt abgeschlossen ist. Apples Anleitung zur Vorbereitung der macOS-Notarisierung beschreibt den Notarisierungsablauf; verwechseln Sie dessen Ticket nicht mit dem Signierzertifikat oder dem privaten Schlüssel.

Ersatzbeschaffung und Signierumgebung vorbereiten

Beantragen Sie Ersatz erst, wenn klar ist, welcher Typ benötigt wird und welches Team die Ausstellung verwalten darf. Apples Anleitung zum Erstellen von Developer-ID-Zertifikaten und die Austauschhilfe sind die maßgeblichen Stellen, um Rollen, Voraussetzungen und den aktuellen Ablauf im Developer-Konto zu prüfen. Übernehmen Sie keine alten internen Notizen ungeprüft: Werkzeuganforderungen, Kontoberechtigungen und geltende Beschränkungen können sich ändern.

Der Ersatz muss zum jeweiligen Artefakt passen. Für die signierte Anwendung ist Developer ID Application zu prüfen, für das Installationspaket Developer ID Installer. Kontrollieren Sie nach der Ausstellung, dass die Ausstellerangabe der vorgesehenen G2 Sub-CA entspricht, bevor Sie das Zertifikat als produktionsbereit markieren. Die Erzeugung des privaten Schlüssels und dessen Ablage gehören in den freigegebenen Prozess des Teams; geben Sie Schlüsselmaterial nicht in Build-Protokollen, Artefaktarchiven oder allgemein zugänglichen Variablen aus.

Für die spätere CI-Nutzung sind drei Dinge getrennt nachzuweisen: Das Zertifikat ist vorhanden, der dazugehörige private Schlüssel ist im vorgesehenen Schlüsselbund verfügbar und das CI-Dienstkonto kann die Signieridentität tatsächlich verwenden. Testen Sie die Berechtigungen unter derselben Konto- und Ausführungsbedingung wie im späteren Release-Auftrag. Ein manuell erfolgreicher Lauf mit einem administrativen Benutzer ersetzt diesen Nachweis nicht.

Die Zeitangaben und Wirkungsgrenzen in der Tabelle beruhen auf Apples Ankündigung zum Ablauf der alten Sub-CA. Die Tabelle ersetzt nicht die Prüfung der einzelnen Zertifikatsdetails oder CI-Protokolle.

Parallele Tests auf einer isolierten Mac-CI-Umgebung

Führen Sie die ersten Tests außerhalb der produktiven Signieraufträge aus. Verwenden Sie eine getrennte Pipeline oder einen isolierten Mac-Knoten, sodass ein fehlgeschlagener Signierlauf weder ein Release-Artefakt überschreibt noch die Produktionsidentität versehentlich weiterverwendet. Dokumentieren Sie dabei nicht nur das Ergebnis, sondern auch Knoten, Dienstkonto, Schlüsselbund, verwendete Identität und Protokolle.

Wie lässt sich der Austausch parallel prüfen?

Arbeiten Sie die Prüfungen getrennt nach Anwendung und Installer ab:

1. Testumfang festlegen: Bestimmen Sie je einen repräsentativen Anwendungsauftrag und einen Paketauftrag. Erfassen Sie, welche Artefakte und Veröffentlichungswege damit abgedeckt werden.
2. Ersatzidentitäten einrichten: Installieren Sie die passenden Ersatz-Zertifikate in der freigegebenen Testumgebung. Halten Sie fest, welchem privaten Schlüssel und welchem Team sie zugeordnet sind.
3. Zugriff des CI-Dienstkontos prüfen: Starten Sie die Signieraufträge unter den vorgesehenen CI-Bedingungen. Kontrollieren Sie, dass die richtige Identität auswählbar ist und nicht unbemerkt auf ein altes Zertifikat zurückgegriffen wird.
4. Anwendung validieren: Signieren Sie die Anwendung, führen Sie den vorgesehenen Notarisierungs- und Verteilungsablauf durch und sichern Sie Signier- und Notarisierungsprotokolle. Apples Hinweise zur Behebung häufiger Notarisierungsprobleme sind nützlich, wenn Einreichung oder Verarbeitung scheitern.
5. pkg separat validieren: Signieren Sie ein Paket mit der Installer-Identität und prüfen Sie Signatur sowie Installation in der für Releases vorgesehenen Testumgebung. Eine erfolgreiche Notarisierung einer Anwendung belegt nicht die korrekte Installer-Signatur.
6. Ergebnisse nachvollziehbar ablegen: Bewahren Sie die relevanten Build- und Prüfprotokolle zusammen mit Artefaktkennung, Testknoten und verantwortlicher Person gemäß den internen Aufbewahrungsregeln auf.

Eine einzelne erfolgreiche Ausführung ist noch keine Produktionsfreigabe. Wiederholen Sie die kritischen Aufträge unter den Bedingungen, die im späteren Betrieb gelten, und prüfen Sie insbesondere, ob die Pipeline Zertifikate explizit auswählt oder eine mehrdeutige Auswahl aus dem Schlüsselbund zulässt. Stimmen Konfiguration und beobachtetes Verhalten nicht überein, stoppen Sie die Umstellung, statt einen erfolgreichen manuellen Test als Ersatznachweis zu verwenden.

Entscheiden Sie anhand dieser Bedingungen:

• Wenn Aussteller, Zertifikatstyp und Teamzuordnung eindeutig belegt sind, dann kann das passende Ersatz-Zertifikat in der isolierten Umgebung getestet werden. Andernfalls bleibt der Auftrag gesperrt, bis die Zuordnung geklärt ist.
• Wenn das CI-Dienstkonto die richtige Identität verwenden kann und Anwendungs- sowie pkg-Prüfung getrennt bestanden sind, dann kann der Auftrag für eine gestaffelte Produktionsumstellung vorgeschlagen werden. Andernfalls bleiben Test und Produktionssignierung getrennt.
• Wenn die Anwendung nachweislich notarisiert und mit sicherem Zeitstempel versehen ist, dann entspricht ihre Weiterverwendung der von Apple beschriebenen Grenze. Wenn dieser Nachweis fehlt, dann wird das Artefakt nicht aufgrund einer allgemeinen Annahme als unbetroffen freigegeben.
• Wenn ein Release von einem betroffenen Installer-Zertifikat abhängt, dann muss der Paketpfad vor dem 01.02.2027 auf das Ersatz-Zertifikat umgestellt und geprüft sein. Andernfalls ist die Veröffentlichung nach Apples Ankündigung nicht als installierbar einzuplanen.

Produktionsumstellung und Rückfallbedingungen

Nach abgeschlossener Testphase ändern Sie nicht pauschal alle Mac-CI-Aufträge gleichzeitig. Erstellen Sie eine Liste der betroffenen Pipelines, der zu ändernden Identitäten, der verantwortlichen Teams und der vorgesehenen Release-Fenster. Beginnen Sie mit einem klar begrenzten Auftrag, prüfen Sie dessen Protokolle und erweitern Sie die Umstellung erst, wenn die Nachweise vollständig sind.

Als Freigabebedingungen sollten mindestens gelten:

• Die verwendete Zertifizierungsstelle wurde anhand der Zertifikatsdetails geprüft.
• Anwendungs- und Installer-Aufträge nutzen jeweils den dafür vorgesehenen Zertifikatstyp.
• Das CI-Dienstkonto kann die neue Signieridentität verwenden.
• Die Signierung, Notarisierung und Verteilung der Anwendung wurden anhand des vorgesehenen Ablaufs geprüft.
• Das pkg wurde separat signiert und seine Installation getestet.
• Build- und Prüfprotokolle ermöglichen eine nachträgliche Zuordnung zu Auftrag und Artefakt.
• Der Verwendungsumfang alter Zertifikate ist dokumentiert; keine ungeprüfte Pipeline bleibt als Nebenweg aktiv.

Definieren Sie den Rückfall vor dem ersten Produktionslauf. Ein Rückfall darf beispielsweise bedeuten, die Veröffentlichung anzuhalten, den Auftrag auf eine geprüfte Konfiguration zurückzusetzen oder die Freigabe zu verschieben. Er darf nicht bedeuten, ein abgelaufenes oder betroffenen Sub-CA zugeordnetes Zertifikat als dauerhafte Ersatzlösung weiterzuverwenden. Bewahren Sie die bisherige Pipeline-Konfiguration nur im Rahmen der internen Sicherheits- und Aufbewahrungsregeln auf und verhindern Sie, dass sie unbeabsichtigt wieder für neue Signaturen aktiviert wird.

Nach der Umstellung braucht es einen Abschlussabgleich: Welche Aufträge wurden migriert, welche alten Identitäten sind noch vorhanden, und gibt es archivierte oder manuell gestartete Release-Wege? Stimmen Sie die Antworten mit den Teamverantwortlichen ab. Erst wenn offene Altpfade entweder geprüft, deaktiviert oder mit einem verantwortlichen Termin versehen sind, ist die Migration nachvollziehbar abgeschlossen.

Freigabenachweise und passende Mac-Umgebung

Fassen Sie die Zertifikatsinventur, die Ausstellerprüfung, die Anwendungs- und pkg-Testergebnisse sowie die Produktionsänderungen in einer Freigabeakte zusammen. Halten Sie fest, wer die Prüfung vorgenommen hat, welche Konfiguration getestet wurde und welche Einschränkungen noch bestehen. So lässt sich im nächsten Release unterscheiden, ob ein Fehler aus der Signierung, der Notarisierung, dem Schlüsselzugriff oder dem Installationspaket stammt.

Für temporäre Tests oder eine getrennte Release-Umgebung kann ein gemieteter Remote-Mac eine Alternative zum Kauf zusätzlicher Hardware sein. Ein eigener Knoten bindet Kapital und verlangt interne Wartung, Aktualisierung und Wiederherstellungsplanung; eine allgemeine Nicht-Mac-Umgebung ersetzt den macOS-Signierlauf nicht. Eine Remote-Mac-Umgebung kann diese Aufgaben nur dann sinnvoll ergänzen, wenn Zugriff, Schlüsselverwaltung, Datenschutzanforderungen und CI-Ablauf zur eigenen Freigabepolitik passen. Bei dauerhafter, planbarer Hochlast oder benötigten physischen Schnittstellen kann eigene Hardware geeigneter sein.

Prüfen Sie die tatsächlich angebotenen Bedingungen, bevor Sie eine Umgebung in den Release-Prozess aufnehmen. Informationen zu RUVCLOUD und den ausgewiesenen Mietoptionen finden Sie auf der RUVCLOUD-Übersicht und der Preisseite. Entscheidend bleibt ein eigener Abnahmetest: Ein Mietangebot ersetzt weder die Prüfung der Zertifikatskette noch den Nachweis, dass der konkrete CI-Dienst sicher signieren und veröffentlichen kann.