Developer-ID-G2-Zertifikat migrieren? Signaturabnahme auf dem Mac 2026

Symptom: Ihre Veröffentlichung nutzt ein Developer-ID-Zertifikat, aber der Aussteller ist nicht dokumentiert.

Schnellster Weg: Prüfen Sie die Zertifikatskette, behandeln Sie Mac-Apps und .pkg getrennt und ersetzen Sie betroffene Zertifikate rechtzeitig durch G2. Betroffene Installationspakete müssen vor dem 01.02.2027 neu signiert werden; bereits notarisierten Apps mit sicherem Zeitstempel droht laut Apple nicht pauschal dieselbe Pflicht.

Dieser Leitfaden hilft Ihnen, wenn:

• Sie als unabhängiger Entwickler eine App außerhalb des Mac App Store verteilen und den Status Ihrer Signatur klären müssen.
• Ihr Mac-Softwareteam .pkg-Installationspakete ausliefert und G2-Wechsel, Neusignierung und Installationsprüfung planen muss.
• Sie als CI/CD-Verantwortlicher Zertifikat, privaten Schlüssel und Signaturaufgabe in einer macOS-Pipeline umstellen.

Zuletzt aktualisiert am 28.10.2026; geprüft anhand von Apples Ankündigung vom 01.10.2026, der Austausch-Anleitung und den Developer-ID-Hilfeseiten. Maßgeblich sind die dort beschriebenen Zertifikats- und Artefaktregeln; vor einer Veröffentlichung sollten Sie erneut prüfen, ob Apple die Angaben zwischenzeitlich geändert hat.

Developer-ID-G2-Zertifikat migrieren: erst den Aussteller, dann das Artefakt bewerten

Entscheiden Sie nicht anhand der Bezeichnung „Developer ID“ oder des Ablaufdatums, ob ein Zertifikat betroffen ist. Apple hat am 01.10.2026 angekündigt, dass die ursprüngliche Developer ID Certification Authority am 01.02.2027 abläuft. Für betroffene Zertifikate und Veröffentlichungen ist daher der Aussteller entscheidend. Apples Ankündigung zum Ablauf der ursprünglichen Zertifizierungsstelle unterscheidet außerdem die Folgen für Apps und Installationspakete.

Diese Unterscheidung ist für die Planung zentral: Eine notarisiert veröffentlichte Mac-App mit sicherem Zeitstempel ist nicht automatisch wie ein .pkg zu behandeln, das mit einem betroffenen Zertifikat signiert wurde. Apple zufolge können solche bereits notarisierten Apps weiterhin funktionieren; betroffene Installationspakete sollen vor dem Stichtag mit einem Ersatz-Zertifikat neu signiert werden. Die Anleitung zum Austausch von Developer-ID-Zertifikaten beschreibt den Zertifikatswechsel. Die Apple-Übersicht zu Developer-ID-Zertifikaten erklärt, welche Zertifikatstypen für die jeweiligen Signaturaufgaben vorgesehen sind.

Die Einstufung ist eine operative Entscheidungshilfe, keine pauschale Aussage über jede historische Signatur. Wenn Sie für ein Artefakt nicht belegen können, welcher Aussteller, welcher Signaturtyp und welcher Notarisierungsstatus vorliegt, führen Sie es bis zur Klärung als ungeprüft.

Wichtig: Der Ablauf der ursprünglichen Zertifizierungsstelle bedeutet nicht, dass jedes Developer-ID-Zertifikat sofort ersetzt werden muss. Die G2-Migration betrifft die jeweils betroffenen Zertifikate und Lieferobjekte. Ein G2-Zertifikat hat außerdem eine eigene Gültigkeitsdauer und muss unabhängig von diesem Stichtag überwacht und bei Bedarf erneuert werden.

Unabhängige Entwickler: Zertifikatsstatus am konkreten Mac prüfen

Für einzelne Entwickler besteht das häufigste Risiko darin, nur den Namen des Zertifikats in den Projekteinstellungen zu lesen. Die sichtbare Bezeichnung beschreibt nicht zuverlässig, über welche Zertifikatskette es ausgestellt wurde. Auch ein scheinbar passendes Ablaufdatum genügt nicht. Prüfen Sie daher den Eintrag im Entwicklerkonto und das tatsächlich importierte Zertifikat auf dem Mac, auf dem signiert wird.

Gehen Sie dabei ohne Änderung an der produktiven Veröffentlichung vor:

1. Öffnen Sie die Zertifikatsübersicht des Entwicklerkontos und notieren Sie die vorhandenen Einträge für Developer ID Application und Developer ID Installer getrennt. Es handelt sich um unterschiedliche Signaturrollen: Die erste ist für Apps bestimmt, die zweite für Installationspakete.
2. Öffnen Sie auf dem Signier-Mac das Schlüsselbund-Verwaltungsprogramm und suchen Sie die verwendeten Developer-ID-Zertifikate. Rufen Sie für jedes Zertifikat die Details auf und kontrollieren Sie Aussteller sowie Zertifikatskette.
3. Vergleichen Sie den Befund mit Apples Anleitung zum Austausch und zu den Developer-ID-Zwischenzertifikaten. Apple erläutert die Kette in seiner Dokumentation zur Developer-ID-Zwischenzertifizierungsstelle.
4. Stellen Sie fest, ob der zugehörige private Schlüssel auf dem tatsächlich verwendeten Signier-Mac verfügbar ist. Ein Zertifikatseintrag allein belegt nicht, dass die Pipeline damit signieren kann.
5. Dokumentieren Sie für jedes ausgelieferte Artefakt den verwendeten Zertifikatstyp, den Aussteller und – bei Apps – den bekannten Zeitstempel- und Notarisierungsstatus.

Wer eine App mit Developer ID Application verteilt, sollte nicht vorsorglich jede veröffentlichte Version neu signieren, bevor der Status des konkreten Zertifikats und Artefakts geklärt ist. Für ein betroffenes .pkg reicht umgekehrt die Feststellung, dass die App selbst weiterhin akzeptiert wird, nicht als Entwarnung. Das Installationspaket ist ein eigenes Distributionsobjekt und benötigt eine eigene Prüfung.

Mac-Softwareteams: App und Installationspaket getrennt abnehmen

Release-Teams sollten ihre Bestandsaufnahme nach dem auszuliefernden Objekt organisieren, nicht nach dem Namen des Projekts. Ein Produkt kann eine App, ein signiertes Installationspaket oder beides enthalten. Ändert sich die Zertifikatskette, muss die Abnahme also erfassen, welche konkrete Datei der Kunde herunterlädt und welche Signatur diese Datei trägt.

Bei einer Mac-App prüfen Sie zunächst, ob die bestehende Version mit sicherem Zeitstempel signiert und notarisiert wurde. Apple beschreibt die Notarisierung als Teil der Distribution für macOS-Software; die Anleitung zur Notarisierung vor der Verteilung erläutert den entsprechenden Ablauf. Die Aussage, dass bestehende notarisierten Apps mit sicherem Zeitstempel weiter funktionieren können, ist kein Freibrief, neue Builds ohne Prüfung freizugeben: Kontrollieren Sie das neue Zertifikat, die Signatur des erzeugten Artefakts und – wenn Ihr Release-Prozess es vorsieht – den Notarisierungsnachweis.

Bei .pkg-Dateien ist die Migration konkreter: Ist das Paket mit einem betroffenen alten Zertifikat signiert, planen Sie den Ersatz durch ein passendes Developer ID Installer-Zertifikat und eine neue Signatur vor dem 01.02.2027 ein. Eine erfolgreiche Signierung des enthaltenen App-Bundles beweist nicht, dass auch das Paket korrekt signiert wurde. Testen Sie die installierte Anwendung, nicht nur den Build-Log oder den Signaturdialog.

Für die Release-Abnahme eignet sich diese Reihenfolge:

1. Artefakte erfassen: Listen Sie alle tatsächlich verteilten Apps, .pkg-Dateien und gegebenenfalls weitere signierte Bestandteile auf. Vermerken Sie, welche davon externe Nutzer installieren.
2. Zertifikate zuordnen: Ordnen Sie Developer ID Application den Apps und Developer ID Installer den Paketen zu. Halten Sie Aussteller und privaten Schlüssel für den jeweiligen Build-Kontext fest.
3. Ersatz-Zertifikat beschaffen: Folgen Sie Apples Austausch-Anleitung und prüfen Sie, dass Zertifikat und privater Schlüssel im vorgesehenen Signierumfeld zusammen verfügbar sind.
4. Isoliert neu signieren: Erzeugen Sie zunächst eine Testveröffentlichung mit dem neuen Zertifikat, ohne die produktive Pipeline oder den bestehenden Release-Kanal gleichzeitig umzustellen.
5. Notarisierung bedarfsgerecht prüfen: Wenden Sie den für das Artefakt vorgesehenen Apple-Prozess an. Bei Fehlern orientieren Sie sich an Apples Dokumentation zur Behebung häufiger Notarisierungsprobleme und ändern nicht blind mehrere Signaturparameter auf einmal.
6. Installation testen: Prüfen Sie das fertige .pkg auf einem geeigneten Test-Mac und verifizieren Sie, dass Installation und Start des installierten Produkts wie erwartet funktionieren.
7. Freigabe dokumentieren: Archivieren Sie das freigegebene Artefakt, den Zertifikatsbezug und die Ergebnisse der Signatur- und Installationstests nach Ihrer internen Richtlinie.

Das sind keine universellen Apple-Befehle oder eine Garantie für jeden Pakettyp. Die konkreten Signatur- und Notarisierungsschritte hängen von der Bauform Ihres Produkts und dem Release-Prozess ab. Apples Hinweise zu anpassbaren Notarisierungsabläufen helfen, den Ablauf an die eigene Verteilung anzupassen. Bei Zertifikatsfehlern liefert Apples Technote zu Code-Signing-Zertifikaten und Zeitstempeln zusätzliche Einordnung.

Abnahmehinweis: Ein erfolgreicher CI-Job ist kein ausreichender Installationsnachweis. Für die Freigabe zählt das tatsächlich verteilte Artefakt. Bewahren Sie deshalb Testergebnis und Artefaktversion so auf, dass das Team später nachvollziehen kann, welche Signatur zur geprüften Datei gehörte.

Häufige Fragen zur G2-Migration

Wie lässt sich der Aussteller zuverlässig feststellen?
Prüfen Sie den Zertifikatseintrag im Entwicklerkonto und die Zertifikatsdetails im Schlüsselbund. Maßgeblich ist die Aussteller- beziehungsweise Zertifikatsketteninformation, nicht allein der sichtbare Name oder das Ablaufdatum. Vergleichen Sie den Befund mit Apples Anleitung zum Austausch der Developer-ID-Zertifikate. Wenn Kontoansicht und Schlüsselbund voneinander abweichen, klären Sie zuerst, welches Zertifikat samt privatem Schlüssel tatsächlich für den Build verfügbar ist.

Woran erkennt man G2 gegenüber einem älteren Zertifikat?
Verlassen Sie sich nicht auf eine vermutete Namenskonvention. Prüfen Sie die Ausstellerangaben und die Kette des konkreten Zertifikats in den Zertifikatsdetails und gleichen Sie sie mit Apples Informationen zur Developer-ID-Zwischenzertifizierungsstelle ab. Ein ähnlicher Anzeigename oder ein späteres Ablaufdatum beweist für sich genommen nicht, dass das Zertifikat zur neuen G2-Kette gehört.

Was ist bei betroffenen .pkg-Dateien nach dem Stichtag zu beachten?
Apple weist Anbieter an, betroffene Installationspakete vor dem 01.02.2027 mit einem Ersatz-Zertifikat neu zu signieren. Verlassen Sie sich daher nicht auf eine unveränderte alte Signatur für spätere Veröffentlichungen. Prüfen Sie Aussteller und Pakettyp, erstellen Sie ein neu signiertes Testartefakt und testen Sie die Installation auf einem Zielsystem, bevor Sie den produktiven Release-Kanal umstellen.

Müssen Apps und Pakete nach dem Wechsel beide neu signiert werden?
Nicht pauschal. Bereits notarisierten Mac-Apps mit sicherem Zeitstempel können laut Apple weiter funktionieren. Für betroffene .pkg-Dateien ist vor dem Stichtag eine neue Signatur erforderlich. Diese unterschiedliche Behandlung ist der Grund, warum die Inventarliste nach konkreten Distributionsartefakten aufgebaut sein sollte und nicht nur nach Produkt- oder Repository-Namen.

CI/CD-Verantwortliche: neue Identität isoliert in die Pipeline übernehmen

Eine Zertifikatsmigration scheitert in CI häufig nicht am ausgestellten Zertifikat, sondern an einer veralteten Referenz im Buildprozess: Ein Job wählt weiterhin die alte Identität, nutzt einen anderen Schlüsselbund als erwartet oder verwendet ein Zertifikat ohne passenden privaten Schlüssel. Prüfen Sie deshalb Konfiguration und Laufzeitumgebung getrennt. Apples Dokumentation zu Zertifikaten, Signierung und Notarisierung sollte die Grundlage für konkrete Befehle bilden; dieser Leitfaden ersetzt keine auf den eigenen Runner zugeschnittene Apple-Anleitung.

Vor der Änderung der produktiven Pipeline sollten Sie folgende Punkte klären:

• Welche Runner oder Build-Macs signieren derzeit tatsächlich Veröffentlichungsartefakte?
• Verweist die Signaturkonfiguration auf eine Identität, die dem betroffenen alten Aussteller zugeordnet ist?
• Sind Zertifikat und privater Schlüssel im vorgesehenen Schlüsselbund verfügbar, und ist die Referenz in der Pipeline eindeutig?
• Werden Apps und .pkg-Dateien getrennt behandelt, oder wird für beide versehentlich dieselbe Annahme über die Signatur gemacht?
• Sind Notarisierungszugangsdaten und Zertifikatsmaterial nach der internen Sicherheitsrichtlinie geschützt und außerhalb von Quellcode sowie Build-Protokollen gehalten?

Diese Fragen sind keine Aussage, dass eine bestimmte Schlüsselbund- oder Geheimnisverwaltung für jede Organisation vorgeschrieben wäre. Sie legen offen, welche Abhängigkeiten vor der Umstellung überprüft werden müssen. Apple erklärt in der Dokumentation zu Zertifikaten und Code-Signing-Zeitstempeln, wie Zertifikate und Zeitstempel in die Signaturprüfung eingehen. Verwenden Sie für die konkreten Vorgänge ausschließlich die für Ihre macOS- und Xcode-Umgebung passende Apple-Dokumentation.

Führen Sie die Umstellung in einer isolierten Veröffentlichungsaufgabe durch. Signieren Sie zunächst eine nicht produktive Version, kontrollieren Sie danach das Signaturergebnis und testen Sie die Installation. Bei Apps prüfen Sie zusätzlich den für die Veröffentlichung vorgesehenen Notarisierungsstatus; bei Paketen kontrollieren Sie insbesondere die äußere .pkg-Signatur. Erst wenn die Artefakte die Abnahme bestehen, aktualisieren Sie die offizielle Pipeline und deren dokumentierte Rollback-Bedingung.

Für die Verantwortlichkeit empfiehlt sich eine klare Übergabe: Die Person, die Zertifikate verwaltet, bestätigt Aussteller und Schlüsselverfügbarkeit; die Release-Verantwortlichen bestätigen Artefakt und Testinstallation; die CI/CD-Verantwortlichen bestätigen, dass die Pipeline die neue Identität tatsächlich verwendet. Bei einem fehlerhaften Test bleibt die produktive Konfiguration zunächst unverändert. So verhindern Sie, dass ein teilweise aktualisierter Job einen Release erzeugt, dessen Signaturstatus später nicht mehr nachvollziehbar ist.

Teams, die auf einem gemeinsam genutzten Mac testen, sollten zusätzlich Berechtigungen, Zugriff auf private Schlüssel, Protokollierung und Datenaufbewahrung prüfen. Für personenbezogene oder vertrauliche Build-Daten gehört die DSGVO-Bewertung zur Auswahl des Betriebsmodells. Wenn ein extern bereitgestellter Mac Teil der Testkette ist, lesen Sie vor dem Transfer vertraulicher Daten die Datenschutzhinweise von ArmMacs und gleichen Sie diese mit den eigenen Anforderungen ab; daraus folgt keine pauschale Aussage über Ihre Compliance.

Entscheidung und nächste Schritte für die Veröffentlichung

Nutzen Sie vor der Umstellung diese ausführbare Abnahmeliste. Lassen Sie einen Punkt offen, wenn der Nachweis fehlt, statt den Status aus einer Zertifikatsbezeichnung abzuleiten.

• [ ] Alle Developer-ID-Zertifikate aus Entwicklerkonto und Signierumgebung erfasst.
• [ ] Aussteller und Zertifikatskette jedes tatsächlich genutzten Zertifikats geprüft.
• [ ] Developer ID Application und Developer ID Installer den passenden Artefakten zugeordnet.
• [ ] Apps und .pkg-Dateien als getrennte Distributionsobjekte inventarisiert.
• [ ] Für bestehende Apps Zeitstempel und Notarisierungsstatus geprüft, statt pauschal eine Neusignierung anzunehmen.
• [ ] Betroffene Installationspakete für eine Neusignierung vor dem 01.02.2027 eingeplant.
• [ ] Ersatz-Zertifikat samt privatem Schlüssel in einer isolierten Aufgabe getestet.
• [ ] Neue App beziehungsweise neues Paket auf dem fertigen Artefakt geprüft und die Installation nachvollzogen.
• [ ] Verantwortliche, Freigabekriterium und Rückfall auf die letzte geprüfte Veröffentlichung festgelegt.
• [ ] Ablaufdatum des G2-Zertifikats unabhängig vom Termin der alten Zertifizierungsstelle in die Erneuerungsplanung aufgenommen.

Wenn Sie noch keine geeignete macOS-Umgebung für eine isolierte Signatur- und Installationsprüfung haben, vergleichen Sie zuerst den tatsächlichen Bedarf: Ein vorhandener lokaler Mac kann für seltene Releases ausreichen, ist aber bei parallelen Builds oder gemeinsam genutzten Schlüsseln organisatorisch begrenzt. Eine Linux-Buildmaschine ersetzt die erforderliche macOS-Signaturumgebung nicht; zugleich bringen externe Umgebungen zusätzliche Fragen zu Netzwerkzugriff, Schlüsselverwahrung, Datenschutz und stabiler Verfügbarkeit mit sich. Für einen zeitlich begrenzten Migrationstest kann ein gemieteter Mac eine Alternative zum sofortigen Hardwarekauf sein, sofern Ihre Sicherheitsvorgaben den Einsatz zulassen.

Planen Sie daher zunächst die Zertifikatsprüfung und den Test mit echten Distributionsartefakten; wählen Sie die Umgebung erst danach nach Laufzeit, Zugriffsschutz und Verantwortlichkeit aus. Informationen zu verfügbaren Mac-Mietplänen von ArmMacs können bei der Prüfung eines temporären Testsystems helfen. Für Fragen zur Eignung eines solchen Systems für den eigenen Ablauf finden Sie außerdem den Mac-Support von ArmMacs. Die endgültige Freigabe sollte jedoch weiterhin auf Ihrer eigenen Zertifikatsprüfung und einer reproduzierbaren Installation des neu signierten Artefakts beruhen.

Häufig gestellte Fragen