I just got my certificate installed on a Mac OS X 10.7 and wrote a script that runs codesign on a number of files after compiling my project. I created a new keychain and disabled the option for locking it after a certain period of time. It looks like the login keychain. But every time my script runs the codesign command the following error occurs: <filename>: User interaction is not allowed. If I start a shell, unlock the keychain with security unlock-keychain <path> and then run the script manually, it works. The question is how to keep the keychain always unlocked so that my automatic build can sign the files?
When you use security unlock-keychain -p $PASSWORD $KEYCHAIN the keychain will be unlocked, but, for only 5 minutes, due to an automatic relock. To keep the keychain unlocked permanently you need to use security set-keychain-settings $KEYCHAIN.
For completeness of this answer, I would also recommend that you use security import $CERT -k $KEYCHAIN -P "$CERTPASSWORD" -T /usr/bin/codesign to grant /usr/bin/codesign access to your certificate.
Late reply but as 2022 - Monterey could not get it to run, testing all answers and commands here.
My issue was, the certificates were in the System Toolchain. Looks like in this case there is no way to skip the admin password prompt, even if you lock, unlock, set timeouts ....
Tried moving them from System to login => did not work, there was a private key that did not refresh
Lastly, I used "reset keychain", that deletes everything from local and login keychain. Then I imported the certs again, this time into the login keychain. Restarted the computer and it worked.
A useful command is security find-identity, you can use to display if the moved key to the Login keychain has been detected.
After these steps I can finally sign files without any password prompt.
Related
Connected via ssh and executing:
xcrun altool --notarize-app --primary-bundle-id com.example.app --username exam#ple.com --password #keychain:AC_PASSWORD --file app.dmg
results in:
2019-04-17 16:06:53.146 altool[4331:55219] *** Error: User interaction is not allowed.
The password has been stored in a temporary keychain with:
security add-generic-password -a "exam#ple.com" -s "AC_PASSWORD" -p "myPassword" -A "temp.keychain"
codesigning works with the temporary keychain trick: https://apple.stackexchange.com/questions/255872.
During creation of the temporary keychain, the AC_PASSWORD password item is added with the above command.
Executing the same command locally on the machine works.
I also tripped on this exact same issue. I think the solution can be found in this answer.
Specifically:
The first time you run altool, you get a security confirmation dialog asking you whether to allow altool to read the password. Enter your keychain password and click on Always allow.
You will need to login interactively and run the altool command as you would over ssh. When the confirmation pops, enter the keychain password and click "Always allow". You only have to go through this once after adding the password to the keychain.
I had a similar issue, getting the same error when using SSH to run security import for a cert. I'm working on scripts that should be able to run over Ansible without user interaction, so I want to avoid one-time manual steps for each script.
You don't know which information the tool is trying to prompt for (password, passphrase, etc.) because the error is generic, so by connecting over VNC for an interactive session and then running the command manually in Terminal, you can see see the prompt and learn what the problem is. (For me, a missing certificate passphrase.)
Related post: Xcode, Codesign Error from Jenkins / SSH - "User Interaction is not allowed"
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.
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
Our automated build is running on Jenkins. The build itself is running on slaves, with the slaves being executed via SSH.
I get an error:
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
I have tried every suggestion I have seen so far in other posts here:
Using security unlock-keychain immediately before signing to unlock the keychain.
Moving the signing key out into its own keychain.
Moving the signing key into the login keychain.
Moving the signing key into the system keychain.
Manually setting list-keychains to only the keychain which contains the key.
In all cases, I get the same error.
In an attempt to diagnose the issue, I tried running the "security unlock-keychain" command on my local terminal and found that it doesn't actually unlock the keychain - if I look in Keychain Access, the lock symbol is still there. This is the case whether I pass the password on the command-line or whether I let it prompt me for it. Unlocking the same keychain using the GUI will prompt me for the password and then unlock it. Additionally, if I run "security lock-keychain", I do see the key lock immediately after running the command. This makes me think that unlock-keychain doesn't actually work. I experience the same behaviour on Lion (which we're using for the build slaves) and Mavericks (which I'm developing on.)
Next, I tried adding -v to all the security commands:
list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
"/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.
From this, it would seem that list-keychains is what isn't working. Maybe neither work. :/
There is a similar question here. The solution is interesting - set "SessionCreate" to true in launchctl. But I'm not building on the master - my build process is started from SSH on a slave build machine. Maybe there is a command-line way to do what launchctl is doing when you run "SessionCreate"?
I too have been fighting this. Nothing helped until I tried the suggestion on http://devnet.jetbrains.com/thread/311971. Thanks ashish agrawal!
Login your build user via the GUI and open Keychain Access. Select your signing private key, right-click, choose Get Info, change to the Access Control tab and select the "Allow all applications to access this item".
Well, I guess I get to answer my own question today, because after stabbing at it over two and a half days, one of the things I tried seems to have worked. I'm just going to back away from it now and hope it keeps working.
Essentially, it looks like it comes down to -d system not actually working. So a lot of answers to other questions around here should probably be updated to reflect that.
security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
--resource-rules src/AppResourceRules.plist --timestamp --verbose \
"$APP"
Using Security to create a Keychain for /usr/bin/codesign
Importing the certificate and having it work with codesign programmatically isn't a matter of using login or System keychains or praying to some god of codesign. You just need to have the correct permissions set. I recommend creating a new keychain specifically for codesign purposes.
These days to get codesign to not yield an errSecInternalComponent you need to get the partition list (ACLs) correct. I'll walk through the steps:
Create the Keychain
security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
at this point the keychain is unlocked but won't appear in Keychain Access.
Add the new Keychain to the search list
security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[#]}"
Add the new Keychain to the list. If you don't first grab out the original list from list-keychains you'll no longer have login.keychain in your search-list.
Unlock the keychain
security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
This is redundant if you created the Keychain above, but if the Keychain already existed it is necessary.
Remove the defaults from the Keychain
security set-keychain-settings "${TESTING_KEYCHAIN}"
By not specifying any arguments this will set the auto-lock timeout to unlimited and remove auto-lock on sleep.
Import your signing certs from a .p12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
Import the certs and gives codesign access through the -T option.
Set the ACL on the keychain
security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
This is a requirement that many people miss. You can see what macOS does by using dump-keychain. Which in the case of codesigning requires apple: and apple-tool:. -s refers to signing certificates.
Where's my signing certificate?
Always a good idea to make sure you can find your certificates
security find-identity -p codesigning -v /path/to/keychain
Gitlab-Runner, Jenkins and the like
One very important thing for any CI-type runner or build system is to make sure the process is started from launchd correctly. Make sure your plist contains <SessionCreate> </true>.
Not correctly matching the the owner of the keychain with the build process and making sure a security session is created will result is all sorts of headaches. Diagnostically speaking you can introduce list-keychains and see if the output matches your expectations.
This is from the launchd.plist man-page:
SessionCreate <boolean>
This key specifies that the job should be spawned into a new security
audit session rather than the default session for the context is belongs
to. See auditon(2) for details.
UserName <string>
This optional key specifies the user to run the job as. This key is only
applicable for services that are loaded into the privileged system
domain.
GroupName <string>
This optional key specifies the group to run the job as. This key is only
applicable for services that are loaded into the privileged system
domain. If UserName is set and GroupName is not, then the group will be
set to the primary group of the user.
Example /Library/LaunchDaemons/com.company.gitlab-runner.plist
<?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>com.company.gitlab-runner</string>
<key>SessionCreate</key><true/>
<key>KeepAlive</key><true/>
<key>Disabled</key><false/>
<key>UserName</key>
<string>bob</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/opt/gitlab-runner/bin/gitlab-runner</string>
<string>run</string>
<string>--working-directory</string>
<string>/Users/bob/gitlab-runner</string>
<string>--config</string>
<string>/Users/bob/gitlab-runner/config.toml</string>
<string>--service</string>
<string>gitlab-runner</string>
<string>--syslog</string>
</array>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>
</dict>
</plist>
Register the runner
gitlab-runner register \
--non-interactive \
--tls-ca-file "{{ gitlab_runner_dir }}/certs/git.company.com.crt" \
--config "{{ gitlab_runner_dir }}/config.toml" \
--builds-dir "{{ gitlab_runner_dir }}/builds" \
--url "{{ gitlab_ci }}" \
--registration-token "{{ gitlab_token }}" \
--name "{{ computername }}" \
--tag-list "{{ gitlab_runner_tags }}" \
--output-limit 16384 \
--executor shell \
--shell bash
Finally codesign
You can lookup the signing certificates hash using find-identity
security find-identity -p codesigning -v
Before beginning signing Xcode sets the environment variable CODESIGN_ALLOCATE to use the codesign_allocate that comes with Xcode, not in /usr/bin.
export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"
Codesign a framework, dylib, etc.
If you're codesigning manually, start with the frameworks and dylibs and after they are all signed, then sign the .app. Or in other words - you codesign from the bottom up.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codesign the app bundle
After all the other signables are signed, sign the .app itself. In theory, you could do this all in one go with --deep, however, you would still need to make sure your app has entitlements and possibly other flags.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Flag passed to all items:
--timestamp=none disable timestamps
Other flags to the app signing step:
--entitlements /path/to/entitlements.xcent new entitlements
--preserve-metadata=entitlements keep current entitlements
New codesign requirement - DER encoded entitlements
Apple has recently started requiring entitlements to not be embedded only in plist form, but also in DER encoded form. If you are using an older Mac/Xcode you might encounter the error...
The code signature version is no longer supported
None of the other answers worked for me.
What eventually saved me was this post
To sum it up, this can be caused by a default timeout of 5 minutes, that will trigger this error after a long build.
To fix:
security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain
Try to call security unlock-keychain and codesign as an one-line command. This helped me. Something like:
security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>
Put your keys in the System keychain
So this is the command that works. -A is to prevent Mac from asking password. Importing to system.keychain doesn't require an GUI.
sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
My keychain was locked. It resisted my advances to change that fact...
Keychain Access -> Keychain First Aid -> Repair, et voilá!
Unlocking the keychain is not enough. You also have to set the private key access to "Allow all apps to access this item". And to do that from command line requires reimporting the key. So to take things at a time:
Unlock the login keychain if it is locked. It shouldn't be locked though, but anyway here's how you do that:
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"
If for some reason your build machine has the login keychain locked, and you don't want to expose that password in a script, then you should use a different keychain. You can create one on the spot and use that in the previous and the following command. To create one on the spot:
security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain
Then import your certificates and associated private keys into the login keychain using the -A parameter. Note that you don't need to sudo for all this...
security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A
The -A parameter is what will make your private key to be set to "Allow all apps to access this item"
So using all these you should be able to make a script that installs the required certificate to build a release ipa and sign it without prompt. You can store the .p12 file in your repo, so any machine can build your ipa without requiring manual setup.
Apart from unlocking keychain (as mentioned in another answers), you need to allow access from all applications to Xcode authentication token in keychain:
Select "login" keychain
Select "All Items" category
Search for "xcode" keyword
Select "Allow all applications to access this item" for all Xcode tokens
Don't forget to add unlock keychain step (from previous answers)
Import your keys to System keychain. You can use this command:
sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
So I tried every answer here and something wasn't quite adding up. Finally I figured out when I rebooted my CI service, it was running under a different user than I had expected. Changing to the user that actually had access to the key in their login chain fixed everything. This may not be a common problem, but wanted to document my specific reason for this error, in case it happens to others.
For me nothing worked seems have to reinstall Xcode all over again. Jenkins keeps giving the same error.
You would save lot of time if you just move Xcode installation to Trash and reinstall. Ensure you run the codesign command from command line atleast once.
Even after if you get the same error try setting 'Unlock Keychain?' property within Jenkins and give path to your login.keychain under /Users/${USER}/Library/Keychains/login.keychain
I hope god be with you after that.
In my case, this was caused by a keychain being created with a default timeout of 300s and a long xcode compile lasting more than 300s. The workaround, for me, was to invoke:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
immediately after creating the temporary keychain.
I ran through all these suggestions and was still having problems using fastlane's gym in a Jenkins job. I had the certificate installed and keychain unlocked, and was able to codesign on the slave when I manually ran the codesign command on the command line.
As a workaround, if Jenkins connects to the slave using JNLP instead of SSH, you'll be able to codesign.
For me it happens when there is a second keychain added manually and it's locked. For some reason codesign tries to access the locked keychain and fails even though the certificates are in the login keychain (and is unlocked). Unlocking the second one solves the problem. Just doesn't make sense to me.
After trying a number of the above solutions. I realized that one factor I had, was that I was starting the build using the ION Console. When I switched back to making the build from the Terminal app, everything worked just fine.
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