codesign errSecInternalComponent: Remote-Signierung 2026 beheben?

Diese Anleitung richtet sich an unabhängige Entwickler, die nach einer SSH-Anmeldung auf einem Remote-Mac nicht signieren können, obwohl ein grafisches Archive funktioniert. Sie ist ebenso für kleine Teams gedacht, die fastlane, Skripte oder einen selbst gehosteten Runner ohne manuelle Dialoge betreiben.

Auch nach einer Migration der Build-Umgebung bleibt der Ablauf relevant, wenn eine Apple Distribution- oder Developer-ID-Identität zwar sichtbar ist, der eigentliche Signaturvorgang aber scheitert. Apple beschreibt errSecInternalComponent als allgemeinen Fehler im Umfeld der Codesignatur; die Meldung ist deshalb kein Beweis für eine bestimmte Xcode- oder macOS-Version. Die Apple-Unterlagen zur Codesignatur-Fehlersuche sollten zusammen mit dem konkreten Terminalauszug ausgewertet werden.

Der Fehler kann mindestens vier voneinander unabhängige Ursachen haben:

• Der SSH-Prozess läuft zwar unter demselben Namen, verwendet aber einen anderen Login- oder Keychain-Kontext.
• Der Schlüsselbund ist gesperrt, nicht als Standard-Keychain gesetzt oder nach dem Abmelden nicht initialisiert.
• Das Zertifikat ist vorhanden, der zugehörige private Schlüssel fehlt jedoch oder liegt in einem anderen Schlüsselbund.
• Die Identität ist vorhanden, aber die Vertrauenskette, Provisioning-Konfiguration oder Zugriffsfreigabe ist unvollständig.

Gerade deshalb ist ein blindes Löschen riskant: Es kann eine noch funktionierende grafische Umgebung beschädigen, ohne die eigentliche SSH-Ursache zu beseitigen.

Bevor eine Identität gelöscht, ein Schlüsselbund verändert oder ein Zertifikat widerrufen wird, sollte der Fehler reproduzierbar dokumentiert werden. Die folgenden Angaben gehören in einen abgeschirmten Diagnoseeintrag:

• der tatsächliche macOS-Benutzer des Build-Prozesses;
• die Anmeldeart: grafische Sitzung, SSH, Runner oder geplanter Dienst;
• der vollständige Keychain-Pfad;
• der verwendete Bundle Identifier und der Name des Testartefakts;
• die genaue Phase: codesign, xcodebuild archive, Export oder Upload;
• der relevante, von Passwörtern und geheimen Token bereinigte Fehlerauszug.

Zertifikatsnamen, Team-ID, Bundle-ID, Hashes, Dateinamen und Pfade sollten in geteilten Logs durch Platzhalter wie <TEAM_ID>, <BUNDLE_ID>, <KEYCHAIN_PATH> und <SIGNING_IDENTITY> ersetzt werden. Das schützt nicht nur die Signaturumgebung, sondern erleichtert auch eine spätere Prüfung nach DSGVO-Grundsätzen, weil unnötige personenbezogene oder infrastrukturelle Angaben nicht in CI-Protokollen landen.

Ein sinnvoller Minimaltest signiert kein echtes Release-Artefakt, sondern eine kopierte Testdatei:

codesign --force --sign "<SIGNING_IDENTITY>" \
  --keychain "<KEYCHAIN_PATH>" \
  "<TEST_ARTIFACT_PATH>"

Der Befehl muss im Benutzerkontext des späteren Builds ausgeführt werden. sudo kann den sichtbaren Benutzer, die Umgebungsvariablen und den verwendeten Schlüsselbund verändern und ist daher kein neutraler Diagnose-Schritt.

Für die erste Gegenprobe werden drei Dinge konstant gehalten: Benutzer, Signaturidentität und unschädliches Testartefakt. Zuerst wird der minimale Test in einem grafischen Terminal ausgeführt, danach in einer neuen SSH-Sitzung desselben Benutzers.

Die Sitzungen sollten jeweils mindestens diese Informationen protokollieren:

whoami
id
security default-keychain -d user
security list-keychains -d user
security find-identity -v -p codesigning

Die Ausgabe darf keine geheimen Werte enthalten. Entscheidend ist nicht nur, ob security find-identity eine Identität auflistet, sondern ob beide Sitzungen denselben Benutzer, denselben Standard-Keychain und dieselbe Identitätsauswahl sehen.

Die Apple-Dokumentation zu Keychains erklärt den Schlüsselbund als geschützten Speicher für Zertifikate, Schlüssel und weitere Sicherheitsobjekte. Für die Diagnose bedeutet das: Ein sichtbares Zertifikat ist nicht automatisch ein benutzbarer privater Schlüssel.

Eine Codesignaturidentität besteht praktisch nicht nur aus dem sichtbaren Zertifikatsnamen. Für den Signaturvorgang müssen Zertifikat und passender privater Schlüssel zusammen verfügbar sein. Die technische Struktur und die Beziehung der Bestandteile beschreibt Apple in TN3161 zu Codesignaturzertifikaten.

Die Prüfung erfolgt in einer kontrollierten Reihenfolge:

1. Gültige Identitäten auflisten:
   bash security find-identity -v -p codesigning Der Befehl zeigt, welche Identitäten der aktuelle Benutzer für Codesignaturzwecke findet. Er ersetzt jedoch keine Prüfung des privaten Schlüssels.

2. Zertifikatsdetails anzeigen:
   bash security find-certificate -a -c "<CERTIFICATE_NAME>" \ "<KEYCHAIN_PATH>" Der Name ist durch einen Platzhalter zu ersetzen. Bei gleichnamigen Zertifikaten müssen Seriennummer, Ablaufstatus und Team-Zuordnung sorgfältig unterschieden werden.

3. Privaten Schlüssel im Schlüsselbund suchen:
   bash security find-key -a "<KEY_IDENTIFIER>" \ "<KEYCHAIN_PATH>" Falls die konkrete Schlüsselkennung nicht bekannt ist, sollte die Prüfung im Schlüsselbundprogramm des Build-Benutzers erfolgen. Der private Schlüssel darf nicht aus Logs oder Screenshots exportiert werden.

4. Zertifikat und Schlüssel zusammen bewerten:
   Ein Zertifikat ohne passende private Schlüsselkomponente kann zwar in einer Liste erscheinen, aber keine Signatur erzeugen. Ein Schlüssel in einem anderen Keychain hilft ebenfalls nicht, wenn der Build-Prozess diesen Schlüsselbund nicht verwendet.

5. Doppelte oder alte Identitäten isolieren:
   Mehrere abgelaufene, gleich benannte oder historisch importierte Zertifikate erschweren die automatische Auswahl. Nicht sofort löschen: Erst den aktiven Build auf die gewünschte Identität festlegen und eine sichere Rückfallkopie der benötigten digitalen Identität erstellen.

Die Übersicht der Zertifikatstypen im Apple Developer Account ist dabei die Referenz für die vorgesehene Rolle von Entwicklungs- und Distributionszertifikaten. Ein Fehler namens errSecInternalComponent rechtfertigt allein noch keine neue Apple-Distribution-Ausstellung.

Wenn das grafische Terminal funktioniert, SSH aber nicht, wird der Schlüsselbund zunächst explizit für den Build-Kontext bestimmt und entsperrt. Die Kommandos müssen als derselbe macOS-Benutzer laufen, der später xcodebuild, fastlane oder das Signaturskript ausführt.

Ein möglicher Initialisierungsschritt sieht mit Platzhaltern so aus:

export KEYCHAIN_PATH="<KEYCHAIN_PATH>"
security list-keychains -d user -s "$KEYCHAIN_PATH"
security default-keychain -d user -s "$KEYCHAIN_PATH"
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"

Das Passwort gehört in den geheimen Speicher des CI/CD-Systems und nicht in ein Shell-Skript, eine Prozessliste, ein Repository oder eine dauerhaft lesbare Datei. Auch die Übergabe per Kommandozeile sollte in der konkreten Umgebung darauf geprüft werden, ob andere Prozesse Argumente einsehen können.

Anschließend wird die Zugriffsfreigabe möglichst eng auf die tatsächlich verwendeten Signaturwerkzeuge begrenzt. Ein häufig verwendeter Ansatz ist:

security set-key-partition-list \
  -S apple-tool:,apple: \
  -s \
  -k "$KEYCHAIN_PASSWORD" \
  "$KEYCHAIN_PATH"

Dieser Schritt verändert die Zugriffskontrolle des Schlüsselbunds. Deshalb sollte die bestehende Konfiguration vorher gesichert, der Umfang verstanden und eine Rückfallmöglichkeit dokumentiert werden. Die Einstellung sollte nicht pauschal auf beliebige Programme ausgeweitet werden. Weder das vollständige Abschalten von Sicherheitsmechanismen noch eine dauerhaft offene Keychain ist eine normale Reparatur.

Die Apple-Hilfe zum Erstellen eines App-Store-Provisioning-Profils grenzt die Profilseite von der Zertifikatsseite ab. Das ist für die Diagnose wichtig: Ein korrektes Profil kann einen fehlenden privaten Schlüssel nicht reparieren, und ein funktionierender Schlüssel ersetzt kein passendes Profil.

Ein erfolgreicher Minimaltest mit codesign ist nur ein Zwischenbefund. Ein echtes iOS- oder macOS-Archive kann zusätzlich Frameworks, Extensions, verschachtelte Apps, Entitlements und ein Provisioning Profile enthalten. Deshalb wird nach der Keychain-Reparatur ein vollständig reproduzierbarer Test mit einem unkritischen Projekt durchgeführt.

Die Reihenfolge sollte so aussehen:

1. Projekt und Abhängigkeiten mit identischem Quellstand auschecken.
2. Build-Benutzer, Team-ID, Bundle-ID und Signaturmodus explizit setzen.
3. xcodebuild archive mit einem sauberen, aber nicht produktiven Ausgabeordner ausführen.
4. Das Archive exportieren und die eingebetteten Komponenten prüfen.
5. Erst nach erfolgreichem Export einen kontrollierten Upload-Test durchführen.

Bei der Auswertung müssen die Fehlerphasen getrennt bleiben. Ein Abbruch während codesign verweist auf eine andere Schicht als ein fehlendes Entitlement im Export oder eine Ablehnung beim Upload. Die Xcode-Build-Settings-Referenz von Apple hilft dabei, zu prüfen, welche Signatur- und Exportparameter tatsächlich an den Build übergeben werden.

Für jedes gescheiterte Archive wird festgehalten:

• welche Komponente zuerst fehlschlug;
• welche Identität explizit ausgewählt war;
• welches Provisioning Profile verwendet wurde;
• ob die Entitlements zum Bundle Identifier passten;
• ob der Fehler auf dem gleichen Host grafisch reproduzierbar war.

Wenn eine Zertifikatskette nicht aufgebaut werden kann, ein Zertifikat ungültig ist oder ein privater Schlüssel fehlt, darf eine Neuinstallation gezielt erfolgen. Ein Austausch der digitalen Identität kann jedoch Auswirkungen auf laufende Release-Prozesse, Team-Zuordnungen und andere Build-Hosts haben. Die Apple-Hilfe zum Bearbeiten, Herunterladen oder Löschen von Profilen sollte vor Änderungen an bestehenden Profilen herangezogen werden.

Die Reparatur gilt erst dann als abgeschlossen, wenn die reale Build-Kette auch ohne künstlich offen gehaltene Benutzeroberfläche funktioniert. Dafür wird derselbe Testauftrag in mehreren Zuständen ausgeführt:

• nach einer neuen SSH-Verbindung;
• nach dem Beenden der grafischen Sitzung;
• nach einem fehlgeschlagenen Auftrag und kontrolliertem Wiederholungsversuch;
• nach einem Neustart des Remote-Macs;
• mit einem vollständigen Archive einschließlich Export.

Die folgenden Punkte können als Abnahmeprotokoll verwendet werden:

• [ ] Build-Benutzer und SSH-Benutzer sind identisch dokumentiert.
• [ ] Der verwendete Keychain-Pfad ist im Skript explizit festgelegt.
• [ ] Die Keychain-Entsperrung erfolgt aus einem geschützten Secret-Speicher.
• [ ] Kein Passwort, Token oder privater Schlüssel erscheint im Build-Log.
• [ ] security find-identity zeigt die erwartete Identität im richtigen Benutzerkontext.
• [ ] Zertifikat und passender private Schlüssel befinden sich im verwendeten Keychain.
• [ ] Der minimale codesign-Test funktioniert über SSH.
• [ ] Das vollständige Archive signiert auch verschachtelte Komponenten.
• [ ] Export und Upload verwenden die erwartete Provisioning-Konfiguration.
• [ ] Der Prozess funktioniert nach Abmeldung und Neustart ohne manuelle Dialoge.
• [ ] Für eine fehlerhafte Keychain-Initialisierung existiert ein dokumentierter Rückfall.
• [ ] Änderungen an Zertifikaten oder ACLs sind mit Zeitpunkt und Auswirkung protokolliert.

Ein häufiger organisatorischer Fehler besteht darin, den Host nur während einer manuellen Sitzung zu testen und danach sofort als stabil zu markieren. Wenn ein Team für jede Veröffentlichung zuerst eine grafische Sitzung öffnen oder ein Keychain-Popup bestätigen muss, ist die Umgebung nicht wirklich unbeaufsichtigt. In diesem Fall sollte geprüft werden, ob der aktuelle Mac dauerhaft als Build-Host betrieben werden kann oder ob eine vollständig berechtigte, dauerhaft verfügbare Remote-Mac-Umgebung besser zum Release-Prozess passt. Informationen zur möglichen Remote-Mac-Nutzung für Entwicklungsaufgaben können dabei als nächster Vergleichspunkt dienen.

Eine Reparatur des aktuellen Hosts ist sinnvoll, wenn die Identität nachweislich vollständig ist, nur der SSH-Kontext abweicht und die Keychain-Initialisierung reproduzierbar gemacht werden kann. Das ist normalerweise der risikoärmste Weg, weil keine Zertifikatsrotation und keine Änderung an allen anderen Build-Rechnern erforderlich ist.

Eine kontrollierte Neuimport- oder Rotationsroute ist erst angemessen, wenn mindestens eine der folgenden Bedingungen belegt ist:

• der private Schlüssel fehlt nachweislich;
• Zertifikat und privater Schlüssel gehören nicht zusammen;
• das Zertifikat ist abgelaufen oder widerrufen;
• die Identität wurde doppelt und widersprüchlich importiert;
• die Vertrauenskette kann trotz korrektem Keychain-Zugriff nicht hergestellt werden.

Dabei sollte der alte Zustand nicht vorzeitig gelöscht werden. Zuerst werden Abhängigkeiten, aktive Projekte, Profile und Rückfall-Hosts erfasst; danach wird die neue digitale Identität in einer isolierten Testumgebung validiert. Erst wenn Archive, Export und Upload erfolgreich sind, wird die alte Konfiguration aus dem produktiven Ablauf entfernt.

Die Alternative „eine dauerhaft geöffnete grafische Sitzung“ wirkt kurzfristig bequem, erhöht aber die Abhängigkeit von manuellen Eingriffen, macht Neustarts schwerer planbar und kann bei einem nächtlichen Release erneut zu einem Keychain-Dialog führen. Ein eigener lokaler Mac bietet dagegen physische Kontrolle, verursacht aber Anschaffung, Wartung, Stromverbrauch und die Bindung an einen festen Standort. Für seltene Releases ist eine eigene Maschine oft unnötig; für dauerhaft hohe Last oder benötigte physische Gerätezugriffe kann sie trotzdem die bessere Wahl sein.

Wenn nur temporäre Signier- oder Testkapazität benötigt wird, kann ein gemieteter Remote-Mac von NUKCLOUD die praktische Zwischenlösung sein: vollständige Benutzerrechte, ein dauerhaft erreichbarer Host und ein klar abgrenzbarer Build-Benutzer vermeiden, dass ein Entwicklerrechner kurz vor dem App-Store-Upload umkonfiguriert werden muss. Die passende Region und Laufzeit sollten anhand von Latenz, Datenschutzanforderungen, Dauerlast und dem tatsächlichen Release-Rhythmus gewählt werden; für eine langfristige, gleichmäßige Hochlast ist ein eigener Mac weiterhin mit einzubeziehen. Verfügbare Optionen können auf der deutschen NUKCLOUD-Bestellseite geprüft werden.

Die folgenden Antworten trennen die sichtbare Zertifikatsliste von den Voraussetzungen, die der eigentliche Signaturprozess benötigt.

Warum scheitert codesign nur über SSH?

Grafische Sitzung und SSH können trotz gleichem Benutzernamen unterschiedliche Umgebungsvariablen, Standard-Keychains oder Entsperrzustände verwenden. Wenn der grafische Test funktioniert, sollte zuerst der SSH-Kontext reproduzierbar auf denselben Keychain-Pfad und dieselbe Identität gesetzt werden. Erst wenn beide Sitzungen dieselben Voraussetzungen haben, ist eine Zertifikatsrotation sachlich begründet.

Ist ein neues Apple-Distribution-Zertifikat die Standardlösung?

Nein. errSecInternalComponent ist keine eindeutige Meldung für ein defektes Apple-Distribution-Zertifikat. Der erste Prüfschritt betrifft den Sitzungszugriff, danach die Kombination aus Zertifikat und privatem Schlüssel sowie die Vertrauenskette. Ein neues Zertifikat kann laufende Prozesse beeinflussen und sollte nur erstellt werden, wenn Ablauf, Widerruf, fehlender Schlüssel oder eine tatsächlich beschädigte Identität nachgewiesen ist.

Wie wird der passende private Schlüssel geprüft?

security find-identity liefert eine wichtige Orientierung, bestätigt aber nicht allein die erfolgreiche Verwendung des privaten Schlüssels. Im verwendeten Keychain muss die Zertifikatszuordnung mit einem privaten Schlüssel vorhanden sein. Anschließend wird mit einem Testartefakt und der expliziten Identität signiert. Schlägt dieser Test trotz vorhandener Anzeige fehl, sind Keychain-Pfad, Sperrstatus und Zugriffsfreigabe weiter zu untersuchen.

Was muss nach dem Abmelden getestet werden?

Nach dem Ende der grafischen Sitzung wird eine neue SSH-Verbindung aufgebaut und der Keychain-Initialisierungsschritt vollständig ausgeführt. Danach folgt nicht nur ein Identitätstest, sondern ein echtes Archive mit Export. Dasselbe wird nach einem Host-Neustart wiederholt. Erst wenn kein manueller Dialog, keine lokale Sitzung und kein interaktives Passwort erforderlich ist, kann der Ablauf als unbeaufsichtigt gelten.

Warum reicht eine sichtbare Identität nicht aus?

Eine sichtbare Identität kann bedeuten, dass das Zertifikat gefunden wurde; sie beweist nicht, dass der passende private Schlüssel verfügbar, entsperrt und für den aktuellen Signaturprozess zugänglich ist. Zusätzlich können ein falscher Benutzer, ein anderer Keychain-Pfad, eine restriktive Zugriffskontrolle oder ein nicht passendes Provisioning Profile den späteren Signaturvorgang blockieren.

Bei codesign errSecInternalComponent sollte die Entscheidung deshalb zeitlich geordnet bleiben: Fehlerprotokoll sichern, Grafik und SSH vergleichen, Identität und privaten Schlüssel prüfen, Keychain-Zugriff reparieren und erst danach Archive, Export und Neustartverhalten abnehmen. Wer aktuell für jeden Release zuerst eine grafische Sitzung öffnen, ein Popup bestätigen oder einen lokalen Mac erreichbar machen muss, trägt unnötige Betriebsrisiken in den iOS- und macOS-Veröffentlichungsprozess.

Wenn eine zeitweise oder dauerhaft erreichbare Build-Umgebung ohne eigenen Mac benötigt wird, kann NUKCLOUD für einen kontrollierten Testlauf gemietet werden. Vor einer längeren Bindung sollte der beschriebene Abnahmetest mit SSH, Abmeldung, Reconnect und Neustart durchgeführt werden; so zeigt sich, ob die Remote-Mac-Lösung tatsächlich die vorhandene Signaturkette stabilisiert, statt nur den nächsten manuellen Workaround zu verdecken.

Zuletzt aktualisiert am 25.08.2026; technische Angaben und Prüfschritte wurden anhand der Apple-Dokumentation zu Codesignaturzertifikaten, Keychains, Provisioning Profiles und Xcode-Build-Einstellungen abgeglichen.