The hexsign-fetch-signing-material Step downloads the certificate (.p12 and password) and/or provisioning profile (.mobileprovision) stored in HexSign, places them on disk, and exposes the resulting paths as env vars for downstream Steps like certificate-and-profile-installer, xcode-archive, and fastlane. Nothing is uploaded to Bitrise's code-signing file storage.
What you need
- A service credential with
hexsign-api/readscope, provisioned under Settings → CLI Tokens in the HexSign dashboard. The secret is shown exactly once. HEXSIGN_CLIENT_IDandHEXSIGN_CLIENT_SECRETconfigured as secret env vars in the Bitrise workflow editor.- The certificate and profile IDs you sign with (or a certificate type, bundle id, and team id if you fetch by filter).
Add it to your workflow
steps:
- hexsign-fetch-signing-material@0:
inputs:
- certificate_id: $HEXSIGN_CERT_ID
- profile_id: $HEXSIGN_PROFILE_ID
- client_id: $HEXSIGN_CLIENT_ID
- client_secret: $HEXSIGN_CLIENT_SECRET
- certificate-and-profile-installer@1:
inputs:
- certificate_url: file://$HEXSIGN_CERTIFICATE_PATH
- provisioning_profile_url: file://$HEXSIGN_PROFILE_PATH
# Read the .password file in a script step and feed it in via env.
- xcode-archive@5: {}The Step writes the cert and profile paths into env vars that the next Steps read. On macOS you can skip certificate-and-profile-installer entirely: pass the keychain input to have the Step create a keychain and import the certificate, and install_profile to drop each .mobileprovision where Xcode finds it. If you regenerate signing material regularly, set certificate_type, bundle_id, and team_id instead of IDs so the workflow keeps working when an artefact rotates.