Developer ID G1 läuft ab: Wie migrieren Sie die Signierung von Mac-Installationspaketen? 2026

Ein PKG lässt sich im Testlauf nicht mehr installieren, obwohl der Build erfolgreich war.

Schnellste Lösung: Prüfen Sie zuerst, ob das verwendete Signierzertifikat tatsächlich zur auslaufenden Developer ID Certification Authority (G1) gehört. Ist das der Fall, signieren Sie betroffene PKG-Dateien vor dem Stichtag mit einer korrekt aus G2 ausgestellten Developer ID Installer-Identität neu und testen den Installationsweg. Bereits signierte, notarisierten Apps mit sicherem Zeitstempel sind davon nicht automatisch genauso betroffen wie Installationspakete.

Diese Anleitung richtet sich an macOS-Release-Verantwortliche, die vorhandene Signaturressourcen auf G1 prüfen müssen.
Sie hilft CI/CD-Teams, Zertifikat, privaten Schlüssel, Schlüsselbund und Paketprüfung zusammen zu betrachten.
Auch IT-Verantwortliche, die eine isolierte Mac-Build-Umgebung für die Freigabe planen, finden hier prüfbare Abnahmepunkte.

Zuletzt aktualisiert am 26.10.2026; geprüft anhand der Apple-Mitteilung vom 01.10.2026 und der zugehörigen Zertifikats- und Supportdokumentation.

G1 im Zertifikat erkennen statt nur ein Ablaufdatum lesen

Der kritische Unterschied ist nicht allein, wann ein einzelnes Zertifikat abläuft, sondern von welcher Developer ID Certification Authority es ausgestellt wurde. Apple nennt den 01.02.2027 als Ablaufdatum der ursprünglichen G1-Zertifizierungsstelle. Zertifikate, die von dieser Stelle stammen, können ab diesem Datum nicht mehr zum Signieren verwendet werden; Apples aktuelle Mitteilung legt außerdem ausdrücklich fest, dass betroffene signierte PKG-Dateien dann nicht mehr installierbar sind. (Apples Mitteilung zum Ablauf der Developer ID Certification Authority)

Ein Ablaufdatum am oder vor dem Stichtag ist laut Apple ein Hinweis, beweist für sich genommen aber nicht die ausstellende Stelle. Umgekehrt kann ein irreführend ähnlicher Anzeigename für Zertifikate aus den verschiedenen Sub-CAs auftauchen. Verlassen Sie sich deshalb weder allein auf den Namen im Signierdialog noch auf eine Inventarliste, die nur Ablaufdaten enthält. Die Anleitung zur Identifizierung und Ersetzung betroffener Developer-ID-Zertifikate erläutert die Prüfung des Ausstellers.

So prüfen Sie die Identität konkret:

1. Öffnen Sie in der Schlüsselbundverwaltung das Blattzertifikat, das der Build-Pipeline tatsächlich zum Signieren verwendet.
2. Klappen Sie Issuer Name auf und prüfen Sie Organizational Unit.
3. Ordnet Apple den Eintrag „Apple Certification Authority“ zu, stammt das Zertifikat aus der vorherigen Sub-CA und sollte ersetzt werden. Steht dort „G2“, ist es der aktuellen Sub-CA zugeordnet.
4. Verwechseln Sie das Blattzertifikat nicht mit dem separaten Eintrag der Zertifizierungsstelle im Schlüsselbund. Apple weist darauf hin, dass dieser Eintrag eine andere Bedeutung hat.
5. Halten Sie für die Pipeline fest, welche Zertifikatsidentität einschließlich Ausstellerkette auf dem Build-Knoten verfügbar ist.

Diese Prüfung ist für Developer ID Installer und Developer ID Application relevant. Sie sind nicht austauschbar: Das erste Zertifikat signiert Mac-Installationspakete, das zweite Apps. Apple beschreibt beide Zertifikatstypen getrennt und erklärt, dass für beide Arten jeweils ein passendes Zertifikat benötigt wird. Die Dokumentation zum Erstellen von Developer-ID-Zertifikaten führt diese Trennung auf.

Für ein Team mit mehreren Build-Knoten entsteht hier ein häufig übersehener Betriebsaufwand: Ein Zertifikat, das auf dem Arbeitsplatz eines Release Engineers korrekt aussieht, belegt nicht, dass die CI-Umgebung dieselbe Identität verwendet. Parallele Schlüsselbunde, zwischengespeicherte Signaturressourcen und abweichende Build-Skripte können dazu führen, dass der lokale Kontrolllauf und das veröffentlichte Artefakt nicht dieselbe Kette haben. Das ist kein Beweis für einen Fehler in einem bestimmten Tool, sondern ein Grund, die tatsächlich erzeugte Datei zu prüfen.

PKG, bestehende App und Update getrennt bewerten

Die G1-Frage lässt sich nicht mit einem pauschalen „alles neu signieren“ beantworten. Maßgeblich ist, welches Artefakt verteilt wird und welche Signatur es trägt. Apples Mitteilung unterscheidet explizit zwischen Installer Packages und bereits signierten, notarisierten Mac-Programmen mit sicherem Zeitstempel. Für neue App-Versionen ist die Umstellung wiederum relevant.

Die Unterscheidung ist im Alltag wichtig, weil ein Unternehmen eine notarisierten App häufig in einem PKG ausliefert. Die Tatsache, dass die App selbst nach Apples Aussage weiter funktioniert, macht ein betroffen signiertes Installationspaket nicht automatisch installierbar. Prüfen Sie daher sowohl die App-Signatur als auch die äußere Paketdatei, statt aus einem erfolgreichen App-Test auf den Paketstatus zu schließen.

Auch die allgemeine Zertifikatsdokumentation beschreibt App- und Installer-Verhalten getrennt: Bei einer App ist für die Bewertung unter anderem entscheidend, ob das Zertifikat bei der Erstellung gültig war; ein Installer-Paket wird beim Ausführen anhand der Gültigkeit des Developer ID Installer-Zertifikats bewertet. Für den konkreten G1-Termin hat jedoch Apples aktuelle Mitteilung Vorrang: Betroffene PKG-Dateien können ab dem genannten Stichtag nicht installiert werden. Weitere Einzelheiten zu Zertifikaten und ihren Auswirkungen finden Sie in Apples Übersicht zu Zertifikaten.

Fragen, die vor der Umstellung geklärt sein sollten

Welche PKG-Dateien sind nach dem G1-Ablauf gefährdet?
Nicht jedes alte Paket und nicht jedes Developer-ID-Zertifikat ist automatisch betroffen. Entscheidend ist, ob das PKG mit einem Zertifikat aus der ursprünglichen Developer ID Certification Authority signiert wurde. Prüfen Sie den Aussteller des verwendeten Developer ID Installer-Zertifikats und gleichen Sie ihn mit Apples Identifizierung ab. Für betroffene PKG-Dateien nennt Apple den 01.02.2027 als Termin, ab dem sie nicht mehr installiert werden können.

Wie wird der Aussteller eines Developer ID Installer-Zertifikats geprüft?
Öffnen Sie das Blattzertifikat in der Schlüsselbundverwaltung und kontrollieren Sie im erweiterten Feld Issuer Name die Organizational Unit. Apple ordnet „Apple Certification Authority“ der vorherigen Sub-CA und „G2“ der aktuellen Sub-CA zu. Prüfen Sie gezielt das verwendete Zertifikat und nicht nur den Anzeigenamen einer Identität oder den separaten Zertifizierungsstellen-Eintrag im Schlüsselbund.

Müssen bereits notarisierten Mac-Apps wegen G1 neu signiert werden?
Nein, nicht pauschal: Apple erklärt, dass bereits signierte und notarisierten Mac-Programme mit sicherem Zeitstempel weiter funktionieren. Bei künftig veröffentlichten Updates muss das Team jedoch mit einem neuen passenden Zertifikat signieren und den sicheren Zeitstempel für die Notarisierung berücksichtigen. Ein Installer-Paket bleibt eine eigene Prüfstelle; die App-Ausnahme darf nicht auf die äußere PKG-Datei übertragen werden.

Wie nimmt ein CI-Team den G2-Wechsel für ein PKG ab?
Führen Sie einen repräsentativen Build mit der aktualisierten Signieridentität auf dem vorgesehenen CI-Knoten aus. Prüfen Sie die Paket-Signatur mit pkgutil --check-signature und installieren Sie das Ergebnis anschließend in einer geeigneten Testumgebung. Dokumentieren Sie Identität, Ausstellerkette und Installationsresultat. Die Pipeline gilt nicht als abgenommen, nur weil der Build-Prozess ohne Fehlercode endet.

G2 auswählen, ohne die Zertifikatsmigration zu verfehlen

Beim Erstellen des Ersatzes müssen Sie die passende Zertifikatsart für das jeweilige Artefakt wählen. Ein Ersatz für einen PKG-Workflow braucht Developer ID Installer; für eine App-Signatur ist Developer ID Application vorgesehen. Wenn beide Arten im Release-Prozess vorkommen, planen Sie beide Wechsel ein, denn ein Installer-Zertifikat ersetzt keine App-Signatur und umgekehrt. Apples Anleitung zum Erstellen von Developer-ID-Zertifikaten beschreibt die Auswahl der passenden Art.

Achten Sie bei der Ausstellung darauf, die G2-Sub-CA tatsächlich auszuwählen, wenn die Oberfläche nach dem Developer ID Certificate Intermediary fragt. Apple warnt, dass eine andere Auswahl ebenfalls ein Zertifikat ergeben kann, das 2027 ausläuft. Verwenden Sie Xcode 11.4 oder früher, fordert Apple vor dem Erstellen des neuen Zertifikats ein Update. Diese Versionsgrenze ist eine offizielle Vorgabe für die Ausstellung, kein allgemeiner Beleg dafür, dass jede andere ältere Toolchain zwangsläufig fehlerhaft signiert.

Ein weiteres Detail wirkt sich auf den Betrieb aus: Apple gibt an, dass Zertifikate aus G2 jährlich erneuert werden müssen. Behandeln Sie den Ersatz daher nicht als einmalige Umstellung ohne Folgeaufgabe. Ergänzen Sie im Zertifikatsinventar eine verantwortliche Person, einen Erneuerungsprozess und eine Prüfung, ob die neue Identität in allen relevanten Build-Umgebungen angekommen ist. Die jährlich erforderliche Erneuerung und die Auswahl von G2 sind in Apples Mitteilung sowie der Anleitung zur Ersetzung betroffener Zertifikate dokumentiert.

Für die Signierkette gilt: Bewahren Sie benötigte Zwischenzertifikate solange auf, wie bestehende Signieridentitäten sie benötigen. Apple erklärt in den Hinweisen zu Developer-ID-Zwischenzertifikaten, dass das bisherige Zwischenzertifikat bis zu seinem Ablauf für Inhalte mit den zugehörigen bestehenden Zertifikaten gebraucht wird. Eine Bereinigung des Schlüsselbunds sollte deshalb nicht ungeprüft mit der Ausstellung des G2-Ersatzes zusammengelegt werden.

CI-Abnahme: Die erzeugte Datei ist der Prüfgegenstand

Ein erfolgreicher Build beweist zunächst nur, dass der Build-Prozess ein Artefakt erzeugt hat. Er beweist nicht, dass der CI-Knoten die gewünschte G2-Identität auswählte, dass der private Schlüssel im richtigen Schlüsselbund verfügbar war, dass die Paketdatei korrekt signiert ist oder dass die Installation auf einem Zielsystem funktioniert. Diese Differenz ist besonders relevant, wenn Entwickler lokal und CI mit unterschiedlichen Schlüsselbund-Konfigurationen oder Umgebungsvariablen arbeiten.

Arbeiten Sie die Umstellung in einer kontrollierten Abnahme durch:

1. Artefakte inventarisieren. Erfassen Sie veröffentlichte und in der Pipeline erzeugte Apps, PKG-Dateien sowie weitere Verteilformate. Notieren Sie, welche Signieridentität im jeweiligen Build-Skript oder Exportprozess ausgewählt wird.
2. Zertifikatskette auf dem Build-Knoten prüfen. Kontrollieren Sie Aussteller, Zertifikatstyp und zugehörigen privaten Schlüssel in der tatsächlich vom Job verwendeten Schlüsselbund-Konfiguration. Vergleichen Sie diese Werte mit der dokumentierten G2-Auswahl.
3. Identität pro Artefakt festlegen. Verknüpfen Sie App-Signierung und PKG-Signierung jeweils mit dem passenden Zertifikatstyp. Vermeiden Sie eine Konfiguration, in der die Auswahl lediglich über einen mehrdeutigen Anzeigenamen erfolgt.
4. Repräsentativen Release-Build ausführen. Bauen Sie eine typische App-Version samt dem tatsächlich verteilten Paket. Halten Sie fest, welche Signieridentität der Job verwendet hat und welche Datei als endgültiges Artefakt ausgegeben wurde.
5. Signaturen auslesen und überprüfen. Apple empfiehlt zur Untersuchung einer PKG-Signatur pkgutil --check-signature. Für Apps können codesign und spctl zur Signatur- beziehungsweise Systemrichtlinienprüfung eingesetzt werden; Apples Anleitung zur Behebung häufiger Notarisierungsprobleme beschreibt Prüfwerkzeuge und Auswertung.
6. Installation tatsächlich testen. Installieren Sie die erzeugte PKG-Datei in einer geeigneten, vom Produktionssystem getrennten Testumgebung. Testen Sie die App anschließend entsprechend dem vorgesehenen Release-Ablauf. Ein Prüfbefehl ersetzt diesen Installationsversuch nicht.
7. Nachweis und Rückfall festhalten. Speichern Sie Build-Kennung, Artefakt-Prüfsumme, Zertifikatsidentität, Prüfausgabe und Installationsergebnis in einem zugriffsbeschränkten Freigabenachweis. Private Schlüssel, Zugangsdaten und Geheimnisse gehören nicht in Job-Ausgaben oder Beispielprotokolle.

Für App-Signierung und Notarisierung sind außerdem sichere Zeitstempel zu berücksichtigen. Apples Dokumentation zur Notarisierung von macOS-Software beschreibt den Ablauf und die Bedeutung des sicheren Zeitstempels. Eine Notarisierung der App macht die getrennte PKG-Signaturprüfung nicht überflüssig; ebenso ersetzt ein erfolgreicher PKG-Signaturtest keine Installation auf einem geeigneten Testsystem.

Bewahren Sie Testergebnisse so auf, dass Release- und IT-Verantwortliche sie ohne Offenlegung von Schlüsselmaterial nachvollziehen können. Bei gemeinsam genutzten Build-Umgebungen gehören dazu klar abgegrenzte Schlüsselbund-Zugriffe, dokumentierte Zuständigkeiten und ein Verfahren zum Austausch der Signierressourcen. Weitere technische Beiträge finden Sie in den macOS- und CI/CD-Leitfäden; für den Umgang mit sensiblen Daten in einer Umgebung sind außerdem die Datenschutzhinweise zur Mac-Nutzung relevant.

Wann eine isolierte Mac-Umgebung die Abnahme erleichtert

Eine Freigabe sollte nicht auf einem Entwicklerrechner erfolgen, auf dem unbemerkt eine andere Zertifikatsidentität oder ein abweichender Schlüsselbund aktiv ist. Ein dedizierter Testlauf auf einer kontrollierten Mac-Build-Umgebung trennt die Abnahme vom Produktionsrelease und macht sichtbar, ob die neue Identität mitsamt privatem Schlüssel, Signierkette und Paketinstallation zusammenarbeitet. Dabei müssen Verantwortliche Zugriffsrechte, Geheimnisverwaltung, Aufbewahrung von Artefakten und DSGVO-Anforderungen gesondert prüfen; ein gemieteter Rechner allein ist kein Nachweis für Compliance oder Isolation.

Der Vergleich ist eine Betriebsentscheidung: Ein vorhandener Entwickler-Mac ist sofort verfügbar, kann aber durch lokale Konfigurationen, konkurrierende Nutzung und manuelle Pflege schwer reproduzierbar sein. Ein dauerhaft selbst beschaffter CI-Mac gibt dem Unternehmen die unmittelbare Kontrolle, verursacht jedoch Beschaffungs-, Wartungs- und Erneuerungsaufwand und ist bei einem einmaligen Migrationslauf womöglich länger gebunden als nötig. Eine zeitlich begrenzte Mac-Miete kann für einen isolierten Validierungslauf sinnvoll sein, wenn die Organisation Zugriff, Datenhaltung und erforderliche Werkzeuge vorher geprüft hat; sie ist weniger passend, wenn eine dauerhafte Hochlast-Buildfarm oder physische Schnittstellen zwingend gebraucht werden.

Wenn die bestehende Build-Umgebung sich nur schwer vom Produktionspfad trennen lässt, kann xcodeops als zeitlich begrenzte Mac-Umgebung für einen kontrollierten Testlauf in Betracht kommen. Der Produktumfang und die konkreten Sicherheitsanforderungen sollten vorab geprüft werden; es werden hier keine nicht belegten Leistungs-, Standort- oder Sicherheitszusagen unterstellt. Informationen zur verfügbaren Mac-Umgebung finden Sie auf der Mac-mini-Seite. Entscheidend ist, dass das Team dort denselben G2-Signatur- und Installationsnachweis erbringt, den es auch für einen eigenen CI-Knoten verlangen würde.

Häufig gestellte Fragen