Apple-Notarisierung in CI fehlgeschlagen? Leitfaden zur Fehlerbehebung 2026

Ein erfolgreicher Upload ist noch keine Freigabe. Für die Diagnose müssen mindestens vier getrennte Ereignisse auseinandergehalten werden: die Signierung des Artefakts, die Einreichung samt Authentifizierung, die Verarbeitung durch Apples Notarisierungsdienst und die anschließende Ticket-Anheftung beziehungsweise Prüfung des fertigen Pakets. Apples Beschreibung des Notarisierungsverfahrens erläutert, dass die Notarisierung ein automatisierter Prüfschritt vor der Verteilung ist. Sie ist nicht mit einer App-Store-Prüfung gleichzusetzen.

Wenn die CI-Konsole „Upload erfolgreich“ meldet, belegt das zunächst nur, dass die Übertragung in der betreffenden Phase abgeschlossen wurde. Es belegt weder, dass Apple das Paket akzeptiert hat, noch dass ein Ticket am verteilbaren Artefakt angebracht und dieses danach erfolgreich geprüft wurde. Genau hier entsteht häufig ein Fehlalarm: Ein Job prüft lediglich den Upload-Befehl und markiert den Release als erfolgreich, obwohl die abschließende Statusabfrage fehlt.

Die Tabelle ist ein Diagnosemodell, keine Aussage über eine feste Bearbeitungsdauer. Apples Notary-API-Dokumentation beschreibt Statusabfragen und den Abruf von Protokollen anhand der Submission-ID. Ein CI-Job sollte diese Kennung deshalb als Release-Nachweis sichern, nicht nur die letzte Konsolenausgabe.

Was ist nach einer erfolgreichen notarytool-Einreichung mit fehlgeschlagenem Status zu prüfen? Rufen Sie zunächst mit der zugehörigen Submission-ID den Status und, sofern verfügbar, das Notarisierungsprotokoll ab. Bei einer CLI-Konfiguration mit Schlüsselbundprofil sind dafür die Unterbefehle info und log von notarytool vorgesehen; die konkrete Aufrufsyntax muss zur verwendeten Xcode- und Werkzeugversion passen. Ein erneuter Upload ohne Prüfung kann denselben Fehler wiederholen und zusätzlich die Zuordnung zwischen CI-Lauf und Einreichung erschweren.

Ein Zertifikats- oder Berechtigungsfehler bedeutet nicht automatisch, dass der Mac-Knoten defekt ist. Zuerst ist zu unterscheiden, womit das Programm signiert wurde und womit sich der CI-Prozess gegenüber dem Notarisierungsdienst authentifiziert. Die Signatur identifiziert und schützt das zu verteilende Programm; die Zugangsdaten erlauben dem automatisierten Job, eine Einreichung zu veranlassen und deren Ergebnis abzufragen.

Für extern verteilte Mac-Software kommen je nach Artefakt unterschiedliche Developer-ID-Signaturen in Betracht. Ein App-Bundle und ein Installer-Paket sind nicht austauschbar: Wird ein PKG verteilt, müssen Signatur und Paketaufbau zum vorgesehenen Verteilungsweg passen. Apple erläutert die Rolle der Code-Signierungsdienste; die Dokumentation zu häufigen Notarisierungsproblemen ordnet typische Ablehnungen konkreten Eigenschaften der Software zu.

Prüfen Sie bei einem einschlägigen Fehler insbesondere:

• Verwendet der Build die passende Developer-ID-Identität für die Art des auszuliefernden Artefakts?
• Ist die Signatur des endgültigen Pakets gültig, oder wurde nach dem Signieren noch eine Datei verändert?
• Sind Zertifikatskette und zugehöriger privater Schlüssel im Schlüsselbund des tatsächlich ausführenden CI-Kontos verfügbar?
• Ist das für notarytool hinterlegte Profil vorhanden und für den Job lesbar?
• Verwendet der Job einen Zugang für die Einreichung, statt fälschlich ein Signaturzertifikat als Einreicher-Authentifizierung zu behandeln?

Achtung: Ein Schlüsselbund kann in einer interaktiven Sitzung verfügbar sein, während ein nicht interaktiver CI-Dienstprozess keinen Zugriff darauf hat. Prüfen Sie daher den ausführenden Benutzer, den Schlüsselbund-Kontext und die Berechtigungen direkt im Job. Ein lokaler erfolgreicher Test mit einem anderen Benutzer beweist nicht, dass die Pipeline denselben Zugriff besitzt.

Welche Apple-Notarisierungsprotokolle deuten auf ein Signaturproblem hin? Entscheidend ist nicht ein einzelnes Schlagwort in der CI-Ausgabe, sondern der konkrete Befund im offiziellen Protokoll: etwa eine nicht akzeptierte Signatur, ein fehlerhaft signierter Bestandteil oder eine nicht passende Paketstruktur. Vergleichen Sie den gemeldeten Pfad mit dem tatsächlich signierten Release-Artefakt und prüfen Sie die Signatur dort erneut. Apple beschreibt die typischen Ursachen und Prüfbereiche in der Übersicht zur Fehlerbehebung; leiten Sie aus einer allgemeinen Upload- oder Netzwerkfehlermeldung nicht ohne diesen Nachweis einen Zertifikatsfehler ab.

Eine erfolgreiche Signaturprüfung eines Zwischenprodukts reicht nicht aus, wenn nachfolgend ein anderes Paket komprimiert, umbenannt, neu verpackt oder an die Distribution angepasst wird. Maßgeblich ist die Datei, die tatsächlich an Apple übermittelt und später an Anwender verteilt werden soll. Apples Hinweise zum Verpacken von Mac-Software für die Verteilung behandeln den Zusammenhang zwischen Paketierung, Signierung und Verteilung.

Bei einem abgelehnten Artefakt sollte der Bericht deshalb als Prüfliste für die betroffenen Bestandteile dienen. Stimmen die gemeldeten Pfade mit den Inhalten des finalen DMG, ZIP oder PKG überein? Wurden eingebettete Helfer, Frameworks oder Plug-ins mit signiert und nach der Signatur unverändert belassen? Entsprechen die Entitlements dem tatsächlichen Anwendungszweck und der verwendeten Signatur? Ändern Sie nicht vorsorglich sämtliche Entitlements: Eine Änderung kann neue Probleme erzeugen und erschwert den Vergleich mit dem ursprünglich abgelehnten Build.

Die Build-Pipeline sollte außerdem unverwechselbar speichern, welches Artefakt geprüft wurde. Ein häufiger Designfehler ist, dass Signaturprüfung und Notarisierung auf einem Pfad arbeiten, der nach dem Packen nicht mehr dem Pfad des später veröffentlichten Pakets entspricht. Das lässt sich vermeiden, indem der Job den Artefaktnamen und dessen unveränderliche Build-Identität protokolliert und die finale Prüfung ausdrücklich auf dieselbe Datei richtet.

Muss bei fehlgeschlagener macOS-Notarisierung neu signiert, erneut hochgeladen oder das Paket repariert werden? Das hängt von der Phase ab: Weist der Bericht einen Signatur- oder Inhaltsfehler nach, muss das betroffene Artefakt korrigiert und anschließend erneut signiert und eingereicht werden. Ist die Einreichung selbst nicht zustande gekommen, prüfen Sie zuerst Zugangsdaten und Übertragung. Ist sie bereits vorhanden, fragen Sie deren Status ab, bevor Sie erneut senden. Ein blindes Neusignieren behebt weder ein fehlendes CI-Schlüsselbundrecht noch einen Netzwerkfehler.

Wenn eine Einreichung gestartet wurde, aber kein verwertbarer Bericht vorliegt, sollten Submission-ID, Statusantwort, Job-ID und Zeitpunkt der jeweiligen CI-Aktion zusammen aufbewahrt werden. Ohne diese Zuordnung wird es schwierig festzustellen, ob der Job vor der Übertragung, während der Antwortverarbeitung oder erst bei der anschließenden Protokollabfrage endete. Die Notary-API stellt Status- und Protokollinformationen bereit; die Apple-Dokumentation zur Übermittlung über das Web beschreibt, wie diese Informationen zur Einreichung gehören.

Wie lässt sich Mac-CI-Fehlerbehebung von einem Apple-Dienstproblem abgrenzen? Prüfen Sie zuerst, ob die Pipeline eine Submission-ID erhalten hat und ob Statusabfrage oder Protokollabruf scheitern. Wenn Einreichungen grundsätzlich nicht gestartet werden, untersuchen Sie CI-Zugangsdaten, Schlüsselbund und ausgehende Netzwerkverbindungen. Wenn der Job trotz erreichbarer Einreichung keine Status- oder Protokolldaten erhält, prüfen Sie zusätzlich den Dienststatus bei Apple Developer System Status. Dieser Schritt verhindert, dass ein möglicher Dienstzustand vorschnell als Fehler des Artefakts behandelt wird; umgekehrt sollte ein allgemeiner Systemstatus nicht als Beleg für die Annahme einer konkreten Einreichung gelten.

Bei einem erneuten Versuch müssen vorhandene Einreichungen und die gespeicherte Anfragekontextualisierung berücksichtigt werden. Prüfen Sie, ob der vorherige Lauf bereits eine Submission-ID ausgegeben hat und ob sein Status noch abgefragt werden kann. Wird der Kontext beim Übergang zwischen CI-Schritten verworfen, kann ein späterer Job nicht mehr zuverlässig feststellen, welches Ergebnis zu welchem Paket gehört. Das ist ein Pipelineproblem, selbst wenn die Apple-Dienste und der Mac-Knoten ansonsten erreichbar sind.

Ein akzeptierter Notarisierungsstatus und ein erfolgreich verteilbares Artefakt sind verwandte, aber getrennte Prüfpunkte. Für unterstützte Verteilungsformate kann das Notarisierungsticket mit stapler an das fertige Artefakt angeheftet werden. Danach sollte die Pipeline die Anheftung und die finale Datei prüfen; bei einer Anwendung im DMG ist beispielsweise das DMG selbst zu berücksichtigen, während ein Installer-Paket einen anderen Verteilungsweg haben kann. Apples Dokumentation zur Notarisierung beschreibt die Werkzeuge und den Notarisierungsablauf.

In einem automatisierten Ablauf sind xcrun stapler staple und anschließend xcrun stapler validate mögliche Prüfschritte, sofern das gewählte Format und der Verteilungsweg dafür geeignet sind. Die erfolgreichen Ausgaben beider Befehle sollten als Release-Nachweis gespeichert werden. Anschließend ist die Datei zu testen, die tatsächlich aus der Pipeline herausgegeben wird, nicht eine frühere Kopie vor der Ticket-Anheftung. Bei Änderungen nach dem Signieren oder beim Austausch des finalen Pakets muss die Pipeline die Prüfung für das neue Artefakt erneut durchführen.

Ist das Stapling nach einer akzeptierten Notarisierung immer zwingend? Nicht pauschal für jeden denkbaren Verteilungsweg. Ob ein Ticket angeheftet werden soll, hängt vom Artefakt und den Anforderungen an die Verteilung und spätere Prüfung ab. Wenn ein Ticket für die Offline-Prüfung mit dem ausgelieferten Paket verfügbar sein soll, muss der entsprechende Stapling-Schritt erfolgreich sein. Entscheidend ist, dass das Team Akzeptanzstatus, Anheftung und finale Verifikation nicht als einen einzigen CI-Erfolgscode zusammenfasst.

Mit einer Checkliste lässt sich verhindern, dass ein grüner Upload-Job eine unvollständige Freigabe verdeckt. Bewahren Sie Nachweise so auf, dass ein späterer Release-Review den Zusammenhang zwischen Artefakt, Einreichung und Prüfung nachvollziehen kann:

• [ ] Ergebnis der Signaturprüfung für das finale Verteilungsartefakt einschließlich der geprüften Identität.
• [ ] Submission-ID und gespeicherte Statusantwort der Einreichung.
• [ ] Apple-Protokoll oder dokumentierter Grund, weshalb ein Protokoll noch nicht abrufbar war.
• [ ] Ergebnis der Ticket-Anheftung, sofern sie für das gewählte Format und den Verteilungsweg vorgesehen ist.
• [ ] Ausgabe der abschließenden Verifikation des Artefakts, das tatsächlich veröffentlicht wird.
• [ ] Nachweis, welches CI-Konto den Einreichungszugang verwendet hat, ohne geheime Werte in Logs abzulegen.

Das ist besonders wichtig, wenn mehrere Personen oder CI-Dienste denselben Release-Prozess betreuen. Eine Submission-ID ohne Artefaktzuordnung hilft wenig; ein gespeichertes Protokoll ohne Angabe des zugehörigen Builds ebenfalls. Zugänge sollten daher nachvollziehbar den Dienstkonten zugeordnet sein, während private Schlüssel und Authentifizierungsdaten nicht in Klartextausgaben, frei lesbaren Build-Artefakten oder allgemein zugänglichen Protokollen landen.

Bei der Abnahme eines entfernten Mac-Knotens sollte nicht allein dessen Erreichbarkeit zählen. Führen Sie einen kontrollierten Testlauf mit einem repräsentativen Release-Artefakt durch und prüfen Sie dabei Schlüsselbundzugriff, Signatur, Submission-ID, Statusabfrage, Ticket-Anheftung und Endprüfung. Wenn für den Aufbau eines solchen Testumfelds eine temporäre Mac-Umgebung benötigt wird, können Verantwortliche die verfügbaren Mac-Umgebungen von NUKCLOUD als eine mögliche Option prüfen. Für die Beschaffung ist es sinnvoll, die geltenden Vertragsbedingungen vorab zu prüfen; daraus folgt jedoch keine Aussage über eine konkrete CI-Konfiguration oder die Eignung für einen bestimmten Sicherheitsstandard.

Bei einem bereits vorhandenen Fehlerbild hilft die folgende Entscheidungslogik, den nächsten Schritt einzugrenzen:

• Wenn keine Submission-ID vorliegt, prüfen Sie Einreicher-Zugang, Schlüsselbundkontext und Netzwerkübertragung; wiederholen Sie nicht einfach die Signierung.
• Wenn eine Submission-ID vorliegt, aber der Status fehlt, sichern Sie die vorhandene Antwort und prüfen Sie Statusabfrage, Protokollabruf und Dienststatus.
• Wenn der Status nicht akzeptiert ist und das Protokoll einen Inhalt oder eine Signatur beanstandet, korrigieren Sie das betroffene finale Artefakt und starten Sie den Build ab der notwendigen Signatur- und Verpackungsphase neu.
• Wenn Apple die Einreichung akzeptiert hat, aber die Ticket-Prüfung fehlschlägt, kontrollieren Sie Format, Dateipfad und tatsächliches Ergebnis von stapler; behandeln Sie das nicht als erneute Einreichungsablehnung.
• Wenn Signatur, Einreichung, Protokoll und Endprüfung erfolgreich sind, geben Sie nur genau das verifizierte Release-Artefakt frei.

Für Teams, deren Problem nachweislich bei CI-Konto, Schlüsselbund oder Knoten liegt, ist ein kontrollierter Test auf einer geeigneten Mac-Umgebung oft aussagekräftiger als ein weiterer blinder Produktionslauf. Eine gemietete Mac-Umgebung von NUKCLOUD kann für einen zeitlich begrenzten Abnahmetest sinnvoll sein, wenn keine zusätzliche Hardware dauerhaft bereitgestellt werden soll. Sie ersetzt aber weder die Prüfung der eigenen Zugangskontrollen noch die Release-Abnahme; bei dauerhafter, gleichbleibender hoher Auslastung oder benötigten physischen Schnittstellen kann ein eigener Mac die passendere Wahl sein. Entscheidend bleibt, dass Apple-Status, Protokoll, Ticket und finale Verifikation gemeinsam belegen, was tatsächlich veröffentlicht werden darf.