Developer-ID-Zertifikat läuft 2027 ab? Migrations-Checkliste 2026

Bei der Migration gewinnt die getrennte Prüfung von Zertifikatskette und Release-Artefakt: Prüfen Sie zuerst, ob das Developer-ID-Zertifikat vom auslaufenden alten Sub-CA stammt. Signierte .pkg-Dateien mit einem betroffenen Zertifikat müssen vor dem Stichtag mit einer neuen Identität neu signiert und geprüft werden. Eine bereits signierte, notarierte und mit sicherem Zeitstempel versehene Mac-App muss allein wegen dieses Ablaufs dagegen nicht neu signiert werden. Das gilt für Teams, die ihre tatsächlichen Zertifikats- und Paketdaten im Entwicklerkonto nachvollziehen können.

Geeignet für Entwickler, die macOS-Apps außerhalb des App Store verteilen und kommende Updates vorbereiten.
Ebenso relevant für Teams, die .pkg-Installer oder eine lokale beziehungsweise entfernte Veröffentlichungsumgebung betreiben.
Wer keine Developer-ID-Signierung nutzt, muss diese Migration nicht auf seine Releases übertragen.

Zuletzt aktualisiert am 02.10.2026; geprüft anhand der Apple-Mitteilung vom 01.10.2026 und der offiziellen Zertifikatsdokumentation. Apple nennt den 01.02.2027 als Ablaufdatum des alten Developer-ID-Sub-CA. Die konkrete Betroffenheit muss dennoch anhand der Zertifikatsaufzeichnung des jeweiligen Entwicklerkontos geprüft werden.

Zertifikatskette statt pauschalem Austausch

Nicht jedes Developer-ID-Zertifikat ist automatisch betroffen. Apple zufolge läuft die ursprüngliche Developer ID Certification Authority, das alte Sub-CA, am 01.02.2027 ab; von ihr ausgestellte Zertifikate funktionieren danach nicht mehr. Deshalb ist die ausstellende Stelle entscheidend, nicht allein der sichtbare Name „Developer ID“. Maßgeblich sind Apples Mitteilung zum Sub-CA-Ablauf und der Eintrag des konkreten Zertifikats im Entwicklerkonto.

Eine Prüfung nur des Ablaufdatums kann in die Irre führen. Auch eine lokal vorhandene Identität ist kein Beleg dafür, dass der Produktions-Build bereits die neue Zertifikatskette verwendet. Ein Team sollte deshalb mindestens drei Nachweise zusammenführen: den Zertifikatseintrag im Konto, die Signieridentität im tatsächlich genutzten Schlüsselbund und die Signatur des ausgelieferten Artefakts.

Für die Prüfung des Ausstellerzertifikats sind die Apple-Hinweise zum Developer-ID-Zwischenzertifikat relevant. Apples Dokumentation zu Code-Signing-Zertifikaten beschreibt ergänzend, wie Zertifikate und ihre Vertrauenskette einzuordnen sind. Die Kontodaten bleiben für die konkrete Entscheidung maßgeblich.

Mac-App und .pkg mit unterschiedlichen Folgen

Eine Developer-ID-Migration ist keine einheitliche Aufgabe für alle Artefakte. Developer ID Application ist für die Signierung von macOS-Apps vorgesehen. Developer ID Installer signiert Installationspakete. Dass ein App-Bundle und ein .pkg aus demselben Build stammen, macht ihre Folgen beim Ablauf des alten Sub-CA nicht gleich.

Apple grenzt in seiner Erläuterung zu den Auswirkungen von Zertifikaten die Folgen für bestehende Software und Installationspakete ab. Damit lässt sich eine wichtige Fehlannahme vermeiden: Der Zertifikatsablauf bedeutet nicht, dass jede bereits veröffentlichte Mac-App sofort neu signiert oder erneut notarisiert werden muss. Für ein künftiges Update ist dagegen die passende neue Identität einzuplanen. Ob ein bestimmtes Release erneut zu notarisierten Prüfungen eingereicht werden muss, richtet sich nach dem konkreten Veröffentlichungsprozess und nicht allein nach dem Zertifikatswechsel.

Bei .pkg-Dateien ist die Abnahme strenger zu planen. Apple benennt ausdrücklich die Installationswirkung nach dem Stichtag. Prüfen Sie daher nicht nur das aktuelle Build-Verzeichnis. Auch ältere Downloads, Spiegel, Kundendokumentation oder gespeicherte Installer können weiterhin verteilt werden. Wo ein betroffenes Paket noch angeboten wird, braucht es eine Entscheidung: ersetzen, aus dem Download nehmen oder neu signieren und erneut veröffentlichen.

Release-Auswirkungen nach Prüfkriterium

Die folgende Vergleichsmatrix trennt die Entscheidungen nach dem Artefakt und dem Nachweis. Sie ist hilfreicher als ein pauschaler Migrationsplan, weil sie keine unnötige Neusignierung bereits funktionierender App-Versionen voraussetzt.

Developer ID Application und Developer ID Installer dürfen in der Release-Dokumentation nicht unter einem allgemeinen Feld „Developer-ID-Zertifikat“ zusammenfallen. Halten Sie fest, welches Zertifikat die App signiert und welches gegebenenfalls das Installationspaket signiert. Bei Projekten, die beide Verteilungswege anbieten, ist eine getrennte Freigabe erforderlich.

Ebenso sind Zertifikat und privater Schlüssel zwei verschiedene Teile der Signieridentität. Das Zertifikat allein ermöglicht keine reguläre Signierung, wenn der zugehörige private Schlüssel im tatsächlichen Build-Konto fehlt oder nicht zugänglich ist. Der private Schlüssel darf weder in Tickets noch in gemeinsam genutzten Protokollen, Screenshots oder Build-Ausgaben offengelegt werden.

Häufige Fragen zu Auswirkungen und Nachweisen

Betroffene Mac-Apps und alte Signierketten

Eine bereits veröffentlichte Mac-App wird nicht allein deshalb zu einem sofortigen Neusignierungsfall, weil ein älteres Developer-ID-Zwischenzertifikat abläuft. Apples Aussage bezieht sich ausdrücklich auf bereits signierte und notarierte Software mit sicherem Zeitstempel. Für Updates ist die neue Zertifikatsidentität relevant. Die Zuordnung muss anhand des tatsächlich ausgelieferten App-Bundles und seiner Signatur erfolgen, nicht anhand einer allgemeinen Annahme über alle Developer-ID-Apps.

Frist für Installer mit Developer ID Installer

Apple nennt den 01.02.2027 als Stichtag, ab dem mit einem betroffenen Zertifikat signierte .pkg-Dateien nicht mehr installiert werden können. Deshalb sollten Teams zuerst die veröffentlichten Installer erfassen und deren Signierkette nachvollziehen. Ein neu signiertes Paket ist erst dann abgenommen, wenn Signatur und Installation des konkreten Pakets geprüft wurden. Das bloße Erstellen eines Zertifikats belegt noch nicht, dass die Verteilung funktioniert.

Notarisierte App mit sicherem Zeitstempel

Eine bereits signierte, notarierte und mit sicherem Zeitstempel versehene App muss wegen dieses Ablaufs nicht pauschal neu signiert werden. Das ersetzt jedoch keine Prüfung der tatsächlich bereitgestellten App. Stimmen Signieridentität, Zeitstempel oder Notarisierungsnachweis nicht mit der veröffentlichten Version überein, muss der konkrete Fall gesondert bewertet werden. Für neue Releases ist die aktualisierte Signieridentität einzuplanen.

Prüfung des alten Sub-CA

Öffnen Sie im Entwicklerkonto die konkrete Zertifikatsaufzeichnung und gleichen Sie Aussteller sowie Ablaufdatum mit Apples Mitteilung zum alten Sub-CA ab. Prüfen Sie anschließend die vom Build verwendete Signieridentität und ein signiertes Release-Artefakt. Ein ähnlich klingender Zertifikatsname oder ein lokaler Eintrag im Schlüsselbund allein genügt nicht. Dokumentieren Sie, welche Identität die App und gegebenenfalls der Installer tatsächlich verwenden.

Signieridentität auf dem Build-System

Der Abnahmepunkt ist nicht, dass eine neue Identität im Konto erstellt wurde. Entscheidend ist, ob der passende private Schlüssel zusammen mit dem Zertifikat im Konto läuft, das den Release-Build ausführt. Das gilt für eine lokale Maschine ebenso wie für eine entfernte Mac-Build-Umgebung. Unterschiedliche Schlüsselbunde, Benutzerkonten oder Build-Aufgaben können sonst unbemerkt verschiedene Signieridentitäten verwenden.

Mit den macOS-Werkzeugen lässt sich die vorhandene Identität zunächst inventarisieren:

security find-identity -v -p codesigning

Ein beispielhafter, bewusst anonymisierter Eintrag sieht so aus:

[INDEX] [FINGERPRINT] "Developer ID Application: [Organisation] ([Team-ID])"

Der Eintrag zeigt eine verfügbare Codesignatur-Identität im aktuellen Kontext. Er belegt für sich genommen weder, dass ein bestimmtes App-Bundle damit signiert wurde, noch dass der private Schlüssel in jedem Build-Konto verfügbar ist. Prüfen Sie deshalb zusätzlich die konkrete Datei:

codesign --display --verbose=4 "/Pfad/zur/Anwendung.app"

Für ein Installationspaket ist eine separate Signaturprüfung erforderlich:

pkgutil --check-signature "/Pfad/zum/Installer.pkg"

Bei diesen Prüfungen sollten die erwartete Signieridentität und das Ergebnis im Release-Protokoll stehen. Das Protokoll darf keine wiederverwendbaren Zugangsdaten oder privaten Schlüssel enthalten. Für Notarisierungsfragen verweist Apple auf die Dokumentation zur Fehlerbehebung bei der Notarisierung; sie ist eine Ergänzung für konkrete Fehler, aber kein Ersatz für die Abnahme der Signatur und Installation.

Migration nach messbaren Abnahmekriterien

Die Reihenfolge richtet sich nach den benötigten Nachweisen, nicht nach einer abstrakten Migrationszeitachse. So kann ein Team den Status für jede App und jedes Paket belastbar dokumentieren.

1. Release-Artefakte inventarisieren. Erfassen Sie alle noch verteilten Mac-Apps und .pkg-Dateien. Notieren Sie pro Eintrag den Speicherort, den Verteilungskanal und die im Release verwendete Signierart. Nehmen Sie auch ältere, weiterhin erreichbare Downloads auf.

2. Zertifikatskette im Konto abgleichen. Prüfen Sie bei jeder relevanten Identität die ausstellende Stelle und das Ablaufdatum. Ordnen Sie sie anhand von Apples offizieller Mitteilung dem alten oder neuen Sub-CA zu. Falls die Aufzeichnung keine eindeutige Antwort ergibt, treffen Sie keine Annahme aus dem Anzeigenamen; klären Sie die Zertifikatsdaten anhand der offiziellen Dokumentation.

3. Neue Identität und Zwischenzertifikat prüfen. Apples Anleitung zum Erstellen von Developer-ID-Zertifikaten beschreibt den offiziellen Erstellungsprozess. Prüfen Sie dabei, dass die neue Identität der aktuellen Developer ID Certification Authority (G2) zugeordnet ist und welche Zwischenzertifikatsoption für den konkreten Ablauf erforderlich ist. Kompatibilitätseinschränkungen älterer Xcode-Versionen sind anhand der offiziellen Hinweise und des verwendeten Projekts zu verifizieren, nicht durch eine pauschale Annahme.

4. Privaten Schlüssel im echten Build-Kontext prüfen. Kontrollieren Sie die Identität in genau dem Benutzerkonto, das signiert. Bei einer entfernten Maschine ist ein erfolgreicher Test in einem Administratorkonto kein Beleg für den regulären Build-Benutzer. Halten Sie fest, ob die neue Identität samt passendem Schlüssel verfügbar ist, ohne Schlüsselmaterial selbst zu exportieren oder offenzulegen.

5. Mac-App und Installer getrennt neu bauen. Erstellen Sie einen Test-Release für jede betroffene Verteilungsart. Für Apps prüfen Sie die Signatur und den Notarisierungsnachweis des fertigen Bundles. Für .pkg-Dateien prüfen Sie die Paket-Signatur und die Installation des resultierenden Installers. Führen Sie nicht aus der App-Prüfung auf die Paketprüfung über.

6. Verteilung und Rückfalloption kontrollieren. Ersetzen Sie betroffene Pakete an allen Stellen, an denen sie noch angeboten werden. Prüfen Sie Links, Release-Seiten und interne Ablagen. Bewahren Sie eine nachvollziehbare Zuordnung zwischen alter und neuer Signieridentität sowie den freigegebenen Artefakten auf. Wenn ein Installer bis zum Stichtag nicht erfolgreich getestet wurde, sollte er nicht als migriert gelten.

7. Entscheidung mit Belegen dokumentieren. Wählen Sie für jeden Eintrag zwischen „nicht betroffen“, „neue Identität für kommende Updates“, „Installer neu signieren und ersetzen“ oder „Verteilung einstellen“. Verknüpfen Sie jede Entscheidung mit der Zertifikatsaufzeichnung, dem Signaturprüfergebnis und – bei Installern – dem Installationstest. Eine Zertifikatserstellung allein ist kein Release-Nachweis.

Entscheidung nach Artefakt und Veröffentlichungsrisiko

Wenn die Zertifikatsaufzeichnung eine andere als die alte Sub-CA-Kette bestätigt, dann dokumentieren Sie den Nachweis und nehmen das Artefakt nicht allein wegen der allgemeinen Ankündigung in eine Neusignierung auf. Wenn eine Mac-App bereits signiert, notarisiert und mit sicherem Zeitstempel versehen ist, dann bleibt sie nach Apples Aussage nicht allein aufgrund des Ablaufs ein sofortiger Neusignierungsfall; verwenden Sie für das nächste Update die neue Identität. Wenn ein .pkg mit einem betroffenen Developer ID Installer signiert ist, dann planen Sie Neusignierung, Installationstest und Austausch des Downloads vor dem 01.02.2027. Diese Frist und die beschriebenen Auswirkungen sind in Apples Ablaufmitteilung festgehalten.

Die Bestandsaufnahme sollte außerdem nach dem möglichen Ausfall unterscheiden. Eine App, die nur als Direktdownload angeboten wird, hat andere Austauschpunkte als ein Installer, der in mehreren Dokumentationen oder Kundenportalen verlinkt ist. Der relevante Aufwand steckt häufig nicht im Signierbefehl, sondern im Auffinden aller weiterhin erreichbaren Paketkopien und im Nachweis, dass das ersetzte Paket tatsächlich installiert werden kann.

Veröffentlichungsumgebung und nächste Entscheidung

Eine lokale Mac-Umgebung ist meist die naheliegende Wahl, wenn die Signierung dauerhaft auf derselben kontrollierten Maschine stattfinden soll oder physische Schnittstellen benötigt werden. Sie setzt jedoch voraus, dass die Hardware verfügbar bleibt, Speicher und Schlüsselbund gepflegt werden und ein Ausfall nicht gerade den Release blockiert. Ein geteiltes CI-System kann wiederholbare Builds erleichtern, bietet aber nicht automatisch Zugriff auf jeden macOS-spezifischen Zustand oder die für den konkreten Signierablauf erforderliche Kontrolle.

Für ein zeitlich begrenztes Migrationsfenster kann ein gemieteter Mac eine getrennte und kontrollierbare Umgebung bereitstellen. Das ist besonders dann sinnvoll, wenn ein Team neue Signieridentitäten und Installer prüfen möchte, ohne den täglichen Entwicklungsrechner umzubauen. Es ersetzt keine sichere Schlüsselverwaltung und ist nicht automatisch die beste Wahl für dauerhafte, gleichbleibende Hochlast oder Anforderungen an physische Anschlüsse. Vor einer Entscheidung sollten Mietdauer und Arbeitsablauf mit den Mac-Mietpreisen abgeglichen werden.

Wer lokale und entfernte Veröffentlichungswege gegenüberstellt, sollte nicht nur den Gerätepreis vergleichen. Relevant sind auch die Pflege des Build-Kontos, der Zugriff auf private Schlüssel, der Umgang mit Ausfällen und die Wiederholbarkeit des Installationstests. Einen Überblick über die verfügbaren Optionen bietet die Übersicht zu SFTPMAC.

Für den konkreten Ablauf ist die sachliche Entscheidung: alte Zertifikatskette nachweisen, Apps und .pkg getrennt bewerten und jedes Ersatzartefakt mit dem tatsächlichen Build-Konto abnehmen. Wenn für diese Migration eine unabhängige macOS-Umgebung benötigt wird, kann SFTPMAC eine passende zeitlich begrenzte Option sein – vorausgesetzt, Zertifikat, privater Schlüssel und Zugriffsmethode passen zu den Sicherheitsvorgaben des Teams.