Erst hier nachsehen, dann uns kontaktieren

Übertragen Sie die .p12-Datei über einen sicheren Kanal auf die Maschine, importieren Sie sie in den für den Build verwendeten Schlüsselbund und vergewissern Sie sich, dass sie den zugehörigen privaten Schlüssel enthält. Nur mit dem Zertifikat, aber ohne privaten Schlüssel, ist keine Codesignierung möglich. Stellen Sie das Importpasswort über eine CI-Secret-Variable bereit. Speichern Sie es nicht im Repository, in Skripten oder im Ticket.

security find-identity -v -p codesigning

Führen Sie die Prüfung in der Benutzerumgebung aus, in der der Runner tatsächlich läuft. Dass ein Zertifikat für den Desktopbenutzer sichtbar ist, bedeutet nicht, dass auch ein anderer Dienstbenutzer darauf zugreifen kann. Prüfen Sie außerdem, ob der Schlüsselbund entsperrt und in der Suchliste des Benutzers enthalten ist und ob der Signierprozess Zugriffsrechte hat.

Verwenden Sie für den Build einen eigenen Schlüsselbund und sperren Sie ihn nach Abschluss der Aufgabe gemäß Ihrem Ablauf. Wenn Sie Hilfe benötigen, teilen Sie nur bereinigte Prüfergebnisse zur Signieridentität und den Fehlertext mit. Senden Sie weder die .p12-Datei noch den privaten Schlüssel oder das Importpasswort.

Stimmen Sie vier Angaben aufeinander ab: Bundle ID, Team ID, Exportzweck und Entitlements. Bei Apps mit Erweiterungen benötigt jedes zu signierende Target eine passende Konfiguration. Ein passendes Profil für die Haupt-App bedeutet nicht, dass auch die Erweiterungen korrekt konfiguriert sind.

Prüfen Sie außerdem, ob das Provisioning Profile gültig ist, das verwendete Zertifikat enthält und die Signiermethode in den Exportoptionen zum Projekt passt. Für Entwicklungstests und Distributionsversionen gelten unterschiedliche Konfigurationen. Wählen Sie nicht allein aufgrund eines ähnlichen Dateinamens.

Bewahren Sie die Protokolle des Exportvorgangs und eine bereinigte Kopie der ExportOptions.plist auf. Geben Sie im Ticket an, ob der Fehler bei archive oder exportArchive auftrat. So lässt sich die Ursache schneller eingrenzen.

Speichern Sie die .p8-Datei in einem zugriffsbeschränkten Verzeichnis. Stellen Sie Key ID, Issuer ID und Dateipfad über CI-Secret-Variablen bereit. Verwenden Sie nur die Berechtigungen, die für Upload oder Automatisierung erforderlich sind. Schreiben Sie den Schlüsselinhalt nicht direkt in eine Lane und checken Sie ihn nicht ins Repository ein.

Ein API Key kann Uploads und Verwaltungsabläufe unterstützen, die diese Authentifizierungsmethode verwenden. Er ersetzt jedoch nicht das Zertifikat mit privatem Schlüssel, das für die lokale Codesignierung benötigt wird. Unterscheiden Sie bei fehlgeschlagenen TestFlight-Uploads zwischen Signierfehlern beim lokalen Build und Problemen mit Authentifizierung, App-Berechtigungen oder Versionsangaben.

Aktualisieren Sie nach dem Wechsel des Schlüssels die Runner-Konfiguration und entfernen Sie Verweise auf den alten Schlüssel. Wenn Sie Unterstützung benötigen, teilen Sie den bereinigten Fehlercode und den betroffenen Schritt mit. Senden Sie nicht die .p8-Datei.

Prüfen Sie die Leseberechtigung für das Signierungs-Repository, die Entschlüsselungsphrase, den Verteilungstyp, die App-Kennung und die Teamkonfiguration. Die CI sollte im Alltag bereits vorbereitete Signierressourcen bevorzugt schreibgeschützt abrufen, statt bei jedem Lauf Zertifikate erstellen oder ändern zu wollen.

lane :prepare_signing do
  match(
    type: "appstore",
    readonly: true,
    app_identifier: ENV.fetch("APP_IDENTIFIER"),
    team_id: ENV.fetch("TEAM_ID")
  )
end

Verwalten Sie die Zugangsdaten für das Repository und die Entschlüsselungsphrase getrennt. Schlägt der Abruf fehl, prüfen Sie zuerst die Repository-Authentifizierung. Bei einem Entschlüsselungsfehler prüfen Sie die Phrase. Wenn die Installation gelingt, die Signierung aber fehlschlägt, untersuchen Sie Schlüsselbund und Provisioning Profile. Fassen Sie diese drei Fehlerarten nicht unter „match funktioniert nicht“ zusammen.