I am trying to automate a cert installation on a bunch of different Mac boxes so that I can build on any of them using Jenkins. I've seen that you can do an import:
sudo security import certName -P password
And you can also allow applications to use the keychain at installation time:
sudo security import certName -P password -T /usr/bin/codesign
But is there a way to modify existing installations from the command line so I don't have to reimport all the certs that I have imported already? Or is it okay to just reimport everything by running the second command on all the boxes, and it will just update the existing cert installation?
Basically, the overall problem I'd like to solve is to prevent the prompts asking for passwords every time I run a build that say "codesign would like to access the keychain", etc. And then I have to enter the password and click "Always Allow" to prevent it again. But every time I update the cert, I have to go through this process again.
Has anyone ever automated this entire process before? Installing the cert and allowing apps to access the keychain without prompting for a password.
I'd also be happy with allowing any applications to access the keychain without a password. I'm not sure if a flag like that even exists, but it would be a big help if this was possible.
It seems that these three lines were what I needed (answer found here: security / codesign in Sierra: Keychain ignores access control settings and UI-prompts for permission):
security unlock-keychain -p password kaychainName.keychain
security set-keychain-settings keychainName.keychain
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k password keychainName.keychain
Related
I'm trying to move our iOS CI over to github actions but I'm running into some build issues . These issues (fastlane just hangs when gym runs) seem to arise when using match.
Here's the log that makes me think it's keychain related
WARN [2019-09-26 13:46:14.52]: Could not configure imported keychain item (certificate) to prevent UI permission popup when code signing
Check if you supplied the correct `keychain_password` for keychain: `/Users/runner/Library/Keychains/login.keychain-db`
security: SecKeychainItemSetAccessWithPassword: The user name or passphrase you entered is not correct.
The docs say sudo is passwordless so I assumed the same for keychain. I seem to be wrong but I can't find anything in the docs for it. Any help would be greatly appreciated.
EDIT
Lyndsey Ferguson's comment below is mostly the solution. They're approach of using create_keychain and then match I was able to just specify the keychain and it's password so I was able to avoid import_certificate
EDIT 2
Here's what I'm doing in fastlane to get around this
create_keychain(
name: "actiontest_keychain",
password: "meow",
default_keychain: true,
unlock: true,
timeout: 3600,
lock_when_sleeps: false
)
match(
type: "appstore",
readonly: is_ci,
keychain_name: "actiontest_keychain",
keychain_password: "meow"
)
Maybe it is a little late, but I think it is worth mentioning that there is a handy fastlane action setup_ci for this purpose:
Description
Setup the keychain and match to work with CI
Creates a new temporary keychain for use with match
Switches match to readonly mode to not create new profiles/cert on CI
Sets up log and test result paths to be easily collectible
Just add this to the top of your Fastfile or within a specific lane if you use CI.
Fastfile lane Example
lane :build_release do
setup_ci
sync_code_signing(
type: "appstore",
readonly: is_ci
)
build_app
end
Also make sure, your provisioning profiles and certificates within your match storage are up to date and you configured manual signing for release build. Otherwise match will maybe try to sign your app with wrong signing identities which will fail ;)
I can’t use Fastlane because I am trying to use the keychain to work with Java 14’s new jpackage tool in GitHub Actions to build and code sign a Java application native bundle, so I was excited to see Yakuhzi’s answer. It almost worked for me, but there were a couple of errors I had to sort out, which were very difficult because there were no error messages: my workflow just hung on the jpackage command, while I assume the build Mac virtual machine invisibly prompted for the keychain to be unlocked in the virtual frame buffer.
Here is the variation that worked for me. The first three steps were fine (I am passing my signing certificate and its decryption passphrase to the script as environment variables extracted from Github Action secrets, and use the same passphrase to create the build keychain):
security create-keychain -p "$IDENTITY_PASSPHRASE" build.keychain
security default-keychain -s build.keychain
security unlock-keychain -p "$IDENTITY_PASSPHRASE" build.keychain
But trying to run his fourth line at this point would fail with this error:
security: SecItemCopyMatching: The specified item could not be found in the keychain.
Eventually, I after studying the documentation for security set-key-partition-list I realized the first problem was that the -k argument requires the keychain password, which must have been actions in his case! So my next step was to fix line 4 to look like this:
security set-key-partition-list -S apple-tool:,apple: -s -k "$IDENTITY_PASSPHRASE" build.keychain
I was still getting the error though, so I studied the documentation some more, and experimented with the command on a spare Mac mini that didn’t have my signing identity in the login keychain. Eventually I discovered the command was trying to take an action on a signing key that did not yet exist in the keychain. So I moved my steps that import my signing key before that line, and it started to work. Here is the full section once it worked, and you can see the entire script on GitHub:
security create-keychain -p "$IDENTITY_PASSPHRASE" build.keychain
security default-keychain -s build.keychain
security unlock-keychain -p "$IDENTITY_PASSPHRASE" build.keychain
echo "$IDENTITY_P12_B64" > DS_ID_App.p12.txt
openssl base64 -d -in DS_ID_App.p12.txt -out DS_ID_App.p12
security import DS_ID_App.p12 -A -P "$IDENTITY_PASSPHRASE"
security set-key-partition-list -S apple-tool:,apple: -s -k "$IDENTITY_PASSPHRASE" build.keychain
This is an answer that can be accepted, but I would like to understand how the cert and private key get into the keychain.
Try this:
- name: Set up keychain
run: fastlane run create_keychain name:name_of_keychain password:chosen_password
That will create the keychain, and then when you want to use it, you can again provide the chosen_password however you have it. Probably a GITHUB_X env var?
You could try to create a new keychain and set it as default.
- name: Set up keychain
run: |
security create-keychain -p <password> build.keychain
security default-keychain -s build.keychain
security unlock-keychain -p <password> build.keychain
security set-key-partition-list -S apple-tool:,apple: -s -k actions build.keychain
I am trying the automate the build process of Xcode using ant scripts. I used the security import command with -A and -T to import the certificates.
Command which I used to import the certificate
security import <PATH till the certificate> -k <PATH of keychain> -t priv -P <password> -T <codeSigning Path> -T <Xcode.app Path> -A
But still when I run the xcodeBuild command to archive the build, it pops up a pop which asks for the permission to access the key chain
ask for the permission to access the key chain
Please post as soon as you see this post.
I've had this issue as well. It seems Mac won't let anything automatically access your keychain. Best solution was to check the "Do this every time" box in the popup to prevent it bothering you again
It's Working fine
If its default login keychain the above command will work.
If you have created the login keychain then some times code sign will ask for permission.Solution for this restore your login keychain to default version by taking a backup of all the certificates from the login keychain.
Building a new Jenkins for an iOS app CI story.
I created a keychain named build in KeyChainAccess to hold the dev certificate.
I set a password for the keychain.
On Jenkins, Manage Jenkins --> Keychains and Provisioning Profiles Management -> choose the build.keychain file and upload.
I filled in the password (the same as what I set earlier). I filled in the certificate (by copy the common name of the certificate info in KeyChain access).
I created a Jenkins job using the Keychain and Code Signing Identity, filled in the password.
But when I build the project by Jenkins, it throw the following error in Console Output:
[ProjectName] $ /usr/bin/security unlock-keychain -p ******** /Users/Shared/Jenkins/Home/jobs/JobName/workspace/build.keychain
security: SecKeychainUnlock /Users/Shared/Jenkins/Home/jobs/JobName/workspace/build.keychain: The user name or passphrase you entered is not correct.
FATAL: Unable to unlock the keychain.
I checked the password, I can unlock the build keychain in KeyChain Access using the password. I am not sure what username it asks for, Jenkins?
It's been a long time since you asked this question but I think it's worth it to answer it!
The output error The username or passphrase you entered is not correct. can be caused by several things but one of the common errors is a wrong keychain path.
To solve it the first thing you need to be sure is that your keychain was created and get its correct path. Run the following command in your console:
security list-keychains
The output should return all the keychains you have, something like this:
"/Users/jenkins/Library/Keychains/login.keychain-db"
"/Library/Keychains/System.keychain"
If your build keychain is not there something were wrong during its creation and you need to create it again. In case you keychain is the above list you need to copy the path where the keychain is located.
If for some reason the name of your keychain is duplicated in that list be sure to remove the duplicated keychains running the following command:
security list-keychains -s pathOfTheKeychainDuplicated
Then with the path and the password of the user with access to this keychain you can unlock it using the following command:
security unlock-keychain -p ****** /Users/jenkins/Library/Keychains/login.keychain-db
In the above command, the path should be the one of your build keychain
I hope this helps you.
In my Mac, got a similar issue for unlock keychain command command.
I have just quit the terminal(all tabs)
Quit the keychain
Reopened the keychain -> unlocked and locked the keychains couple of times manually.
Then I executed the command, it worked! Surprising..
One more hint, got this issue after upgrading macOS from Sierra to High Sierra.
I had a similar problem running unlock-keychain from jenkins after upgrading to Mojave.
It was caused by the default keychain being set incorrectly.
I used
security default-keychain -s <name> to change the default back to the jenkins user's login keychain.
We are using Jenkins as our CI server for our iOS team with the following setup:
Master server on OSX, not running any job
2 slaves on OSX running our integration jobs + UI Testing
Currently all signing identities and provisioning profiles for the apps are uploaded each slave which makes the administration a tad tedious and adding a new node to the cluster even more painful.
To work around this we've looked into using the credentials plugin with Developer profiles and import the profile as the first build step on all iOS jobs but are faced with to main issues:
The import developer profile seems to work the first time (at least for creating the keychain entries) but the job fails with a "no matching provisioning profile" error, even if the developer profile contains all the provisioning profiles required by the target.
Second run on the same job always fail with a "Keychain already exist" error
We've tried some work arounds for the second issue adding a shell build step removing the particular keychain but are still faced with the first error. If we manually install the profile on the slave the build passes but this defeat the purpose of using the credentials plugin.
What do you guys think?
I think the newest version of the credentials plugin now first removes any existing keychains with a matching name before importing, as seen in the log output below.
$ security delete-keychain jenkins-MyAppsBuildName-iOS
$ security create-keychain -p ******** jenkins-MyAppsBuildName-iOS
$ security unlock-keychain -p ******** jenkins-MyAppsBuildName-iOS
Because of this fact, I don't think you will have an issue anymore with duplicate keychain errors on the second run.
As far as the issue relating to the provisioning profile not being found, add the following line inside the execute shell command and run a build on jenkins.
security list-keychains
Take a look at the console for that specific build and you should see a list of all the keychains that are currently in the scope of the shell.
If you do not see "jenkins-MyAppsBuildName-iOS" as a listed keychain, this is why you are having the signing issue. Because the keychain is not listed, it is never even being searched through to find the proper signing identity/profile.
Solution: Warning: it's hacky
I'm not 100% sure why this is happening, but from other threads it appears to be a permissions issue.
Luckily there is an easy way around this.
In the execute shell command add the following:
security list-keychain -s jenkins-${JOB_NAME}
This will reset the keychain list to include the keychain needed to successfully build the project.
To verify that this now lists the proper keychain, you can add the following lines to the shell command:
security list-keychain
security list-keychain -s jenkins-${JOB_NAME}
security list-keychain
Now compare the output of the first list-keychain command with the second list-keychain command in the console. Make sure that the jenkin's build keychain is listed after the second security list-keychain output.
Warning: This will permanently change the keychain list on the system, so it is probably a good idea to reset the keychain after the build completes. You can accomplish this by settings the default desired keychain values in the xcode configuration inside of Jenkin's System Configuration section. After doing so, make sure to tick the check box "Restore OS X keychains after build process as defined in global configuration" under build environment inside of the Jenkins job's page.
Additional info: In my example I set the keychain-list to only include the keychain generated from Jenkins, but you may decide to also include the standard system and login keychain's by modifying the line as such:
security list-keychain -s jenkins-${JOB_NAME} login.keychain System.keychain
Keywords: Jenkins, iOS, slave, node, Xcode, plugin, credentials, .developerprofile
I'm trying to setup an automated build server for an iPhone application. I'd like to be able to have nightly adhoc beta builds so that testers can follow the development.
I've setted up xcode successfully xcode to perform adhoc builds and I can also launch the build from the command line:
xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build
The problem I'm having is that the following line doesn't work from a forked terminal (using nohup or screen) and failed with the following
CodeSign error: Code Signing Identity 'iPhone Distribution: XXXXX' does not match any code-signing certificate in your keychain. Once added to the keychain, touch a file or clean the project to continue.
I've checked my environment variables in my shell and in nohup or screen and didn't found a clue.
I guess my problem is that the forked terminal can't access to the keychain but I have no clue on how to allow it.
Thanks for your help
I had te error User interaction is not allowed and solved it by unlocking the keychain first
security unlock-keychain /Users/yannooo/Library/Keychains/login.keychain
I've also tried to put my certs in the System's keychain and it was working.
My final solution was to put all my iPhone related certs in a dedicated keychain named iPhone.keychain using the Keychain Access application
security list-keychains -s /Users/yannooo/Library/Keychains/iPhone.keychain
security unlock-keychain -p keychainpassword /Users/yannooo/Library/Keychains/iPhone.keychain
There are two (possibly three!) components to this. One is the keychain must be unlocked. Second, there is an access control list inside the keychain that tells which permissions are given to applications in the unlocked state. So even if you have the keychain successfully unlocked, if the ability to access the private key and sign with it isn't given to /usr/bin/codesign then you will still get this message. Finally, if you are on Mac OS Sierra, the default partition ID assigned to keys is incorrect in order to be compatible with the codesign binary.
The solution is as follows:
1) If you have access to the Keychain Access GUI, then you can manually grant every program or /usr/bin/codesign access by right clicking on your private key, selecting the "Access Control" tab and then selecting the "Allow all applications to access this item" radio or the list of "Always allow access by these applications" list.
2) If you are encountering this error, chances are you are trying to run codesign for a non-login user. In this case, you clearly don't have access to the "Keychain Access" GUI. For these cases, you verify the sign authorization missing for application <null>, which apparently means all applications, or specifically /usr/bin/codesign by using:
security dump-keychain -i login.keychain
However, you cannot add or modify access control attributes in interactive mode for some reason --only delete! You actually have to manually delete the key and re-add it to the keychain specifying the -T flag.
security import login.keychain -P "<password>" -T /usr/bin/codesign
Where -T specifies
-T Specify an application which may access the imported key (multiple -T options are allowed)
3) If you are on Mac OS Sierra, modify the partition ID to include the apple partition. Presumably, this is the namespace assigned to codesign because it was distributed by Apple.
security set-key-partition-list -S apple-tool:,apple: -k "<password>" login.keychain
NOTE: The apple-tool partition is inserted by the security tool, so the command above preserves that partition. For more information on this aspect, see: http://www.openradar.me/28524119
Another solution :
Open the Keychain Access
Right click on the private key
Select "Get Info"
Select "Access Control" tab
Click "Allow all applications to access this item"
Click "Save Changes"
Enter your password
Enjoy
Could you use security list-keychains -s ${HOME}/Library/Keychains/login.keychain inside the build process to explicitly add your login keychain to the search list? It seems like from the forked Terminal, the build process doesn't see your user keychain. That could make sense if the keychain search list is based on your current security session - a forked terminal session would leave the login session just as if you ssh over the loopback connection.
update for people running into similar issues with Jenkins:
If you set up your Mac to launch jenkins via LaunchDaemons, you need to make sure to add
<key>SessionCreate</key>
<true />
So the whole ci.plist would look like so:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>Jenkins</string>
<key>UserName</key>
<string>user</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/java</string>
<string>-Xmx512m</string>
<string>-jar</string>
<string>/path/to/jenkins/jenkins.war</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>EnvironmentVariables</key>
<dict>
<key>JENKINS_HOME</key>
<string>/path/to/jenkins/home</string>
</dict>
<key>SessionCreate</key>
<true />
</dict>
</plist>
I've been stuck wit the same issue as many people above have.
Specifically I experienced the issue when running from a Jenkins shell
script I got the same ** User interaction is not allowed ** error.
When running from an ssh shell, my script worked fine.
The difference that most people have also seen is that if you run
security list-keychain you'd get:
$ security list-keychain
"/Library/Keychains/System.keychain"
"/Library/Keychains/System.keychain"
But when running in the ssh shell, I'd get:
$ security list-keychain
"/Users/<i>user_account_name</i>/Library/Keychains/login.keychain"
"/Library/Keychains/System.keychain"
And most people will have all their keys/certs etc. in the user
account keychain. Like some folks suggested it's easy to make a new
key chain that is distinct from the user key chain, and reseve it for
your XCode signing stuff. I ended up putting mine here:
/Library/Keychains/sysiphone.keychain
I think the issue is that for my setup (and possibly for yours too),
you're running in a different security preference domain (system
vs. user). Finally -- here is how I got my sysiphone.keychain to show
up:
$ sudo security list-keychains -d system -s "/Library/Keychains/sysiphone.keychain"
Password: *****
$ security list-keychains -d system
"/Library/Keychains/sysiphone.keychain"
... and magically things started to build in Jenkins. Wow... that was
about 4 hours down the drain for me. Sigh.
Ok, the problem was two things for me, 1st was unlocking the keychain;
security unlock-keychain login.keychain
Second was (empty) passphrase,
security import blahblahbackup.p12 -k login.keychain -T /usr/bin/codesign -P ""
UPDATE:
A had a little problem later, when the script is triggered from a web script or sth. like that. It just sees /Library/Keychains/System.chain. So i found a dirty workaround (which may lead to security issues but ok for me);
setup pubkey ssh login (from user that wants to call build script, to actual user which has certificates and will run xcodebuild) in my case, it's same user. Apache is working as someuser and everything for build is setup on someuser.
and my php script (for triggering build) was calling ~/build-script. I've changed that like this:
ssh someuser#localhost ~/build-script
so it works in a real tty, and all keychain is accessible, everything works fine.
As another poster says,
security list-keychains -s "~/Library/Keychains/login.keychain"
But I think you only have access to the login.keychain when you are logged in, in the GUI context (I just tested on a system via SSH and screen, but which I also happen to be logged into via VNC).
It is apparently possible to use launchctl to select the GUI context and run the program, but I suspect that only works for the "logged in user" too.
If you try 'security show-keychain-info keychain-file' then you'll get the following error:
User interaction is not allowed
And that's a phrase to search with for some more info.
The other solution is to put the certificate into your System keychain!
I've looked at the security command an it appears that the keychains assigned to my terminal are not the same when forked. If I launched the security command in terminal I have:
$ security list-keychains
"/Users/yannooo/Library/Keychains/login.keychain"
"/Library/Keychains/System.keychain"
whereas when using screen I have the following output:
$ security list-keychains
"/Library/Keychains/System.keychain"
"/Library/Keychains/System.keychain"
Since my build certificates are stored in the login keychain, the code sign error I have looks normal.
Does anyone know how I could assign a keychain to a terminal? I've tried this without success
security login-keychain -s /Users/yannooo/Library/Keychains/login.keychain
Any ideas?
I am using Atlassian Bamboo 2.7 and OS X 10.7.3 Lion and I've tried every approach found in the thread but I was still getting the "user interaction not allowed" error.
The problem was that, in a remote terminal session (as "superuser" such as in the case of Bamboo or another automated build system), the keychain that needs to be unlocked containing the signing certificates are different from what you would normal see (such as was shown by Yann in here) when you are not superuser.
What ultimately worked for me was to do the following:
log in as System Administrator as described here
create the signing-only keychain (e.g., ios.keychain)
add the signing certificates to it (along with the WWDRCA certificate)
Verify it by going su and running security list-keychains on the terminal. You should see the ios.keychain among the list. (sudo security list-keychains won't show the same thing):
sh-3.2# security list-keychains
"/private/var/root/Library/Keychains/login.keychain"
"/Library/Keychains/ios.keychain"
"/Library/Keychains/System.keychain"
I've found that you still have to add ios.keychain to your search scope before doing the unlock-keychain command. In your build script, have the following lines run:
KEYCHAIN=/Library/Keychains/ios.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 bambooiphone $KEYCHAIN
Unlocking the login keychain did not work for me. Creating a separate keychain using Keychain Access (called iOS) and then adding these commands to the build did work (when running Jenkins as my own user):
security -v list-keychains -d system -s ~/Library/Keychains/iOS.keychain; security -v unlock-keychain -p password ~/Library/Keychains/iOS.keychain;
This looks more promising, though: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnotallowed
If you're running security list-keychains and seeing your custom keychain appear SOMEWHERE in the list but it still doesn't work, it could be that you're running into the issue I had whereby the keychains are checked in order from the search list, and since I wasn't unlocking login.keychain in my SSH session, it would fail there rather than move to the next keychain in the list, which was the custom one I wanted to unlock.
Setting the search list to a custom keychain which you unlock with security unlock-keychain works. Using this method from Yann's answer will also remove your login.keychain from the search list.
To preserve login.keychain:
security list-keychains -s ~/Library/Keychains/custom.keychain ~/Library/Keychains/login.keychain
This way, when using the GUI session at the machine you will still have access to login.keychain items, but code signing will check the custom keychain first, which succeeds if you've unlocked it.
If you're executing xcodebuild as root (which you are when you sudo), you need to log in as root and put your signing certificates in root's keychain. Then unlock the keychain with security as above.
I did:
delete login.keychain from list
create own keychain in $HOME/Library/Keychains/
add it to keychain list (I did not specify any specific domain)
set it as default
call security unlock-keychain on it
add global signing certificate (WWDRCA) to it
import private key and both Development and Distribution certificates to it
If there's login.keychain, I still get "User interaction not allowed" error.
Thus deleting login.keychain using security delete-keychain finally helped!