Xcode Command /usr/bin/codesign failed with exit code 1 : errSecInternalComponent

Question

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

The error comes from a mismatch in the provisioning profile setup and the certificates and the bundle id. Make sure that your PP, bundle id, and certificates are setup correctly in the and assigned correctly in itunes connect and in app. — Alex Pelletier, Nov 19 '14 at 03:48
I encountered this problem going from Xcode 11.2.1 to 11.3 during code signing of frameworks built by me. No provisioning profiles were involved. The answer by Mohit Manhas cleared it up. — Daniel Zhang, Jan 07 '20 at 00:32
This happens if you're using SSH and codesign is not allowed access to the private key in Keychain. To check this, find the key in Keychain, right click and select "Get Info", switch to "Access Control" and see if 'codesign' app is in the list of "always allow access". See this comment https://github.com/electron-userland/electron-builder/issues/4455#issuecomment-642019500 What I did is ran the scripts once from GUI and clicked "Always allow" for key access, then it started working. — ArticIceJuice, Jul 14 '20 at 16:51
I tried various things and I expect some of them probably helped, but the action that got me unstuck was clearing the DerivedData folder — Tommy Herbert, May 25 '22 at 11:10

score 268 · Accepted Answer · edited Mar 30 '19 at 23:36

268

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!

edited Mar 30 '19 at 23:36

Ky -

30,724
51
192
308

answered Jun 27 '18 at 18:41

Mohit Manhas

3,471
1
17
21

It helped, the initial problem was caused by changing a password for my Mac. – Dmytro Hutsuliak Nov 26 '18 at 09:42
5

Worked for me too. Build an apk for Android 30 seconds, build an app for iOS.. 2hs. – Gabe Dec 12 '18 at 03:18
Just did this while codesigning a FileMaker runtime that I have been struggling with all day... can't believe it worked!!! – Schwarz Software Feb 28 '19 at 13:53
1

@FredericP For me I had recently changed my password. So there was some interplay between the last time the keychain was unlocked by xcode and the password used to do so. – sherrellbc Aug 02 '19 at 19:31
This helped for Xcode 10, macOS 10.13, when Apple temporarily lost my developer account, found it again, but sent me to keychain hell, and afterwards, simply failed me with exit code 1. THANK YOU. – green_knight Aug 18 '20 at 22:32
18

Can't find the lock all keychains option on MacOS Big Sur 11.6 – allenlinli Sep 24 '21 at 04:54
2

@allenlinli same here. for me what worked too was: Keychain Access -> on the left sidemenu right click on "login" -> click on "Change Settings for Keychain 'login'..." -> set to lock after 1 minute -> wait one minute and open xcode Then it asked again for password. – marvinfrede Feb 01 '22 at 16:42
@marvinfrede Unfortunately this no longer works -- or it doesn't on macOS Monterey 12.2.1 with Xcode 13.3. codesign will prompt you for your password but you'll see exactly the same error. Looks like Apple may have broken this feature (codesigning). – Mar 30 '22 at 22:10
`Can't find the lock all keychains option on MacOS Big Sur 11.6` - yeah, and even can't "Change Settings for Keychain 'login'..." because of permissions error. Needed to relogin under user in GUI first – Drey Apr 16 '23 at 17:28

score 118 · Answer 2 · edited Jun 10 '21 at 01:25

118

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.

edited Jun 10 '21 at 01:25

MarSoft

3,555
1
33
38

answered May 26 '18 at 02:27

cbracken

3,610
2
21
20

2

Unfortunately this solution seems entirely circular: running the above command requires you to enter the password, which is obviously a no-go in a non-interactive session (as when executing this via a CI agent such as Jenkins). – Konrad Rudolph Jan 15 '19 at 17:48
5

We had a similar problem on Jenkins, and in addition to what is mentioned in the above command we had to pass the password as an argument to the command so we did "security unlock-keychain -p $KeychainPassword ", where you can easily store KeychainPaasword on Jenkins securely. – Mohit Tater Aug 30 '19 at 01:42
3

I can't thank you enough for this post. I've spent a few days trying to figure out why `codesign` was failing and this is the magic command that saved me!!! – Dimu4 Mar 14 '20 at 19:56
1

seems like unlocking has to be done in the same bash session where codesign is run otherwise it will fail. – OLIVER.KOO Apr 21 '21 at 18:14
The option for : security unlock-keychain login.keychain worked just fine. If you don't provide your login password, the console will ask for it in the process: password to unlock login.keychain: – vsecades Nov 28 '21 at 17:09

score 82 · Answer 3 · answered Aug 14 '14 at 17:08

82

It seems like a bug in the code signing mechanism, restarting your mac should solve the problem

answered Aug 14 '14 at 17:08

sigabrt

1,047
8
11

different case, but similar error message - restart worked. – mikus Jul 09 '18 at 13:40
2

If you're waiting for a less destructive solution, see Mohit Manhas's answer below – yonix Oct 28 '18 at 09:52

score 49 · Answer 4 · edited Oct 03 '18 at 15:07

49

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

edited Oct 03 '18 at 15:07

Jon McClung

1,619
20
28

answered Sep 07 '18 at 11:30

Equilibrium

694
1
7
6

Can you elaborate on "update key access control to "Allow all applications to access this item"? I have no idea what that even means. – Jon McClung Oct 02 '18 at 18:15
2

@JonMcClung Open keychain access, go to login keychain - my certificates. Find the certificate you're signing with, expand it to see the key. Double click the key and you should see "Access control" tab. Switch to allow is there – Equilibrium Oct 03 '18 at 13:56
To improve this answer: from security point of view, the best would be to only allow access the private key from a specific application. It is `codesign` in this case. This is also possible from the Access control tab after double-clicking on the private key in Keychain. – Jakub Žitný Jan 15 '19 at 11:40
How did you manage to run the `security unlock-keychain` command via CI? I am asked to enter the keychain password (entirely reasonably). No way around this. I initially thought that part 1 of your answer was enough to get this to work for CI but apparently that only worked temporarily. – Konrad Rudolph Jan 15 '19 at 17:49
6

@KonradRudolph `security unlock-keychain -p login.keychain` from CI. – Equilibrium Jan 16 '19 at 08:32
@Equilibrium That’s obviously far from ideal since it requires you to have the literal password stored somewhere in the CI configuration or a script. I’d much rather grand selective access to just a single keychain item (which is precisely what part 1 of your answer does). It seems bizarre that macOS seemingly doesn’t support this, and it considerably weakens security. (And, yes, I can symmetrically encrypt the key in my script but that just defers the problem rather than solving it.) – Konrad Rudolph Jan 16 '19 at 09:37
1

@KonradRudolph it's not necessary to provide a password for security unlock-keychain if you allowed codesign to access a private key. It's enough to leave an empty string as a password. – Kamil Szostakowski Feb 25 '19 at 23:36
This should be the correct answer. It's even better to set `codesign` specifically, not "all applications to access" the item. You add the `codesign` by clicking on `+` and navigating to `/usr/bin/codesign`. – Jakub Žitný Mar 28 '19 at 14:38
1

@KonradRudolph still probably not ideal but you could move that unlock command to `~/.bash_profile` so that the keychain unlocks on SSH client startup but you don't need reference to it from your CI script – sschilli Oct 09 '19 at 17:24
@equilibrium THX You command **security unlock-keychain -p {account-password} login.keychain** helped me on **Bamboo CI** – A.Kant Oct 15 '19 at 15:39

ifeegoo · Answer 5 · 2018-05-24T02:31:26.310

25

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!

edited May 24 '18 at 02:31

answered Apr 25 '18 at 08:05

ifeegoo

7,054
3
33
38

14

We have saying in America - 'Never reboot old hardware' – Brant Jun 28 '18 at 16:06
@Brant Why you have this saying? It's interesting. – ifeegoo Jun 29 '18 at 03:47
Just joking - but we had a similar problem and finally just resorted to rebooting an old server. – Brant Jul 17 '18 at 01:32
2

@ifeegoo Old servers can have problems booting back up(maybe the os updated itself? maybe someone broke the bootup scripts?) or need some manual startup procedure nobody who is available knows about. You can't know before you try it. Maybe the bios rom had gone bad. It's just one of those things that shouldn't be a problem in a properly kept up environment but you don't actually know before you try and you would rather not try. – Lassi Kinnunen Sep 20 '18 at 05:28
1

@LassiKinnunen You are right,we are mobile developers for Android & iOS,so this kind of situation does not care about the servers.The servers are really dangerous,it's not situable. – ifeegoo Sep 20 '18 at 09:13
sounds like the linux and windows world before vagrant and docker. good times. you guys should really hold apple ransom to join the current century. – airtonix Feb 10 '21 at 05:19
Sounds like Windows XP style solution. ;-) – Karsten Nov 22 '21 at 10:59
@Karsten en, it looks like. ;-) – ifeegoo Nov 22 '21 at 13:39

score 13 · Answer 6 · answered Aug 03 '18 at 20:24

13

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.

answered Aug 03 '18 at 20:24

jamesdlin

81,374
13
159
204

This is very strange, even running the keychain unlock command seems to silently fail because the codesign still doesn't work. But running the same commands using remote desktop (instead of SSH) works fine. – Max Jul 30 '20 at 20:12
Met the same using SSH over MacOS 12 Montery. Execute from VNC succeed. – Trout.Z Mar 20 '22 at 15:11
I am experiencing the same thing, I can build on a remote build server Mac mini using VNC but I can't run the same commands via ssh, or using our Bamboo server. We have legacy "good" Mac mini nodes, but I'm struggling to setup new ones. I posted in Apple forums here but the response didn't help https://developer.apple.com/forums/thread/703254 – LizCiraG May 02 '22 at 20:00
`security unlock-keychain login.keychain` did not work for me. I had to run on the macOS machine and confirm the password popup with the *Always Allow* option. – Thomas S. Apr 07 '23 at 10:04

score 4 · Answer 7 · answered Aug 30 '19 at 01:54

4

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

answered Aug 30 '19 at 01:54

Mohit Tater

453
1
6
10

Your answer is based on @equilibrium answer, but I will conceive it. On **Bamboo CI** me helped command **security unlock-keychain -p {account-password} login.keychain** – A.Kant Oct 15 '19 at 15:37
I had this issue after importing a keychain from another mac I didnt realise I was using in a project. I used your solution with the exact path to the keychain and then rebuilt and it work - several days spent trying to solve the issue. – M3nd3z Feb 15 '21 at 19:37

score 4 · Answer 8 · answered Sep 25 '19 at 03:08

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

score 4 · Answer 9 · answered Nov 30 '20 at 10:01

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

score 3 · Answer 10 · answered Dec 22 '18 at 20:09

3

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.

answered Dec 22 '18 at 20:09

sunapi386

1,167
14
18

score 3 · Answer 11 · answered Nov 09 '19 at 02:07

3

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.

answered Nov 09 '19 at 02:07

Andres Felipe

4,292
1
24
41

This helped me. I deleted Apple’s certificates in `Keychain Access > My Certificates` then added the distribution and development certificates via `Xcode menu > Settings > Accounts > Manage Certificates`, then cleaned the project via `Product > Clean Build Folder…`, then built again. – fregante May 13 '23 at 09:29

score 2 · Answer 12 · answered Oct 19 '18 at 10:44

2

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

answered Oct 19 '18 at 10:44

Stas S

101
1
3

score 2 · Answer 13 · answered Nov 05 '18 at 06:47

2

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.

answered Nov 05 '18 at 06:47

sahiljain

2,215
1
29
39

score 2 · Answer 14 · answered Oct 04 '19 at 14:09

2

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.

answered Oct 04 '19 at 14:09

Pellet

2,254
1
28
20

score 2 · Answer 15 · answered Mar 30 '22 at 12:15

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/

Thank you thank you thank you!!! Been battling this issue for two weeks and finally found your comment! For those of you trying to figure out which cert to download, you need to open up your Keychain and right click and choose get info. Then look for Organization Unit under Issuer Name. That is the cert. — rplankenhorn, Oct 25 '22 at 16:23

score 2 · Answer 16 · answered Jun 30 '22 at 12:16

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.

score 1 · Answer 17 · answered Nov 04 '18 at 10:38

1

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.

answered Nov 04 '18 at 10:38

Felix

11
1

score 1 · Answer 18 · edited Aug 01 '23 at 23:02

1

The above methods are useless to me.

I resolved it by:

Open keychain access.
Click Login Menu.
Remove all personal certificates.
Clean the project.
Rebuild.

That's it. Hope it helps to anyone.

edited Aug 01 '23 at 23:02

Jeremy Friesner

70,199
15
131
234

answered Apr 07 '20 at 15:07

yerwoo_gmail

31
2

score 1 · Answer 19 · answered Mar 19 '21 at 12:11

1

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

answered Mar 19 '21 at 12:11

Anand Rockzz

6,072
5
64
71

score 1 · Answer 20 · answered Oct 26 '22 at 15:34

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.

score 0 · Answer 21 · answered Sep 18 '20 at 20:47

0

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.

answered Sep 18 '20 at 20:47

RAM237

903
11
17

Deepika MG · Answer 22 · 2021-05-27T11:50:22.967

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.

score 0 · Answer 23 · answered Oct 26 '22 at 15:37

0

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.

answered Oct 26 '22 at 15:37

Dan Gravell

7,855
7
41
64

score 0 · Answer 24 · answered Jul 11 '23 at 15:17

0

Just do partitioning:

security set-key-partition-list -S "apple:" /Users/jenkins/Library/Keychains/login.keychain-db

answered Jul 11 '23 at 15:17

AndrewK

907
8
14

Xcode Command /usr/bin/codesign failed with exit code 1 : errSecInternalComponent

24 Answers24

Linked

Related