I am trying to switch on a certain keychain, and close another one.
I need this because our enterprise & appstore identities are called the same.
Right now, I do a "security unlock-keychain" followed by a "security default-keychain" to open the correct keychain and do a "security lock-keychain" on the keychain I wish not to use.
But xcodebuild still sees the entries in both keychains and gives up.
iPhone Distribution: Company name.: ambiguous (matches "iPhone Distribution: Company name." in /Users/user/Library/Keychains/login.keychain and "iPhone Distribution: Company name" in /Users/user/Library/Keychains/enterprise.keychain)
How do I prevent the system from finding the entry in the keychain that I lock?
You can tell Xcode which keychain to use:
xcodebuild "OTHER_CODE_SIGN_FLAGS=--keychain '$PATH_TO_KEYCHAIN'"
Or, if you call codesign directly:
codesign --keychain "$PATH_TO_KEYCHAIN"
If you use PackageApplication, there isn't a way to set this. However, PackageApplication is a pretty simple script that can be reimplemented if necessary (very useful if you're integrating with a larger system/script).
Solution:
I've put all the appstore related stuff in the login keychain, and the enterprise stuff in a seperate keychain file.
In the buildscript, I switch between those as follows:
# 1. Only activate the System and either the Appstore(=login) or Enterprise keychain.
security list-keychains -s $KEYCHAIN_NAME $SYSTEM_KEYCHAIN
# 2. Loop through App Schema's
for APP_SCHEME in ${APP_SCHEMES[#]}; do
echo "--= Processing $APP_SCHEME =--"
xcodebuild -scheme "${APP_SCHEME}" archive
done ### Looping through App Schema's
# 3. Restore login & system keychains
security list-keychains -s $APPSTORE_KEYCHAIN $ENTERPRISE_KEYCHAIN $SYSTEM_KEYCHAIN
Another solution for xcode version 6 and below: specify your certificate by SHA1 instead of by (ambiguous) name. From "man codesign":
If identity consists of exactly forty hexadecimal digits, it is instead
interpreted as the SHA-1 hash of the certificate part of the desired iden-
tity. In this case, the identity's subject name is not considered.
And from "security help find-certificate"
-Z Print SHA-1 hash of the certificate
Unfortunately, this method requires using the PackageSign script, which has been deprecated in Xcode 7
Related
I tried to code sign an iOS application,
These are the steps that i followed
security create-keychain -p password ${KEYCHAIN}
security set-keychain-settings -u -t 300 ${KEYCHAIN}
security list-keychains -d user -s login.keychain ${KEYCHAIN}
security import "$1" -k ${KEYCHAIN} -A -P "${PASSPHRASE}" -A >/dev/null
security unlock-keychain -p password ${KEYCHAIN}
/usr/bin/codesign -f -s $IDENTITY --keychain $KEYCHAIN --entitlements $ENTITLEMENTS Payload/Test.app
This returned me Codesign returned unknown error -1=ffffffffffffffff via ssh.
If i directly execute the code sign command in the machine, it's successfully signing.
The issue is only in Mac OS Sierra.
Had the same problem a while ago, adding
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k password ${KEYCHAIN}
solved it for me.
Got the same issue but while archiving directly from Xcode.
Sharing the solution in case it helps.
Sometimes, Keychain seems to end up in a corrupted state. Using MacOS Sierra too.
Symptoms :
Relogin needed to access Accounts after restarting Xcode
Prompting for password while using Keychain Access for some operations
Keychain Access - Error while accessing login keychain via Change Settings for Keychain ...
What fixes it for me is locking and unlocking (password required) the involved Keychain, login in my case.
I am going to chip in as well as I had to try a few more things than the ones mentioned here: the problem was that keychain doesn't like SSH sessions. I had to execute these in my session to fix it:
security unlock-keychain -p MY_PASS ~/Library/Keychains/login.keychain
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k MY_PASS ~/Library/Keychains/login.keychain
security set-keychain-settings ~/Library/Keychains/login.keychain
I've also removed my current certificates system/account certificates by removing my account from XCode (I use fastlane to do building) but I suspect that this shouldn't have impacted it.
#madhu I have been trying to fix the same issue and found that Access Control for the key associated with the certificate in question was set to "Confirm before allowing access" which didn't work in Jenkins. I modified it (thru Keychain Access gui - Get Info, Access Control) to "Allow all applications to access this item" and my build was successful.
You might have exported some file like p12 from KeyChain, and when OS asked for your root password, and you denied it, then Xcode will code sign error with this info.
If this maybe so, you should repeat the above action, input your password and click allow, and then it will be ok to code sign.
This happens in a headless build because the prompt for key access cannot be shown or responded to. The solution is to prevent that prompt from showing by granting access to the key in advance.
Open Keychain Access, find the key for your signing certificate (login-> Certificates, then expand the certificate to reveal its key). Right-click on the key and select: Get Info -> Access Control, and select "Allow all applications to access this item".
I've tried almost all the existing suggestions over the web, none of them helped...
Finally only re-generating the Provisioning Profile (for AdHoc), re-downloading it and placing it to ~/Library/MobileDevice/Provisioning Profiles/ overwriting the existing one saved my life.
By the way, AppStore build was successful all this time, so the issue was definitely in the AdHoc profile itself (pretty strange, since it looked nice by all means).
Even though we installed the right certs in the keychain and the right Provisioning Profile under ~/Library/MobileDevices/Provisioning Profiles.
We may also see
unknown error -1=ffffffffffffffff
For this error, I tried the below steps to fixed the issue:
Reboot the machine, unlock keychain using "securify unlock-keychain", lock the keychain again
Remove ~/Library/Developer/Xcode/DerivedData folder.
Run carthage bootstrap --platform iOS
Open the source code syncing down workspace, run "xattr -rc ." then open the .xcodeproject file in xcode.
Turned on the automatic signing for each target. Need to login with valid credentials.
Click on the provisioning profile under signing.
unlock the keychain again
Changing the build device to Generic Devices, under Product --> Clean, then Product –> Archive
There will be a keychain access allow showed up, click "Always Allow".
You should make sure the archive is successful then trigger the Jenkins job again.
Scenario:
I have a .pkg file that needs to be signed using TeamCity after our TeamCity build has completed.
Ideally this could be a build step or script that runs at the end. After research, I tried the following:
Script INPUT:
security import applicationkey.p12 -k login.keychain -P "password"
security import installerkey.p12 -k login.keychain -P "password"
security -v unlock-keychain -p "password" /Users/administrator/Library/Keychains/login.keychain
security -v unlock-keychain -u /Library/Keychains/System.keychain
productsign --keychain /Users/administrator/Library/Keychains/login.keychain --sign 'Developer ID Installer: Company LLC' CompanyInstaller.pkg CompanyInstallerSigned.pkg
pkgutil --check-signature CompanyInstallerSigned.pkg
OUTPUT:
unlock-keychain "-p" "mypassword" "/Users/administrator/Library/Keychains/login.keychain"
unlock-keychain "-u" "/Library/Keychains/System.keychain"
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: Company LLC" from keychain /Users/administrator/Library/Keychains/login.keychain
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
2016-10-05 14:57:11.484 productsign[9385:29611120] SignData failed: CSSMERR_CSP_NO_USER_INTERACTION (-2147415840)
Error signing data.
productsign: error: Failed to sign the product.
QUESTION:
I've noticed many solutions to this mentioning to click the "Always Allow" from the dialog prompt the first time it appears in reference to the Keychain's Access Control, however my only known interaction with this build agent is through SSH. Is there a means to sign a .pkg using productsign on Teamcity mac build agent without gui interaction with this "Always Allow" prompt? Or, is there a way to login to the build agent and view a gui so I could click on this "Always Allow" to enable this?
Note: I've also tried saving the (local signing machine) private key's Access Control to "Allow all application to access this item", exported it, imported it to the build agent's login.keychain, then tried the above again, to only have the same output. When I do the same process on my macbookpro, everything works, however I do not recall if I did click "Alway Allow" from long ago.
Any thoughts? Much appreciated.
We ran into this problem as well - we are using TeamCity to sign packages on a Mac build agent.
The first time we set up the build agent, we imported the certificate into the keychain and granted the 'always allow' permission; this seemed to work. At some point the build agent was rebooted and then signing packages no longer worked, whatever we tried with permission & trust settings. We kept getting the SignData failed: CSSMERR_CSP_NO_USER_INTERACTION error.
We fixed this (hopefully for good!) by moving the certificate into the 'System' keychain (it was previously in the 'login') keychain. We didn't need to change our call to productsign at all - it picked up the system keychain correctly. I imagine that if you had the certificate in both keychains then you would need to tell productsign which keychain to use (--keychain ...).
All of a sudden, with no change to the Xcode build server, I started getting an error, even across different bots, branches, and apps (all are Mac apps). I didn't change any software or configuration on the build server (that I know of), or even sign into it. I get the error once during analysis:
Check dependencies
Code Sign error: Multiple matching codesigning identities found: Multiple codesigning identities (i.e. certificate and private key pairs) matching “Mac Developer: OS X Server (N________L)” were found.
And again during Testing (though my tests pass – the one above is what fails the build):
Testing failed:
Multiple matching codesigning identities found: Multiple codesigning identities (i.e. certificate and private key pairs) matching “Mac Developer: OS X Server (N________L)” were found.
I have tried the following, triggering a build after each step, with no change in the message:
Triggered another build
Updated to the latest Xcode on the build server (6.3.2)
Searched through Keychain Access for any "OS X Server" certificates or keys, finding none
Removed all Developer Teams from Server.app. Note: this acted weird. I had to remove it twice before the setting read "No Teams", but now it's stayed that way
I signed in to add my team again
Removed it again, which still had to be done twice before it "stuck"
Restarted the machine, multiple times
Removed all provisioning profiles from /Library/Developer/XcodeServer/ProvisioningProfiles
Signed in with my developer account again after removing the provisioning profiles. They have been recreated, but the error remains
I turned off "Perform analyze action" in the bot, which did get rid of the message, but turning it back on, or turning on "Perform archive action", reintroduce it, so that's not an option (also, I want static analysis performed, which is why it's turned on in the first place).
Assuming for the moment that Xcode Server's list of signing identities is corrupted, how would I go about resetting them, outside of Server.app (since I already removed the Development Team there)? I found a couple of directories that seem like candidates for some troubleshooting and/or backup restoration, but I'm hesitant to mess around without knowing for sure what they're for.
/Library/Developer/XcodeServer/Certificates
/Library/Developer/XcodeServer/Keychains
I noticed that my provisioning profiles all expire on May 20, 2016. This means my old ones expired two days ago (5/20/2015), which was between my last successful (5/19) and first failed (5/21) builds.
So now, knowing the source of these failures, the problem now becomes: how do I clear out the old provisioning profiles (or certificates, etc.) that are causing the duplicates?
The server is up-to-date on Yosemite (10.10.3), Server (4.1), and Xcode (6.3.2).
Update
I'm trying to list codesigning identities, but can't get even a single "Mac Developer: OS X Server" to show up, let alone multiples. These are the commands I've tried, which only list the non-Server identities in the keychain:
security find-identity -p codesigning
sudo -u _xcsbuildd security find-identity -p codesigning
sudo -u _xcsd security find-identity -p codesigning
It looks like a bug in Server did in fact introduce a duplicate signing identity. I reported it as rdar://21080937, if you'd like to dupe it.
In order to fix it, I had to learn about how Xcode Server stores signing identities (thanks entirely to an extremely helpful answer to an unrelated question).
Xcode Server stores Developer Program certificates in
/Library/Developer/XcodeServer/Keychains/Portal.keychain
Following the steps below, I was able to open the keychain, find the duplicate, remove it, and put it back. These steps are adapted from the answer linked above.
Sign out of the Developer Portal from Server.app by removing the developer team you're having issues with
Copy the Portal keychain to your desktop:
> sudo cp /Library/Developer/XcodeServer/Keychains/Portal.keychain ~/Desktop/
Password: your-administrator-password
> sudo chown `whoami`:staff ~/Desktop/Portal.keychain
Set the Portal keychain password to “123”
> security set-keychain-password -o "`sudo cat /Library/Developer/XcodeServer/SharedSecrets/PortalKeychainSharedSecret`" ~/Desktop/Portal.keychain
New Password: 123
Retype New Password: 123
Open the Keychain in Keychain Access:
> open -b com.apple.keychainaccess ~/Desktop/Portal.keychain
Unlock the “Portal” keychain using password “123”
Find the duplicate keys with the name listed in the error
Remove one (I picked the one modified less recently, but it may not matter)
Lock the “Portal” keychain, quit “Keychain Access”
Reset the Portal keychain password:
> security set-keychain-password -p "`sudo cat /Library/Developer/XcodeServer/SharedSecrets/PortalKeychainSharedSecret`" ~/Desktop/Portal.keychain
Password: your-administrator-password (optional step)
Old Password: 123
It may or may not ask you for your administrator password again, pay attention to the prompt.
Backup the original keychain
> sudo cp /Library/Developer/XcodeServer/Keychains/Portal.keychain /Library/Developer/XcodeServer/Keychains/Portal.keychain.old
Copy the Portal keychain back
> sudo cp ~/Desktop/Portal.keychain /Library/Developer/XcodeServer/Keychains/
Fix the new keychain's permissions
> sudo chown _xcsbuildd:_xcs /Library/Developer/XcodeServer/Keychains/Portal.keychain
Since the system caches open keychains, restart the server
Add your developer team back, in Server.app
Run a build, verifying everything looks good. If so, remove the backup copies of the keychain
> rm ~/Desktop/Portal.keychain
> sudo rm /Library/Developer/XcodeServer/Keychains/Portal.keychain.old
I have a Bamboo plan which builds a package, and I want to sign that package with my developer certificate. In my build script, I have this:
productsign --sign "Name of my certificate" "input.pkg" "output.pkg"
Running this script from the command line works as expected. However, running the script from Bamboo, I always get the error:
productsign: error: Could not find appropriate signing identity for "Name of my certificate"
I presume this must be because of the context that the build script is run in when run from Bamboo. How do I make the certificate usable in Bamboo? It is installed in System, not login.
If you need to run Bamboo as root, then you'll need to copy the appropriate certificates from your login keychain to your System keychain using Keychain Access (Applications > Utilities).
Having said that, it would probably be better to run Bamboo as a user instead of root. E.g. if you need to use mobile provisioning profiles to sign any iOS builds on the same server, being root will not work.
Have you tried sudo'ing the operation?
I.e.:
sudo productsign --sign "Name of my certificate" "input.pkg" "output.pkg"
As the key is in the System keychain (which maybe it shouldn't be for your use case?), you likely don't have access to it as a 'regular' user, even though [by design] you have access to the certificates in it.
My recommendation is to store the keys you need in a separate keychain. That will make it much easier to find them and manage them. Just create a new keychain and move your cert into it; store it somewhere convenient. Then I sign things this way (I'm using codesign, but --productsign is the same). I do not build as root, nor do I use sudo for this.
# Keychain that holds all the required signing certificates
# To create a keychain like this, create it in "Keychain Access" and copy all your certificates into it
# Then set its timeout to infinite (so it doesn't re-lock itself during the build):
# security set-keychain-settings <path>
# Passing no "-t" option means "no timeout."
# Generally you should just be able to copy this file from build host to build host as needed. Then
# add it to the available keychains using Keychain Access, File>Add Keychain…. If you don't add it to
# Keychain Access, you'll receive signing error CSSMERR_TP_NOT_TRUSTED, since it won't recognize the
# entire chain
keychain=~/Library/Keychains/MyProduct.keychain
keychain_password=somepassword # If you have one on the keychain
cert_identifier='My Signing Name'
...
# We assume the keychain has an infinite timeout, so we just unlock it once here.
if ! security unlock-keychain -p "${keychain_password}" ${keychain} ; then
echo "Cannot unlock keychain. Cannot sign on this host."
exit 1
fi
sign()
{
name=$1 ; shift
paths=$*
if ${sign} ; then
echo "** SIGNING $name **"
chmod u+w $paths
codesign --keychain ${keychain} -f -s ${cert_identifier} $paths
fi
}
sign "The Whole Package" something.pkg
I am trying to create automated build for Xcode.
Till now everything is working just fine.
For building the project from command line I am using this command
xcodebuild –project {“xcode_project file path”}–target {“target_name”} –sdk iphoneos –
configuration Release clean build CODE_SIGN_IDENTITY={$distribution_signing Identity}
PROVISIONING_PROFILE={UUID for provisioning profile}
I want to fetch the UUID and CODE_SIGN_IDENTITY dynamically,
for UUID I am doing
UUID=$(grep "<key>UUID</key>" "$PROVISIONING_PROFILE_PATH" -A 1 --binary-files=text | sed -E -e "/<key>/ d" -e "s/(^.*<string>)//" -e "s/(<.*)//")
Above script code gives me the UUID of any provisioning profile.
I am stuck at getting the CODE_SIGN_IDENTITY dynamically.
I know it is of the form like iPhone Distribution: Developer name
How do I extract iPhone Distribution: Developer name from a .p12 file.
You can use the security find-identity command-line utility to list the available codesigning identities on your system:
/usr/bin/security find-identity -v -p codesigning
1) F188B6FD76D83316FCB2E594940XXXXXXXXXXXXE "Mac App Distribution"
2) ADDB5E33AC36FEB2CA0F1C3BC71XXXXXXXXXXXXE "iPhone Developer: Stuart M (xxxxx)"
2 valid identities found
The -v option limits the list to only "valid" identities, and -p codesigning filters it to only codesigning identities, in case you have multiple.
This bit of Python works for me. I didn't have to install anything extra to run this on a Mac.
# load everything. Probably not the best idea in production...
from OpenSSL.crypto import *
p12 = load_pkcs12(file("./path/to/your.p12", 'rb').read(), 'YOUR_P12_PASSWORD')
print(p12.get_friendlyname())
Credit to this answer: Python: reading a pkcs12 certificate with pyOpenSSL.crypto
For those who don't know how to run security find-identity command as mentioned on #Stuart M answer here is how to do it: -
xcrun security find-identity -v -p codesigning