Was tun, wenn ein Apple Developer-Zertifikat abläuft? iOS-Veröffentlichung 2026 reparieren

Das Archive lässt sich nicht signieren, obwohl der Upload gestern noch funktioniert hat.

Schnellster Weg: Prüfen Sie zuerst, ob das Apple Developer-Zertifikat abgelaufen oder widerrufen ist, ob das Provisioning Profile dazu passt und ob der tatsächlich verwendete Build-Mac den passenden privaten Schlüssel besitzt. Aktualisieren Sie nur die betroffene Ressource und bestätigen Sie die Reparatur mit einem neuen Archive.

Für wen dieser Ablauf gedacht ist:
Für unabhängige Entwickler, die ein Update veröffentlichen wollen und plötzlich keine gültige Signatur mehr erhalten.
Für kleine Teams, die Zertifikat und Profile erneuert haben, aber den Build-Rechner noch nicht überprüft haben.
Für Verantwortliche eines Remote-Builds, bei dem die lokale Signierung funktioniert und der automatisierte Build weiterhin scheitert.

Apple Developer-Zertifikat abgelaufen: Fehlerbild und Ursache

Ein allgemeiner Signierfehler bezeichnet nicht automatisch ein abgelaufenes Zertifikat. Derselbe fehlgeschlagene Build kann durch ein widerrufenes Zertifikat, ein abgelaufenes Provisioning Profile, einen fehlenden privaten Schlüssel, falsche Build-Einstellungen oder einen abgelaufenen Entwicklerstatus entstehen. Behandeln Sie diese Fälle getrennt: Prüfen Sie den konkreten Status im Entwicklerkonto, die ausgewählte Signieridentität in Xcode und den Fehler im Protokoll des fehlgeschlagenen Builds.

Apple unterscheidet Zertifikatstypen nach ihrem Zweck. Apple Development wird für Entwicklung und Tests verwendet, Apple Distribution für die Verteilung von Apps. Developer ID ist wiederum für die Verteilung außerhalb des App Store vorgesehen. Ein Fehler bei einem Typ lässt sich nicht ohne Prüfung auf einen anderen übertragen. Die offizielle Apple-Übersicht zu Zertifikaten und deren Verwendungszweck ist die Referenz, wenn die Identität im Build-Protokoll nicht eindeutig zuzuordnen ist.

Wichtig ist auch die Trennung zwischen Ablauf und Widerruf. Ein abgelaufenes Zertifikat hat sein Gültigkeitsende erreicht; ein widerrufenes Zertifikat wurde aktiv ungültig gemacht. Die Ursachen und Folgen sind nicht identisch. Apple dokumentiert Widerruf und Zertifikatsberechtigungen separat in den Hinweisen zu widerrufenen Zertifikaten und Berechtigungen. Leiten Sie daher aus der Meldung „Ungültige Signatur“ nicht direkt ab, dass Sie sämtliche Zertifikate löschen und neu erstellen müssen.

Bei einem abgelaufenen Apple Distribution-Zertifikat ist die zentrale Frage, ob Sie ein neues Build signieren und hochladen können. Der Ablauf bedeutet nicht automatisch, dass eine bereits veröffentlichte App sofort ungültig wird. Apple behandelt den Status einer App-Verteilung und die Gültigkeit eines Zertifikats als getrennte Sachverhalte; prüfen Sie den konkreten Fall in der Apple-Zertifikatsübersicht. Übertragen Sie diese Aussage nicht auf widerrufene Zertifikate, Entwickler-Builds oder einen abgelaufenen Mitgliedsstatus.

Fehlerhinweise im Vergleich

Ordnen Sie die Beobachtung der wahrscheinlich betroffenen Ressource zu, bevor Sie Änderungen vornehmen. Die folgende Bewertung beschreibt den praktischen Beweiswert eines Hinweises: „stark“ bedeutet, dass Sie eine konkrete Ressource gezielt prüfen können; „mittel“ bedeutet, dass noch eine zweite Ursache möglich ist.

Die Tabelle ist ein Diagnosewegweiser, kein Ersatz für den Status im Entwicklerkonto. Ein fehlendes Zertifikat auf einem Mac beweist zum Beispiel nicht, dass es abgelaufen ist; der zugehörige private Schlüssel kann dort schlicht nicht installiert oder für den ausführenden Benutzer nicht zugänglich sein.

Wiederherstellung in einer kontrollierten Reihenfolge

Gehen Sie den Fehler so durch, dass jede Änderung eine konkrete Beobachtung adressiert. Damit vermeiden Sie, ein funktionierendes Zertifikat unnötig zu ersetzen oder eine zweite, unabhängige Fehlerquelle zu erzeugen.

1. Den fehlgeschlagenen Vorgang eindeutig festhalten. Notieren Sie, ob der Fehler beim Build, beim Erstellen des Archive, beim Export oder beim Upload auftritt. Prüfen Sie das Protokoll des fehlgeschlagenen Vorgangs und halten Sie Scheme, Target, Exportmethode sowie die dort genannte Signieridentität fest. Ein Build-Fehler vor der Signierung verlangt eine andere Untersuchung als ein erfolgreicher Build mit fehlgeschlagenem Export.

2. Den Zertifikatstyp und dessen Status im Entwicklerkonto prüfen. Öffnen Sie den Bereich für Zertifikate und suchen Sie gezielt nach der Identität, die der Build tatsächlich verwendet. Vergleichen Sie den Typ mit dem beabsichtigten Vorgang: Entwicklung, App-Store-Verteilung oder Verteilung außerhalb des App Store. Prüfen Sie, ob das Zertifikat abgelaufen, widerrufen oder noch gültig ist. Wenn die Account-Anzeige auf Mitgliedschaft oder Berechtigungen verweist, wechseln Sie nicht vorschnell zur Zertifikatserneuerung.

3. Mitgliedschaft und Teamzugriff separat verifizieren. Ein gültiges Zertifikat beantwortet nicht die Frage, ob das verwendete Team und der ausführende Benutzer die nötigen Rechte besitzen. Prüfen Sie, ob der Build im erwarteten Entwicklerteam ausgeführt wird und ob das Konto Zugriff auf die relevante Ressource hat. Apple erläutert den Mitgliedschaftsstatus und die Verlängerung in der offiziellen Anleitung zur Mitgliedschaftsverlängerung. Zeigt die Prüfung ein Problem mit Mitgliedschaft oder Berechtigung, lösen Sie dieses zuerst und erzeugen Sie nicht auf Verdacht weitere Zertifikate.

4. Die Verknüpfung zwischen Zertifikat und Provisioning Profile kontrollieren. Öffnen Sie das für den Build verwendete Profil und vergleichen Sie dessen App-ID, die benötigten Fähigkeiten sowie die zugelassenen Zertifikate mit der aktuellen Release-Konfiguration. Ein Profil, das noch ein altes Zertifikat referenziert, wird durch das bloße Erstellen eines neuen Zertifikats nicht automatisch passend. Bei manuell verwalteten Profilen kann eine Bearbeitung oder Neuerstellung mit anschließendem Download erforderlich sein. Apple beschreibt diese Schritte unter Profil bearbeiten, herunterladen oder löschen und erklärt in den Hinweisen zu Profilaktualisierungen, wann Aktualisierungen relevant sind.

5. Die Signieridentität samt privatem Schlüssel auf dem Ziel-Mac prüfen. Ein Zertifikatseintrag im Entwicklerkonto allein reicht für die Signierung nicht. Der Mac, der das Archive erzeugt, benötigt die dazugehörige Signieridentität mit zugänglichem privaten Schlüssel. Öffnen Sie auf genau diesem Mac die Schlüsselbundverwaltung und prüfen Sie, ob Zertifikat und Schlüssel als zusammengehörige Identität verfügbar sind. Wenn ein Zertifikat angezeigt wird, aber kein passender privater Schlüssel vorhanden ist, können Sie die Identität dort nicht wie erwartet zum Signieren verwenden. Apple beschreibt die Verwaltung gemeinsamer Team-Signierzertifikate in der Dokumentation zu Team-Signierzertifikaten.

6. Die tatsächlichen Xcode-Signiereinstellungen abgleichen. Prüfen Sie Team, Signing Certificate, Provisioning Profile und die Einstellungen des ausgewählten Targets. Bei automatisch verwalteter Signierung kontrollieren Sie, ob Xcode im richtigen Team arbeitet und die erwartete Ressource verwenden kann. Bei manuell verwalteter Signierung muss das konfigurierte Profil zum Zertifikat und zur App-ID passen. Suchen Sie außerdem nach abweichenden Einstellungen in Build-Konfigurationen oder Schemes: Eine funktionierende Debug-Konfiguration beweist nicht, dass die Release-Konfiguration dieselbe Signieridentität nutzt.

7. Einen neuen Archive- und Exportvorgang als Abnahme durchführen. Erstellen Sie ein frisches Archive mit der vorgesehenen Release-Konfiguration. Prüfen Sie die Signieridentität und das Profil des Ergebnisses; danach exportieren Sie es mit der vorgesehenen Distributionsmethode. Erst wenn der Export die erwartete App-Datei erstellt und der Upload die erwartete Rückmeldung liefert, ist die gesamte Kette überprüft. Ein grüner Build ohne erfolgreiches Archive oder ein erfolgreiches Archive ohne passenden Export bestätigt die Veröffentlichung noch nicht.

Profil, Schlüsselbund und Build-Mac als getrennte Fehlerquellen

Wenn das Zertifikat erneuert wurde, untersuchen Sie nicht nur das Entwicklerkonto. Der zentrale Unterschied lautet: Das Konto verwaltet die Signierressourcen, aber der Build muss diese Ressourcen auf dem ausführenden Mac tatsächlich verwenden können. Ein vorhandener Account-Eintrag sagt weder aus, dass der private Schlüssel verfügbar ist, noch dass ein lokales oder entferntes Profil auf die neue Identität verweist.

Bei einer manuell verwalteten Konfiguration prüfen Sie zuerst das Profil, das im fehlgeschlagenen Build tatsächlich ausgewählt wurde. Laden Sie nicht einfach irgendein neues Profil herunter: Es muss für die passende App-ID und den vorgesehenen Verteilungsweg erstellt oder aktualisiert sein. Vergleichen Sie dessen Inhalt mit dem Zertifikat, das die Release-Konfiguration verwendet. Wenn Sie die Profilverwaltung an Xcode delegieren, prüfen Sie stattdessen die Team- und Signiereinstellungen, die Xcode beim Archive verwendet. Die beiden Wege unterscheiden sich darin, wer die Ressourcen auswählt und aktualisiert; sie sollten nicht innerhalb einer Diagnose unbemerkt vermischt werden.

Ein fehlender privater Schlüssel ist ein anderer Fehler als ein ungültiges öffentliches Zertifikat. Wenn die Schlüsselbundverwaltung auf dem Ziel-Mac keine vollständige Identität zeigt, müssen Sie die Schlüsselbereitstellung für diesen Build-Rechner klären. Behandeln Sie private Schlüssel als vertrauliche Zugangsdaten: Geben Sie sie nicht über ungesicherte Ablagen oder allgemeine Build-Protokolle weiter. Apple beschreibt für Teams, wie Signierzertifikate geteilt und verwaltet werden können; halten Sie sich an diese Zuständigkeiten und Berechtigungen, statt Schlüsselbestände ungeprüft zwischen Konten zu kopieren.

Entscheidungszweige für die nächste Aktion

• Wenn das Zertifikat im Entwicklerkonto als abgelaufen angezeigt wird, dann erneuern oder ersetzen Sie nur die benötigte Zertifikatsart und prüfen Sie anschließend das dazugehörige Profil. Andernfalls lassen Sie das Zertifikat bestehen und untersuchen Sie Widerruf, Schlüsselzugriff oder Einstellungen.
• Wenn das Zertifikat widerrufen ist, dann klären Sie zuerst den Widerrufsgrund und die Auswirkungen auf den konkreten Verteilungsweg. Andernfalls behandeln Sie einen bloßen Ablauf nicht wie einen Widerruf.
• Wenn das Profil ein anderes Zertifikat, eine andere App-ID oder nicht passende Fähigkeiten ausweist, dann aktualisieren oder erstellen Sie das Profil über den dafür vorgesehenen Verwaltungsweg. Andernfalls ändern Sie das Profil nicht auf Verdacht.
• Wenn das lokale Archive gelingt, aber der Remote-Build scheitert, dann prüfen Sie den tatsächlich aufgerufenen Mac, den ausführenden Benutzer und dessen Schlüsselbund. Andernfalls beginnen Sie bei der gemeinsamen Konfiguration und dem Account-Status.
• Wenn Hinweise auf Mitgliedschaft, Teamrechte oder einen Apple-Dienstfehler zeigen, dann stoppen Sie Änderungen an Zertifikaten und lösen Sie zuerst dieses Problem. Andernfalls fahren Sie mit dem Archive- und Exporttest fort.

Remote Mac: Reparatur bis zum ausführenden Prozess verfolgen

Ein lokaler Erfolg ist kein Nachweis für einen erfolgreichen Remote-Build. Finden Sie heraus, welcher Mac tatsächlich vom CI/CD-Auftrag oder Skript angesprochen wird. Prüfen Sie dessen Xcode-Version und Signiereinstellungen, den ausführenden Benutzer, den Schlüsselbundzugriff und den Pfad zum Provisioning Profile. Ein interaktiver Test in Ihrer Sitzung kann erfolgreich sein, während ein automatisierter Prozess unter einem anderen Benutzerkonto läuft und die Identität nicht sieht.

Bei fastlane match prüfen Sie, ob der vorgesehene Build-Rechner nach dem Zertifikatswechsel tatsächlich den erwarteten Stand synchronisiert hat. Prüfen Sie insbesondere, ob der Build die passende Team- und Verteilungskonfiguration erhält und ob das Profil sowie die Signieridentität dort verfügbar sind. Für einen Build, der nur bereits vorhandene Signierressourcen verwenden soll, beachten Sie die in der offiziellen match-Dokumentation beschriebene Nur-Lese-Option. Dieser Prüfschritt bestätigt nicht, dass ein neues Zertifikat korrekt ausgestellt oder ein Profil passend erneuert wurde; er prüft lediglich, was die Build-Umgebung verwendet.

Gleichen Sie die Ausführung mit einem erfolgreichen lokalen Vorgang ab, ohne Geheimnisse in Protokolle zu schreiben. Vergleichen Sie Team-ID, Scheme, Release-Konfiguration, ausgewähltes Profil und die angezeigte Signieridentität. Wenn nur der Remote Mac abweicht, ändern Sie nicht gleichzeitig das lokale Xcode-Projekt und den Account-Bestand. Eine Änderung pro Diagnose verhindert, dass Sie nach einem Erfolg nicht mehr wissen, welcher Schritt den Fehler behoben hat.

Für Teams, die eine externe macOS-Umgebung für wiederkehrende Veröffentlichungen einrichten, lohnt sich auch ein sachlicher Vergleich zwischen physischer und virtualisierter macOS-Infrastruktur. Die Gegenüberstellung von Bare Metal und macOS-Virtualisierung hilft dabei, Ausführungsumgebung und Betriebsmodell von der eigentlichen Signierdiagnose getrennt zu bewerten.

Veröffentlichung abschließen, ohne Zertifikate blind neu zu erstellen

Die Wiederherstellung ist erst abgeschlossen, wenn das Release-Archive den vorgesehenen Verteilungsweg durchläuft. Prüfen Sie die Signieridentität des Archives, die Zuordnung zum Profil und den Export. Kontrollieren Sie anschließend den Upload-Status. Halten Sie dabei fest, welche Ressource geändert wurde und auf welchem Mac der erfolgreiche Vorgang lief. Diese Zuordnung hilft, wenn ein späterer Build wieder unter einem anderen Benutzer oder auf einem anderen Host ausgeführt wird.

Stoppen Sie, wenn die Belege auf Mitgliedschaft, Teamrechte oder einen Apple-Dienstfehler weisen. Wiederholtes Widerrufen und Neuerstellen kann zusätzliche Profile und Signieridentitäten erzeugen, ohne die eigentliche Ursache zu beheben. Klären Sie zuerst, ob der Fehler die Account-Berechtigung, das Profil, den Schlüsselbund oder den Veröffentlichungsdienst betrifft. Erst wenn der Status eine konkrete ungültige Ressource zeigt, ersetzen Sie diese gezielt.

Eine lokale Entwicklungsumgebung ist für gelegentliche Releases oft ausreichend. Wenn sie jedoch auf einem einzelnen Mac liegt, hängen Archive und Upload von dessen Verfügbarkeit, Speicherplatz und Schlüsselbundkonfiguration ab. Für zeitlich begrenzte Veröffentlichungsarbeiten kann ein gemieteter Remote Mac eine zugängliche macOS-Umgebung bereitstellen, ohne dass Sie für einen vorübergehenden Bedarf zusätzliche Hardware kaufen. Für dauerhaft hohe Auslastung oder besondere physische Anschlüsse kann ein eigener Rechner passender sein. Wenn Sie einen Remote-Build erwägen, vergleichen Sie zunächst die Mietkosten für Bare-Metal-macOS mit Ihrem tatsächlichen Nutzungsprofil. MacDate ist eine Option, wenn Sie für eine anstehende Signier- und Veröffentlichungsphase eine remote erreichbare Mac-Umgebung benötigen; die Zertifikatsverwaltung und die sichere Bereitstellung Ihrer Schlüssel bleiben dabei weiterhin Ihre Verantwortung.