Jenkins - Xcode build works codesign fails - ios

Question

Below is my build script (not using xcodebuild plugin).
Build step works
I have created a separate keychain with the required certs and private keys, and they are visible in Keychain Access
keychain commands don't fail in the script
security list-keychains shows these as valid keychains
It's acting like unlock command doesn't truly succeed.
When I try to run codesign from the command line via
codesign -f -s "iPhone Developer: mycert" -v sample.app/ --keychain /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain
I get
CSSM_SignData returned: 000186AD
sample.app/: unknown error -2070=fffffffffffff7ea
although I'm not sure I'm emulating from the command line properly since you can at best
sudo -u jenkins bash
xcodebuild ONLY_ACTIVE_ARCH="NO" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED="NO" -scheme "MySchemeName" CONFIGURATION_BUILD_DIR="`pwd`"
security list-keychains -s /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain
+ security default-keychain -d user -s /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain
+ security unlock-keychain -p jenkins /Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain
+ security list-keychains
"/Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain"
"/Library/Keychains/System.keychain"
+ security default-keychain
"/Users/Shared/Jenkins/Library/Keychains/JenkinsCI.keychain"
+ codesign -f -s '$IDENTITY_GOES_HERE.' -v sample.app/
sample.app/: User interaction is not allowed.
Any help is greatly appreciated.

Answer 1

We don't use Jenkins but I've seen this in our build automation before. Here's how we solved it:
1) Create your build Keychain. This will contain the private key/certificate used for codesigning:
security create-keychain -p [keychain_password] MyKeychain.keychain
The keychain_password is up to you. You'll use this later to unlock the keychain during the build.
2) Import the private key (*.p12) for your CodeSign identity:
security import MyPrivateKey.p12 -t agg -k MyKeychain.keychain -P [p12_Password] -A
The key here is the "-A" flag. This will allow access to the keychain without warning. This is why you're seeing the "User interaction is not allowed" error. If you were attempting this build via the Xcode UI, this is the point where it would prompt you to "Allow access" to your keychain.
3) However you're saving the Keychain (e.g.: checking it in to source control), make sure it's writeable and executable by your build user.
When you're ready to build, add the following prior to running xcodebuild:
# Switch keychain
security list-keychains -s "/path/to/MyKeyhain.keychain"
security default-keychain -s "/path/to/MyKeychain.keychain"
security unlock-keychain -p "[keychain_password]" "/path/to/MyKeychain.keychain"
If you're running locally, you may want to add something at the end of your build script that switches back to the login keychain (~/Library/Keychains/login.keychain), e.g.:
# Switch back to login keychain
security list-keychains -s "~/Library/Keychains/login.keychain"
security default-keychain -s "~/Library/Keychains/login.keychain"
Give that a try. We create a separate Keychain for each identity we use (our own plus builds on behalf of customers). In our company's case, we have both an AppStore and Enterprise account. This can result in naming conflicts while codesigning (e.g.: both accounts resolve to "iPhone Distribution: ACME Corporation"). By keeping these identities in separate keychains we avoid this conflict.

Answer 2

Moving the certs to the System keychain, and referencing it specifically fixed the issue

Answer 3

In this answer, we add / remove your iOS certificate without manipulating the login keychain nor changing the default keychain by:
Use a temporary keychain
Append temporary keychain to the search list (not replacing)
Unlock temporary keychain with no timeout
Import your certificate using -T /usr/bin/codesign
Do the build
Delete certificate by deleting temporary keychain
Create a temporary keychain. I add $$ which is the PID to create a unique name for the keychain. This allows multiple temporary keychains to be created without clashing. This is useful, if we running concurrent Jenkins jobs.
# Create temporary keychain
MY_KEYCHAIN="MyKeychain-$$.keychain"
MY_KEYCHAIN_PASSWORD="secret"
security create-keychain -p "$MY_KEYCHAIN_PASSWORD" "$MY_KEYCHAIN"
Appends temporary keychain to the search list. Be careful to use security list-keychains -s to append your keychain, else, you will clobber builds running in another thread:
# Append keychain to the search list
security list-keychains -d user -s "$MY_KEYCHAIN" $(security list-keychains -d user | sed s/\"//g)
security list-keychains
Unlocks temporary keychain with no automatic relocking timeout (security set-keychain-settings). If you forget to fix the relocking timeout, builds taking longer than the default relocking timeout (typically about 30 minutes) will trigger the password prompt:
# Unlock the keychain
security set-keychain-settings "$MY_KEYCHAIN"
security unlock-keychain -p "$MY_KEYCHAIN_PASSWORD" "$MY_KEYCHAIN"
Import iOS certificate and grants /usr/bin/codesign access without requiring a password prompt.
# Import certificate
security import $CERT -k "$MY_KEYCHAIN" -P "$CERT_PASSWORD" -T "/usr/bin/codesign"
Since the temporary keychain contains only 1 certificate we can, programmatically, derive the IOS_IDENTITY (typically required as an input to build steps).
# Detect the iOS identity
IOS_IDENTITY=$(security find-identity -v -p codesigning "$MY_KEYCHAIN" | head -1 | grep '"' | sed -e 's/[^"]*"//' -e 's/".*//')
IOS_UUID=$(security find-identity -v -p codesigning "$MY_KEYCHAIN" | head -1 | grep '"' | awk '{print $2}')
The security set-key-partition-list is a new/additional requirement for unlocking the certificate.
# New requirement for MacOS 10.12
security set-key-partition-list -S apple-tool:,apple: -s -k $MY_KEYCHAIN_PASSWORD $MY_KEYCHAIN
Do your build now:
# Insert your custom build steps
Delete temporary keychain. Because the build is done, we no longer require the keychain and the certificate. Deleting the temporary keychain will automatically pop it from the search list. i.e. all other keychains will remain.
# Delete the temp keychain
security list-keychains
security delete-keychain "$MY_KEYCHAIN"
security list-keychains

Answer 4

Required to unlock keychain before to sign
"security unlock-keychain -p"

Answer 5

Only one thing solved this problem for me.
What I did is setting the Private Key of the Signing Certificate in the Keychain Access to Allow all applications to access this item.

Answer 6

FWIW... let me throw out another possible reason for this. You may have duplicate certificates floating around and codesign can't tell which one to use. When you run this command from your Jenkins slave do you see duplicate, valid certificates? Something like this:
$ security find-identity -v -p codesigning
1) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)"
2) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)"
3) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)"
4) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)"
5) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)"
6) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)"
7) AAAAE00066DED2FE77DF43012573AD5B6188AAAA "iPhone Developer: JOHN SMITH (XAAAAFSUSJ)"
8) BBBB5B03DB566209964247982908D3DD74D1BBBB "iPhone Distribution: Example, Inc. (TBBBBH5HUE)"
8 valid identities found
If so, I have found it useful to do the following and get back to a baseline set of signing certificates:
Delete all the certificates on the Jenkins slave (and other Jenkins slaves that will be running your build script).
Next: verify, you have 0 identifies by running $ security find-identity -v -p codesigning again.
Within your application's repository include a custom MyApp.keychain with the two valid certificates in it. Be sure to remove any duplicates.
Now, from your build script and before the codesign process runs from unlock MyApp.keychain and set it as the default. This exposes those certificates as available for codesign.
Finally, verify on your Jenkins slave again: $ security find-identity -v -p codesigning that you see only the certificates you bundled into MyApp.keychain and that there are no other signing identities on the system. If you still see duplicates after having done this you have other places where your Jenkins slave is being made aware of these certificates.

Answer 7

I copied all the certs/private keys to a new keychain (you can right-click on the items and simply copy and paste). In the new keychain, right-click on each private key, Get Info -> Access Control and make the keys available to all apps.
Importantly, in the upper left of the Keychain app is the list of keychains. Re-order them so that the new keychain is first in the list.
Another answer I found gave the build step to unlock this keychain during the build:
KEYCHAIN=/Users/<you>/Library/Keychains/codesign.keychain
# the -s option adds $KEYCHAIN to the search scope, while the -d option adds $KEYCHAIN to the system domain; both are needed
security -v list-keychains -d system -s $KEYCHAIN
security -v unlock-keychain -p <keychain password> $KEYCHAIN

Answer 8

Here what worked for me:
I created a new keychain and copied all entries from "login" to it, named it "jenkins_ios"
Made new keychain default.
Added a new "Execute shell" step in Jenkins config, it should be the first step beforecode signing, containing the following:
KEYCHAIN=/Users/<user>/Library/Keychains/jenkins_ios.keychain
security -v list-keychains -s $KEYCHAIN
security -v unlock-keychain -p <password> $KEYCHAIN
security set-keychain-settings -t 3600 -l $KEYCHAIN
Last step is really important, as default unlock timeout may not be enough long for your project to build properly (exactly this happened with our project, as it is huge and build step took about 5-7 minutes, and keychain became locked at the moment it was required for codesign).

Answer 9

This might also be caused by a default timeout on the keychain.
Check out my answer to "User interaction is not allowed" trying to sign an OSX app using codesign

Answer 10

That's a code signing error, the xcodebuild command can't access your certificate's private key since it's running through Jenkins' slave with SSH.
Run this line in your shell script before you run the xcodebuild in order to allow access:
security set-key-partition-list -S apple-tool:,apple: -s -k <ROOT-PASSWORD> /Users/<YOUR USER NAME>/Library/Keychains/login.keychain-db
Hope that helps!

Answer 11

If you face this issue on a CI (GitHub Actions in my case).
Then don't forget to unlock the keychain where your certificates are installed before you run the xcodebuild command.
For example:
security -v unlock-keychain -p <keychain password> $KEYCHAIN
If the keychain is locked the xcodebuild command will hang/freeze when trying to sign the app because it will be waiting for the keychain password to be entered and hence this is a CI and not your own machine there is no way to enter the password when you are asked for it.
You don't need to unlock the keychain if you build the app without code signing e.g ... CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" ...

Answer 12

I removed duplicate keys from the key chains (login and system) and it started working. I did only have one certificate but many keys so I had to filter on keys to see them properly.