DEVELOPER-ID-G2-ZERTIFIKAT ABGELAUFEN
Wie nehmen Sie Mac CI ab? 2026

Frist: Apple nennt den 01.02.2027 als Ablaufdatum der bisherigen Developer ID Certification Authority (Sub-CA) und weist darauf hin, dass betroffene Zertifikate danach nicht mehr funktionieren (Apple-Mitteilung zur G2-Umstellung). Schnellste sichere Maßnahme: Prüfen Sie zuerst den Issuer jedes in Ihrer Mac-CI verwendeten Zertifikats. Ersetzen Sie betroffene Zertifikate durch passende, von der Developer ID Certification Authority (G2) ausgestellte Zertifikate und nehmen Sie Signierung und Notarisierung in einem isolierten CI-Lauf ab. Signierte Installer-Pakete brauchen eine gesonderte Prüfung; bereits notarisierten Mac-Apps mit sicherem Zeitstempel müssen Sie laut Apple nicht allein wegen dieses Ablaufs neu signieren.

Dieser Ablauf ist für Sie relevant, wenn Sie Developer-ID-Signaturen, Verteilung und Notarisierung von macOS-Software betreuen. Als DevOps-Verantwortliche oder DevOps-Verantwortlicher sollten Sie auch Schlüsselbund, CI-Ausführungskonto und Zertifikatsreferenzen prüfen. Veröffentlichen Sie Apps oder .pkg-Installer, brauchen Sie getrennte Abnahmekriterien für beide Artefaktarten.

Zuletzt geprüft am 07.11.2026. Die Frist und die Abgrenzung der betroffenen Produkte wurden anhand der Apple-Mitteilung sowie der aktuellen Apple-Dokumentation zu Zertifikatsersatz und Developer ID abgeglichen.

1. Auswirkung nach Artefakt und Zertifikat einordnen

Die Frist betrifft nicht automatisch jede macOS-Veröffentlichung in Ihrer Pipeline. Entscheidend sind der Aussteller des eingesetzten Zertifikats, dessen Zweck und das ausgelieferte Artefakt. Apple unterscheidet zwischen Developer ID Application zum Signieren von Apps und Developer ID Installer zum Signieren von Installationspaketen. Ein Zertifikat des einen Typs ersetzt das andere nicht.

Bevor Sie Aufgaben an Teams verteilen, trennen Sie deshalb diese drei Fragen:

• Ist die verwendete Identität von der bisherigen Sub-CA oder bereits von G2 ausgestellt?
• Signieren Sie eine App, ein Installer-Paket oder beides?
• Ist eine vorhandene App bereits notarisiert und mit einem sicheren Zeitstempel versehen?

Für Installationspakete ist die Frist handlungsrelevant: Pakete, die mit einem betroffenen alten Developer-ID-Installer-Zertifikat signiert wurden, müssen vor dem 01.02.2027 mit einem geeigneten Zertifikat neu signiert werden. Planen Sie die erneute Veröffentlichung nicht erst zum Stichtag; sie umfasst auch einen vollständigen Test des Installations- und Verteilungswegs. Apple grenzt dies in der [Mitteilung zum Ablauf der bisherigen Sub-CA](https://developer.apple.com/news/?id=w4atic4c) von bereits notarisierten Apps mit sicherem Zeitstempel ab.

Müssen bereits notarisierten Mac-Apps wegen des Ablaufs neu signiert werden? Nicht allein deshalb. Apple erklärt, dass bereits notarisierten Apps mit sicherem Zeitstempel der Ablauf der bisherigen Sub-CA nicht automatisch eine erneute Signierung abverlangt. Prüfen Sie dennoch den tatsächlichen Signatur- und Notarisierungsstatus Ihres ausgelieferten Builds, statt eine allgemeine Aussage auf jedes Artefakt oder jede Pipeline zu übertragen. Apps, die künftig neu gebaut oder veröffentlicht werden, sollten Sie im Rahmen der Umstellung mit einer gültigen G2-Identität testen.

**Achtung:** „Das Zertifikat läuft vor dem Stichtag ab“ ist ein nützlicher Suchhinweis, aber kein Beleg, dass eine Identität betroffen ist. Maßgeblich ist der Issuer des Zertifikats. Halten Sie deshalb Aussteller, Verwendungszweck und Ablaufdatum in Ihrer Inventarliste getrennt fest.

2. Zertifikatsbestand in der Pipeline ermitteln

Erfassen Sie die Zertifikate nicht nur im Entwicklerkonto. In einer realen Mac-CI-Umgebung kann eine alte Identität noch in einem Schlüsselbund, einer Build-Konfiguration, einer geheimen CI-Variable oder einem Wartungsskript referenziert sein, auch wenn das Portal bereits ein neues Zertifikat anzeigt.

Gehen Sie für jede produktive und für Veröffentlichungen vorgesehene Pipeline so vor:

1. Identitäten im Entwicklerkonto erfassen. Öffnen Sie „Certificates, Identifiers & Profiles“ und listen Sie Developer ID Application sowie Developer ID Installer getrennt auf. Notieren Sie Zertifikatsstatus, Verwendungszweck und Aussteller. Apple beschreibt die verfügbaren Zertifikatstypen in der Developer-ID-Zertifikatsübersicht.
2. Pipeline-Referenzen aufnehmen. Suchen Sie in Build-Skripten, Projektkonfigurationen und CI-Geheimnissen nach Identitätsnamen, Team- beziehungsweise Zertifikatsreferenzen und importierten Zertifikatsdateien. Notieren Sie auch, welches Ausführungskonto den Schlüsselbund entsperrt und auf die Identität zugreift.
3. Auf dem CI-Mac installierte Identitäten prüfen. Führen Sie die Inventarisierung in derselben Benutzerumgebung aus, die später signieren soll. security find-identity -v -p codesigning zeigt verfügbare Code-Signing-Identitäten; vergleichen Sie das Ergebnis mit der im Build ausdrücklich ausgewählten Identität.
4. Issuer am Zertifikat verifizieren. Exportieren Sie das konkrete Zertifikat aus dem verwendeten Schlüsselbund und prüfen Sie Aussteller, Betreff und Gültigkeitsdaten, beispielsweise mit openssl x509 -inform DER -in certificate.cer -noout -issuer -subject -dates. Stimmen Exportformat oder Dateiendung nicht mit dem tatsächlichen Zertifikatsformat überein, passen Sie den Aufruf an, statt einen fehlgeschlagenen Befehl als fehlendes Zertifikat zu interpretieren.
5. Ergebnis mit Artefakt und Workflow verbinden. Dokumentieren Sie, ob die Identität eine App, ein .pkg oder beides signiert und wo Notarisierung und anschließende Verteilung stattfinden.

**Wie stellen Sie fest, von welcher Sub-CA das Mac-CI-Zertifikat stammt?** Prüfen Sie den Issuer des Zertifikats, das der konkrete Build tatsächlich verwendet, und gleichen Sie ihn mit der Identität im Entwicklerkonto ab. Der Anzeigename allein reicht nicht: Ein Zertifikat kann in mehreren Schlüsselbünden oder CI-Variablen unter ähnlichen Bezeichnungen auftauchen. Apples [Code-Signing-Prüfanleitung](https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html) erläutert Prüfungen an signierten Codeobjekten; für die Umstellungsentscheidung ergänzen Sie diese Prüfung um den Issuer des Zertifikats selbst.

Diese Zuordnung ist auch für die Fehlersuche wichtig. Findet die Pipeline mehrere passende Identitäten, kann ein lokaler Test unbemerkt eine andere Identität auswählen als der automatisierte Release-Job. Prüfen Sie daher nicht nur, ob der Zertifikatsname vorhanden ist, sondern ob der Build mit genau der vorgesehenen Identität signiert wurde. Bewahren Sie die Inventarliste zusammen mit Pipeline- und Artefaktkennung auf, damit sich eine spätere Freigabe nachvollziehen lässt.

3. G2-Ersatz nach Verwendungszweck vorbereiten

Erstellen Sie für jeden benötigten Zweck das passende Zertifikat. Eine App-Signatur braucht Developer ID Application; ein signiertes Installationspaket braucht Developer ID Installer. Wenn Ihre Auslieferung beide Artefakte umfasst, planen und prüfen Sie beide Identitäten separat. Verwenden Sie nicht einfach das zuerst verfügbare G2-Zertifikat für alle Signierschritte.

Orientieren Sie sich bei Erstellung und Ersetzung an Apples Anleitung zum Ersetzen von Developer-ID-Zertifikaten. Wählen Sie dort den passenden Zertifikatstyp und kontrollieren Sie, dass die Ersatzausstellung über G2 erfolgt. Apple kann Anleitungen und Portalabläufe aktualisieren; übernehmen Sie daher keine alten Screenshots oder nicht mehr geprüften Klickpfade aus internen Runbooks, ohne sie mit der aktuellen Dokumentation abzugleichen.

Prüfen Sie vor dem Import in die CI-Umgebung:

• Zertifikat und privaten Schlüssel: Der Build-Agent benötigt eine zusammengehörige Identität. Ein Zertifikat ohne zugehörigen privaten Schlüssel kann in der Identitätsliste sichtbar sein, aber nicht wie erwartet zum Signieren verfügbar sein.
• Schlüsselbund und Zugriff: Legen Sie fest, in welchem Schlüsselbund die Identität für den tatsächlichen CI-Benutzer liegt und wie der Job darauf zugreift. Testen Sie die Freigabe nicht nur in einer interaktiven Sitzung mit Ihrem persönlichen Konto.
• Geheimnisübergabe: Klären Sie, wer Zertifikat und privaten Schlüssel bereitstellt, wer sie in die CI-Geheimnisverwaltung einträgt und wer den Import kontrolliert. Beschränken Sie die Verteilung auf die benötigten Rollen und halten Sie fest, welche produktiven Jobs auf die neue Identität umgestellt wurden.
• Werkzeugversionen: Prüfen Sie aktuelle Apple-Hinweise zur Kompatibilität Ihrer Xcode- und Signierumgebung. Wenn ein älterer Build-Agent oder eine ältere Xcode-Version beteiligt ist, behandeln Sie deren Unterstützung als offene Prüffrage, bis sie mit der geltenden Apple-Dokumentation und einem CI-Test bestätigt ist.

Die G2-Erstellung ist damit nicht abgeschlossen, wenn das Portal ein Zertifikat anzeigt. Sie müssen sicherstellen, dass das ausführende Konto auf die zugehörige Identität zugreifen kann, die Signierkonfiguration den richtigen Zertifikatstyp auswählt und weder ein altes Importpaket noch ein veralteter CI-Secret den Job weiterhin auf die bisherige Sub-CA lenkt.

4. Isolierten Mac-CI-Probelauf durchführen

Führen Sie den ersten G2-Test in einem isolierten Job oder einer nicht produktiven Pipeline aus. Verwenden Sie dabei dasselbe Ausführungskonto, denselben Schlüsselbundzugriff und dieselben relevanten Build-Einstellungen wie im Release-Prozess. Eine manuelle Signierung aus einer Administratorsitzung belegt nicht, dass der automatisierte Job die Identität verwenden kann.

Ein Remote Mac kann für diesen Probelauf eine Alternative sein, wenn Ihrem Team aktuell keine geeignete Mac-Umgebung für Signatur- und Notarisierungstests zur Verfügung steht. Prüfen Sie die Möglichkeiten einer Remote-Mac-Umgebung von MACGPU anhand Ihrer Anforderungen. Klären Sie vor dem Transfer von Zertifikaten und privaten Schlüsseln selbst, welche Sicherheits- und Zugriffsvorgaben Ihr Unternehmen erfüllen muss; aus einer verfügbaren Mac-Umgebung folgt keine Zusage zu Zertifikatsverwaltung oder Schlüsselverwahrung.

Welche Schritte gehören in die G2-Abnahme der Mac-CI? Behandeln Sie Signierung, Notarisierung und Ergebnisprüfung als getrennte Nachweise. Ein grüner Signierschritt belegt weder eine erfolgreiche Notarisierung noch, dass das veröffentlichte Artefakt dem geprüften Build entspricht.

1. Bauen Sie ein repräsentatives Release-Artefakt mit der vorgesehenen G2-Identität.
2. Prüfen Sie die Identität im Jobprotokoll und kontrollieren Sie anschließend die Signatur des erzeugten Artefakts. Bei Apps können Sie beispielsweise codesign --verify --strict --verbose=2 App.app verwenden und die ausgegebene Identitätskette dokumentieren. Apple beschreibt die Prüfung von Code-Signaturen in seiner Code-Signing-Dokumentation.
3. Übermitteln Sie die für die Veröffentlichung vorgesehene App beziehungsweise das vorgesehene Paket mit dem in Ihrer Pipeline verwendeten Notarisierungsablauf. Für automatisierte Abläufe verweist Apple auf die Dokumentation zum Anpassen der Notarisierung.
4. Erfassen Sie die Notarisierungsantwort und prüfen Sie den Abschlussstatus mit dem dafür vorgesehenen Prozess. Eine erfolgreiche Übermittlung ist noch kein positiver Notarisierungsnachweis.
5. Prüfen Sie das aus der Pipeline stammende Artefakt erneut, einschließlich Signatur und gegebenenfalls angeheftetem Notarisierungsticket. Apple erläutert den Ablauf für die Notarisierung von macOS-Software vor der Verteilung.
6. Archivieren Sie Build-Referenz, ausgewählte Identität, relevante Protokolle, Notarisierungsergebnis und Artefaktprüfungen gemeinsam. Entfernen Sie dabei keine Informationen, die für eine spätere Freigabeprüfung nötig sind.

Bewerten Sie den Probelauf nach Freigabekriterien statt nach dem Eindruck „hat funktioniert“. Eine belastbare Abnahme erfordert, dass der Job die richtige G2-Identität nutzt, das Ergebnis des Signierschritts verifiziert wird, die Notarisierung erfolgreich abgeschlossen und geprüft ist und die gespeicherte Ausgabe dem freigegebenen Build entspricht. Fehlt einer dieser Nachweise, bleibt die Umstellung offen.

5. Apps und .pkg-Installer getrennt abnehmen

Wählen Sie die Prüfungen passend zum Auslieferungsformat. Wenn eine Pipeline eine App in ein .pkg einbettet, brauchen Sie sowohl den Nachweis zur App-Signatur als auch den zum Installer-Paket. Ein bestandener App-Test deckt die Paketidentität nicht ab.

Für eine App kontrollieren Sie die tatsächlich ausgelieferte Signatur und die Notarisierung. Verifizieren Sie, ob der sichere Zeitstempel vorhanden ist, und ordnen Sie das Ergebnis dem passenden Release-Artefakt zu. Der Apple-Hinweis, dass eine bereits notarisierten App mit sicherem Zeitstempel nicht allein wegen des Ablaufs neu signiert werden muss, ist kein Ersatz für die Prüfung neu gebauter Releases oder nachträglich veränderter Artefakte.

Für ein .pkg prüfen Sie dagegen den Signierer des Pakets und die erwartete Installer-Identität. pkgutil --check-signature Paket.pkg ist ein geeigneter erster Prüfpunkt für den Signaturstatus; vergleichen Sie die angezeigte Identität mit dem vorgesehenen Developer ID Installer-Zertifikat. Prüfen Sie außerdem, dass das zu verteilende Paket tatsächlich der neu signierten Ausgabe entspricht und dass nach der Signierung keine Änderungen am Paket vorgenommen wurden. Die Apple-Informationen zu Developer ID beschreiben den Einsatz der Developer-ID-Signierung bei der Verteilung außerhalb des App Store.

<

Auswahl	Wesentliche Abnahmepunkte	Bewertung für die Umstellung
Bestehende Identität ungeprüft weiterverwenden	Issuer unbekannt; CI-Job nicht eindeutig einer Identität zugeordnet	**Nicht freigeben:** Sie können die Betroffenheit nicht belastbar beurteilen.
G2 nur lokal manuell testen	Lokale Signierung möglich; Zugriff des CI-Ausführungskontos, Notarisierung und Artefaktkette offen	**Nur Vorprüfung:** Noch keine CI-Abnahme.
G2 im isolierten CI-Job testen	Passender Zertifikatstyp; Signierung, Notarisierung und Artefaktprüfung protokolliert	**Freigabefähig, wenn alle Nachweise bestehen.**
Produktiv umstellen und alten Pfad entfernen	G2-Prüfung bestanden; Release-Paket geprüft; Rückfallweg dokumentiert	**Zielzustand:** Erst nach erfolgreicher Freigabe ausrollen.

Die Bewertung in der Tabelle ist eine qualitative Freigabehilfe, keine Messung von Leistung oder Ausfallwahrscheinlichkeit. Ihr tatsächlicher Abnahmestatus hängt davon ab, ob alle für Ihr Release-Format erforderlichen Nachweise vorhanden sind. Eine bloß erfolgreiche lokale Codesignatur erfüllt diese Bedingung nicht.

6. Produktivumstellung und Fristenkontrolle abschließen

Rollen Sie die Änderung erst nach bestandenem isoliertem Test in die produktiven Mac-CI-Knoten aus. Aktualisieren Sie Identitätsreferenzen gezielt und halten Sie einen kontrollierten Rückfallpfad bereit, der nicht versehentlich wieder einen betroffenen alten Installer-Signer für neue Pakete auswählt. Ein Rückfallpfad darf die Prüfung nicht umgehen: Er soll eine Veröffentlichung stoppen oder auf einen freigegebenen Build zurückführen, nicht unbemerkt mit einer ungeprüften Identität weiterarbeiten.

Arbeiten Sie die Umstellung in dieser Reihenfolge ab:

1. Aktualisieren Sie den nicht produktiven Job und dokumentieren Sie dessen vollständige Signier- und Notarisierungsnachweise.
2. Übertragen Sie die freigegebene Zertifikatsreferenz auf einen einzelnen produktiven CI-Knoten beziehungsweise einen begrenzten Release-Pfad.
3. Erzeugen und prüfen Sie ein reales Release-Artefakt aus diesem Pfad; vergleichen Sie Identität, Signatur, Notarisierung und Paketinhalt mit der Abnahme.
4. Erweitern Sie die Umstellung auf die übrigen relevanten Jobs und Knoten, nachdem deren Schlüsselbundzugriff und Signierauswahl geprüft wurden.
5. Ergänzen Sie das Runbook um Issuer, Zertifikatstyp, verantwortliche Rolle, betroffene Pipeline, Frist und Ablageort der Abnahmenachweise.
6. Prüfen Sie die Zertifikatsverwaltung erneut vor der Veröffentlichung, insbesondere wenn Apple seine Hinweise zum Ersetzen, zur G2-Ausstellung oder zur Behandlung vorhandener Artefakte aktualisiert.

**Was ist mit betroffenen Developer-ID-Installer-Paketen zu tun?** Identifizieren Sie jedes ausgelieferte .pkg, das mit einem Zertifikat der bisherigen Sub-CA signiert wurde, und planen Sie dessen Ersatz durch ein mit einer passenden G2-Developer-ID-Installer-Identität signiertes Paket vor dem 01.02.2027. Signieren Sie nicht nur das aktuelle Build-Verzeichnis neu: Verifizieren Sie die tatsächlich verteilte Datei und aktualisieren Sie alle Download- oder Veröffentlichungsstellen, die noch auf das alte Paket verweisen.

Zum Abschluss lohnt ein sachlicher Vergleich Ihrer bisherigen Mac-CI mit einer temporär verfügbaren Mac-Umgebung. Ein lokaler Mac kann bei dauerhaftem, kontrolliertem Release-Betrieb sinnvoll sein, bindet aber Hardware und Wartung an Ihr Team; ein gemeinsam genutzter oder für andere Aufgaben genutzter Rechner kann außerdem durch Benutzerwechsel und Schlüsselbundkontext zusätzliche Prüfungen erfordern. Eine gemietete Remote-Mac-Umgebung erspart den Hardwarekauf für einen zeitlich begrenzten Abnahmelauf, bringt dafür aber Abhängigkeiten von Remote-Zugriff, Netzverbindung und Ihrer eigenen Prüfung der Schlüsselübergabe mit sich. Für dauerhaft hohe Auslastung, besondere physische Schnittstellen oder strikte interne Vorgaben zur Schlüsselverwahrung ist eine eigene, vollständig kontrollierte Infrastruktur möglicherweise die passendere Wahl.

Wenn Ihnen für die G2-Umstellung nur vorübergehend eine geeignete Mac-CI-Testumgebung fehlt, können Sie die Mac-Angebote von MACGPU für einen zeitlich begrenzten Probelauf prüfen. Entscheiden Sie anhand Ihrer Sicherheitsvorgaben und der benötigten Zugriffsform; die Zertifikatsprüfung, Schlüsselverwaltung und Freigabe bleiben Aufgaben Ihres Teams.