I am trying to add new provisioning profile to my Xcode, to test an app on the device. Here are the steps I followed:
Deleted all certificates and provisioning profiles
Create/Add IOS Dev Certificate
Add My IOS Device Online
Create IOS Provisioning Profile
Add IOS Provisioning Profile
Clean App
Build Then Run App
Set Codesigning nd Provisioning Profile In Build Settings
Lots of Googling > to no successes
Here is the error I get:
CSSM_SignData returned: 800108E6
/Users/alexpelletier/Library/Developer/Xcode/DerivedData/MyExpense-efnqzvoqwngzcmazaotyalepiice/Build/Products/Debug-iphoneos/MyExpense.app: errSecInternalComponent
Command /usr/bin/codesign failed with exit code 1
Open Keychain Access, then in the File menu select Lock All Keychains.
Then go back to Xcode and clean and rebuild. It will prompt you for your password again to unlock the keychain.
After this, assuming you have no other compile issues, it will succeed!
This occurs when the login keychain is locked. To unlock the login keychain, run:
security unlock-keychain login.keychain
If your keychain is password-protected, specify the password using the -p option:
security unlock-keychain -p PASSWORD login.keychain
If you're using a continuous integration system, you'll likely want to inject the password via an environment variable/token, which most CI systems offer in their settings.
The error code in question is described in Apple's docs as an internal error, so it's entirely possible this occurs in other cases too.
It seems like a bug in the code signing mechanism, restarting your mac should solve the problem
Had the same issue on High Sierra/Xcode 9.4.1, all attempts to sign ended in errSecInternalComponent
Go to Keychain Access
Go to the login keychain
Select the category "My Certificates"
Find the certificate you're signing with and expand it to see the key.
Double click the key
Go to the "Access control" tab.
Update key access control to "Allow all applications to access this item"
Alternatively:
run codesign command on mac terminal and "Always allow" /usr/bin/codesign access to key
If trying to sign from ssh/CI you also need to run
security unlock-keychain login.keychain
before trying to sign app bundle
I have met the same problem, I restart my macOS,and it works.
In China,we have a saying between developers:
Little problems,just restart.Big problems,should reinstall.
Sometimes,the above saying will greatly help you!
In case it helps someone else, I encountered an errSecInternalComponent error with codesign because I was running it over an ssh session to my macOS machine. Running the same command from a terminal window on the macOS machine itself worked.
Presumably this is because codesign needs access to the private key from the login keychain.
Running security unlock-keychain login.keychain (as explained by cbracken's answer) from the same session also should work.
As pointed out by #Equilibrium in one of the comments, if you are in command line env. like Jenkins(my case), you might need to pass the password to the security-unlock command mentioned in the solutions.
So instead of using,
security unlock-keychain login.keychain
use:
security unlock-keychain -p <login-keychain-password> <path-to-login-keychain>
where path-to-login keychain can be $HOME/Library/Keychains/login.keychain(my case) or simply login.keychain
for anyone that encountered this issue from jenkins and ssh:
high possibility that you have not granted access to the private key in keychain, i tried but not sure why all of these are not working:
security import .p12 file with -A or -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k #{password} #{keychainPath}
change all provisioning profile to [UUID].mobileprovision and copy them to '~/Library/MobileDevice/Provisioning\ Profiles' on jenkins server
clean derived data and reboot jenkins server
make sure default keychain is login keychain and unlocked it.
finally resolved by:
1.ssh [user]#[jenkinsServerIP] -L 5900:localhost:5900, log into jenkins server
2.open 'vnc://localhost'
this will launch a remote screen, if your jenkins server allow this...
then open keychain.app to grant access of /usr/bin/codesign to the private key
good luck
Nothing work for me from the above Solution.
Fallowing Solution Work for me...
First Open Keychain Access
Then Select Login And click Certificates
Double click Apple Worldwide Developer Relations Certificate Authority
Open trust section, and set to "Use System Defaults" from "Always Trust"
Clean the build folder and run
I ran security unlock-keychain login.keychain and my login password didn't work. So I rebooted, and then just ran Xcode again and it worked. Running the command works as well. Strange issue.
If trying to sign from ssh run command:
security unlock-keychain login.keychain
before trying to sign app bundle
or from UI
Update key access control to "Allow all applications to access this item"
Thx to #Equilibrium and #Jon McClung
I had the same issue Found out the problem is with code signing the app.
Opened the developer account and accepted the updated agreement and it worked.
Right clicking on the private key associated with the codesigning cert in the keychain, and then clicking on 'allow all applications' instead of relying on a prompt fixed it for me, since the build was happening via ssh.
I had to:
1) delete the certificate associated to the project
2) Back to the Xcode and revoke the app certificate
3) The Xcode require a new certificate
4) Lock all KeyChain
5) Clean the project
6) Rebuild
That's it. Hope it helps to anyone.
If you get errSecInternalComponent after
Warning: unable to build chain to self-signed root for signer …
, you might have the wrong Apple World Wide Developer Relations root certificate in your keychain. In this case, make sure that you import the WWDR certificate with which your developer certificate was signed. I imported the WWDR certificate expiring in 2023 and two hours later finally realized that it didn't work because my developer certificate had been signed with the WWDR certificate expiring in 2030 (AppleWWDRCAG3.cer). Download page: https://www.apple.com/certificateauthority/
Posting a work-around that we finally had to resort to, in case someone else is running out of things to try...
After installing a new Apple Distribution certificate in our "login" keychain, our Jenkins job suddenly started to fail singning iOS apps with the same errSecInternalComponent error:
Command /usr/bin/codesign failed with exit code 1
Our build pipeline calls security unlock-keychain, and we have no problems with our Enterprise Distribution cert (which was coincidentally updated and installed in the same Keychain just a few weeks prior), where the unlocking works as expected.
After trying all the usual things mentioned in this thread and elsewhere, we ended up running codesign manually as the Jenkins user in a new Terminal window, taking the exact same command as found in the Jenkins log: /usr/bin/codesign --force --sign...
This prompted entering the password to unlock the Keychain, which we did, and then selected "Always Allow".
After that Jenkins manages to sign (as expected).
This is obviously a bit of a work-around since we might have to do this again when the cert has expired, and it's really strange that unlocking works for Enterprise certs, but not the cert used for distributing through App Store... They literally share the same pipeline.
Just try it once using mac terminal but not from ssh session
security unlock-keychain login.keychain
And choose always allow in the prompted dialog.
And then you could xcodebuild in the remote session.
The above methods are useless to me.
I resoled it by:
Open keychain access.
Click Login Menu.
Remove all personal certificates.
Clean the project.
Rebuild.
That's it. Hope it helps to anyone.
In my case, this solved.
xcode -> preferences -> accounts -> select the account -> manage certificate -> (+) in bottom left -> Apple development
Ref: https://stackoverflow.com/a/62646138/234110
In my case BUCK was trying to sign the IPA for development, but there were not any development certificates installed. Changing the build config to release (this is what I needed - to build for iTunes) fixed it for me.
Just wanted to callout if someone face similar issue what I did. In my case my apple dev and distribution certificates, keys and provisioning profiles where upto date. My iOS code build was working in user mode without any issue however it does not work due to code sign issue when the code build runs with root privileges i.e. % sudo or invoking the Xcode using sudo through command line.
So, I copied the corresponding working certificates and keys the login to the system location in the keychain tool. Then it started working without any code sign issue.
Similarly, we can export the required certificates, keys for build from the working machine and import those into non working machine's keychain tool may solve the issue.
For me, I was able to sign files when using the Mac directly or via VNC, but not via ssh. I figured it must be something to do with access to the certificate within the keychain. I was already doing a security unlock-keychain [keychain name] but this didn't appear good enough.
What finally fixed it for me was (within a direct/VNC connection, not ssh):
Make sure the keychain in which your certificate resides is locked. Close Keychain Access.
Open Terminal
Do not run security unlock-keychain [keychain name].
Run a signing process using codesign tool. You will be challenged for a password to the keychain.
Enter the password and click "Always allow"
From now on I was able to use codesign via ssh, so long as I included security unlock-keychain [keychain name] before the command.
If you have a code signing certificate with the same name in the keychain, make sure you remove it. I had one which XCode reported as "Missing private key". I had to remove it via Keychain Access before the correct certificate was used by codesign.
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.
I have Jenkins CI set up on Mac Sierra to build iOS apps using Xcode 8.2 with automatic signing. All works well when building using Xcode as the developer. However, Jenkins using xcodebuild is failing with the following:
SecKey API returned: -25308, (null)/Users/Shared/Jenkins/Home/workspace/App/build/Build/Intermediates/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/App.app/Frameworks/GTMSessionFetcher.framework: unknown error -1=ffffffffffffffff
I have followed the advice in security / codesign in Sierra: Keychain ignores access control settings and UI-prompts for permission, to no avail.
I have tried putting both private keys and certs into the System keychain, to no avail.
If I log in as the Jenkins user and run the codesign command manually, I "Always Allow" access to the keychain, and it works, repeatedly. However, running as invoked by the Jenkins CI does not. (The Jenkins master is the Mac, and I'm using this same Mac to build.)
The error is mentioning the CocoaPod GTMSessionFetcher. Is this something to do with CocoaPods?
Any ideas would be appreciated.
I was experiencing exactly the same issue and I am quite sure that it has nothing to do with CocoaPods, its a codesigning issue. Some of the things I did:
Check that I do not have duplicate Keychain Entries. This post was useful for that. It turned out that I had one entry duplicated.
Check that private keys are allowed to all applications, as explained here
Try this (be aware that since macOS Sierra login.keychain has changed to login.keychain-db), which is the second answer in the advice you mention, but didn't work.
Move both private keys and certs to System keychain (leaving only the certificates on login keychain). This last step was the one that made things work.
In case this is not helpful you can try to unlock the login keychain manually in your Jenkins job (that did the trick for me before I moved keys an certs to System keychain):
node("macOS-sierra") {
.........
stage("Build"){
sh 'security unlock-keychain -p KEYCHAIN_PASS "/Users/YOUR-CI-USER/Library/Keychains/login.keychain-db" && fastlane beta'
}
You can check your keychains with this:
$ security list-keychains
I got an issue with Xcode's Bot. It always returns the "User canceled the operation. Command /usr/bin/codesign failed with exit code 1" error string after running the command below:
/usr/bin/codesign --force --sign <MY_PRIVATE_KEY> --entitlements /Library/Developer/XcodeServer/Integrations/Caches/2cdd321641e8c114e4eba9819b017479/DerivedData/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/MyApp.app.xcent /Library/Developer/XcodeServer/Integrations/Caches/2cdd321641e8c114e4eba9819b017479/DerivedData/Build/Products/Debug-iphoneos/MyApp.app
I can run this command in Terminal with sudo. I'm using Xcode 6.3.1 and OS X Server 4.1.53 in my Mac 10.10.4.
Thank for your help.
This looks like a code signing error. There are a few different reasons for this to happen so you will need to do some troubleshooting. Can other bots build on your server? If so then its probably a build settings issue in this specific project.
In the Xcode Project go to the Project Target that your trying to build, and then Build Settings, and Code Signing. Under the Provisioning Profile you can either choose Automatic or explicitly choose the correct provision, and then under the Code Signing Identity choose iOS Developer. This is probably where your issue is if its related to the project. Do you have a proper provision setup for the project on the Apple Developer Portal?
If you can't get any bots to run on your server then the issue could be with how you set up Xcode Server. Have you added the server to your team? Here is the blog post that I used to get mine up and running, although you don't need to do all of those steps in the post. Focus specifically on the Setup Certificates section and Setup Provisioning Profiles section.
I fixed the issue by copying the missing provisioning file from my local directory "/Users/phuongle/Library/MobileDevice/Provisioning Profiles" to "/Library/Developer/XcodeServer/ProvisioningProfiles". Do not use the downloaded provisioning file from developer.apple.com directly.
I just want to note here for everyone having the same issue with me.
I started getting a codesign error after a certificate expired. I have an updated certificate and the expired one has been deleted. But somehow, Xcode sets EXPANDED_CODE_SIGN_IDENTITY with the SHA-1 of the expired certificate. Where does it get this value? I assume it must be cached somewhere because there is no certificate in the keychain with the SHA-1 it is trying to use for code signing. I searched the pbxproj file and did not find it, nor did a recursive grep starting from the project root yield any results.
Here are some details about my configuration:
There is no account set up in Xcode
Instead of a developer account, I am using the exported certificate from the Team Agent
Xcode version is 6.1.1
OSX version is 10.10.2
The project identity is set up in Xcode like this:
When I check the keychain, it finds the correct identity:
$ security find-identity -p codesigning
Policy: Code Signing
Matching identities
1) F1326572E0B71C3C8442805230CB4B33B708A2E2 "iPhone Developer: XXX XXX (C395QGL4DK)"
In the build output I see the environment variable set incorrectly:
export EXPANDED_CODE_SIGN_IDENTITY=9F5616A53464FC5C003847ED620357A7BC72ABB1
I have tried to fix it with the following:
Delete the certificate from Keychain Access and re-add it
Set the Access Control of the private key to allow all apps
Delete all provisioning profiles and re-add the one I am using
Delete everything under ~/Library/Developer/Xcode/DerivedData
Delete everything under ~/Library/Caches/com.apple.dt.Xcode
Restart Xcode
Reboot the Mac
I have now run out of ideas for things to try. There are two other developers I work with, and both of them experienced the same problem initially. However, they are working again after doing some of the same steps that I have tried. We are all using the same certificate, the same provisioning file, and the same project settings. It must be a setting or lingering cache that is on my system, but I have not been able to find it.
If I could find out where Xcode sets this environment variable, I can clean it up and everything should be fine again.
I was having the same issue and for me the answer was fairly simple: I was trying to use a provisioning profile that was tied to the old certificate (my guess is that EXPANDED_CODE_SIGN_IDENTITY is pulled from the profile you are trying to use).
Anyway, after creating a new profile on the dev center tied to the new certificate, this stopped happening.
if it helps, I'm using jenkins to build app, so all commands run from console...
So i've turned off CODE_SIGNING_ALLOWED and "overrided" EXPANDED_CODE_SIGN_IDENTITY_NAME and EXPANDED_CODE_SIGN_IDENTITY. For some reason it helped me to build app with proper identities.
xcodebuild -project my.xcodeproj/ -sdk iphoneos \
CODE_SIGNING_REQUIRED=YES \
CODE_SIGNING_ALLOWED=NO \
CODE_SIGN_IDENTITY="My Identity" \
EXPANDED_CODE_SIGN_IDENTITY_NAME="My Identity" \
EXPANDED_CODE_SIGN_IDENTITY=<CODE_SIGN_IDENTITY>
Last one could be obtained with
security find-certificate -a -c "My Identity" -Z|grep ^SHA-1|cut -d " " -f3|uniq
I want to build a single window Mac application, which can be used to codesign iOS applications without using XCode.
Many of our clients use "Enterprise License" to distribute their apps. Each year they need to be resigned and its a repetitive work. Their requirements are following
Apps make use of APNS
They don't want to share their Enterprise License
Bundle identifier should be replaceable while signing with their certificate
They have certificates with same name in Keychain
Userinterface has the following fields
Path to the *.ipa file
Path to the *.mobileprovision file
Keychain name (optional incase more than one certificate with same name exists)
Name of the certificate (iPhone Developer : .....)
I was able to codesign application, but APNS is not working after resigning. Or is it not possible to resign applications making use of bundleIdentifier?
And also I would like to add a feature of drop down list of certificates available in Keychain for improved useability. Any pointers would be great help
To enable push notifications, the app ID and provisioning profile will need to have that configured and allowed by Apple (through the portal). You can't enable it for arbitrary provisioning profiles/apps just by resigning.
During codesigning, the entitlements need to have the apns-environment key set to sandbox/production depending on what the app uses. This will then be verified at runtime by iOS. If you are using a third-party signing tool, it should take the apns-environment value from the provisioning profile.
For debugging, you can look at the entitlements for a .app with this command:
codesign -d --requirements - --entitlements - path/to/My.app
You should see an apns-environment value, but only if the provisioning profile had that enabled.
Just spent several hours researching this same issue and discovered the following process. Taking Mike's comments one step further, providing the following command line for others running into the same issue.
I am starting with an xcode release build using a bundle id that has been configured for production push notification.
From the terminal window run the following commands - replacing the "CAPITAL SECTIONS" with your info
codesign -d --entitlements -"NAME OF APP.app" > entitlements.plist
codesign -f -s "SIGNING CERTIFICATE NAME" --resource-rules "NAME OF APP.app/ResourceRules.plist" --entitlements entitlements.plist "NAME OF APP.app"
Hope this helps the next person struggling with this same issue