errSecInternalComponent building locally with Xcode

Code Signing General
noah-emberex OP
Created Sep ’23
Replies 9
Boosts 0
Views 897
Participants 2

I'm running into a code signing issue with an (existing) app that I recently started working on. I haven't run into this problem with other apps built on the same computer using the same framework (Capacitor).

When I try to build the app from Xcode, either to run on a linked iPhone or to archive/publish, I get the error message: "Command PhaseScriptExecution failed with a nonzero exit code"

That script fails when running /usr/bin/codesign and shows the message errSecInternalComponent. I tried running the same command directly in the terminal and got the same error message.

I started going through this forum post and the initial sanity check failed. I ran this from a local terminal, not over ssh or inside tmux. I didn't get any dialog prompts when running it, though that may make sense since I was already logged in:

$ cp /usr/bin/true MyTrue
$ codesign -s "Apple Development: ..." -f MyTrue
MyTrue: replacing existing signature
MyTrue: errSecInternalComponent
$ echo $?
1

The identity I attempted to use is listed by security find-identity -p codesigning in both the "Matching identities" and "Valid identities only" sections. Keychain Access shows that the certificate is valid.

I've tried restarting the computer. I've tried cleaning the build folder from Xcode. Any other suggestions for diagnosing and/or fixing the problem?

Replies  9
Boosts  0
Views  897
Participants  2
DTS Engineer OP
Apple
Sep ’23

If you add -vvv to the codesign command, does that turn up anything new?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
noah-emberex OP
Sep ’23

Unfortunately, I'm not getting any more info with the verbose flag:

$ codesign -vvv -s "Apple Development: ..." -f MyTrue
MyTrue: replacing existing signature
MyTrue: errSecInternalComponent

In case the order mattered, I also tried adding -vvv right before -f and then tried it as the last arg, but both of those gave the same result.

0
DTS Engineer OP
Apple
Sep ’23

Unfortunately, I'm not getting any more info with the verbose flag

Yeah, it was a long shot.

There are two potential paths forward here:

  • Try in a different context.

  • Look in the system log for more hints.

For the first, my go-to technique for this sort of thing is to export my signing credentials from the problematic Mac, import them on a ‘fresh’ Mac, and try there.

I usually use a VM as my fresh Mac, restored to a fresh snapshot between each test. If you don’t have a VM set up, you can use some other Mac. If you don’t have another Mac, create a new user account on your current Mac.

The credentials you need to export are:

  • Your signing identity

  • The WWDR intermediate it relies on

You can export both using Keychain Access. Export the signing identity as a PKCS#12. For details instructions, see the Back Up Your Signing Identities section of The Care and Feeding of Developer ID.

Note That post is about Developer ID signing identities, but the backup and restore process is the same for Apple Development ones.

You don’t need to bring over your full Xcode environment; just use the MyTrue test.

On the system log front, the system log is rather busy so I usually use log collect to take a snapshot of the log immediately after reproducing. I then open the snapshot in Console and look through the log for errSecInternalComponent, or it’s numeric equivalent, -2070. Then look backwards in the log for potential causes.

For a bunch of info about the system log, see Your Friend the System Log.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
noah-emberex OP
Oct ’23

Thanks for the info! I'll try the export/import in a minute, but tried the log export first and thought I'd post it here now in case you see something that points in a particular direction.

I believe this is the section of logs resulting from running the MyTrue test:

default 2023-10-02 13:14:49.496818 -0700  securityd 0x7fa4ea41e400(0x7fa4ec4095b0) is unlocked; decoding for makeUnlocked()
default 2023-10-02 13:14:49.496954 -0700  securityd CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.496983 -0700  securityd CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.497085 -0700  codesign  CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.497112 -0700  codesign  CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.497131 -0700  codesign  caught CssmError: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.497132 -0700  codesign  MAC verification failed; something has gone very wrong
default 2023-10-02 13:14:49.497133 -0700  codesign  key has no integrity, denying access
default 2023-10-02 13:14:49.497253 -0700  codesign  CSSM Exception: -25304 The specified item is no longer valid. It may have been deleted from the keychain.
default 2023-10-02 13:14:49.497267 -0700  codesign  error while checking integrity, denying access: CSSM Exception: -25304 The specified item is no longer valid. It may have been deleted from the keychain.
default 2023-10-02 13:14:49.497287 -0700  codesign  MacOS error: -25304
default 2023-10-02 13:14:49.499564 -0700  securityd CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.499596 -0700  securityd CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.499651 -0700  codesign  CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.499676 -0700  codesign  CSSM Exception: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.499696 -0700  codesign  caught CssmError: -2147415734 CSSMERR_CSP_VERIFY_FAILED
default 2023-10-02 13:14:49.499697 -0700  codesign  MAC verification failed; something has gone very wrong
default 2023-10-02 13:14:49.499701 -0700  codesign  key has no integrity, denying access
default 2023-10-02 13:14:49.499775 -0700  codesign  CSSM Exception: -25304 The specified item is no longer valid. It may have been deleted from the keychain.
default 2023-10-02 13:14:49.499788 -0700  codesign  error while checking integrity, denying access: CSSM Exception: -25304 The specified item is no longer valid. It may have been deleted from the keychain.
default 2023-10-02 13:14:49.502739 -0700  codesign  MacOS error: -2070
default 2023-10-02 13:14:49.503076 -0700  codesign  Entering exit handler.
default 2023-10-02 13:14:49.503077 -0700  codesign  Queueing exit procedure onto XPC queue. Any further messages sent will be discarded. activeSendTransactions=0
default 2023-10-02 13:14:49.503125 -0700  codesign  Cancelling XPC connection. Any further reply handler invocations will not retry messages
default 2023-10-02 13:14:49.503154 -0700  codesign  Exiting exit handler.

The lines about the key being invalid or deleted are surprising to me since this is the default/login identity, as far as I understand.

0
DTS Engineer OP
Apple
Oct ’23

Yeah, there’s definitely something weird going on here. Note the error -25304, which errSecInvalidItemRef. That’s not something I see very often.

The lines about the key being invalid or deleted are surprising to me since this is the default/login identity, as far as I understand.

No, I think it’s referring to the private key component of your code signing identity. So the key is there but you can’t use it, and it’s not clear why.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
noah-emberex OP
Oct ’23

Interesting, when I tried to export the cert+key from Keychain Access, I got an error dialog pop up that says:

An error has occurred. Unable to export an item.

The specified item is no longer valid. It may have been deleted from the keychain.

If I click on the certificate in the list, the info pane shows "This certificate is valid", but when I click on the private key nested under it, both the "Kind" and "Usage" fields are blank.

Do you think this means I didn't correctly import the key initially? Or that the key was revoked and I need to check with the account holder?

0
DTS Engineer OP
Apple
Oct ’23

Do you think this means I didn't correctly import the key initially?

It’s possible, but I’m leaning towards the theory that something got borked in the interim.

Or that the key was revoked and I need to check with the account holder?

I doubt it was revoked. Revoking Developer ID certificates is tricky and, even if were revoked, Keychain Access wouldn’t get that error trying to export it.

I suspect that your keychain is just broken in some way. However, I’ve one more test to run before I suggest remedial action:

  1. In Keychain Access, switch to My Certificates and find your Developer ID identity.

  2. Click the chevron to disclose the private key.

  3. Look at the Keychain column for both items.

Are both items in the same keychain? Is it your login keychain? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
noah-emberex OP
Oct ’23

In the My Certificates tab, that certificate and its associated private key both show "login" in the Keychain column.

I have several other development identities in my keychain and others are working, it's just this one that isn't. The others also have both their certificates and private keys in the login keychain.

0
DTS Engineer OP
Apple
Oct ’23

Yeah, you’re in a bit of a bind here.

Normally in a situation like this I’d suggest that you delete everything and start again. However, this is a Developer ID signing identity and those are precious. See The Care and Feeding of Developer ID for more on this.

The alternative would be to export the signing identity, delete everything, and then re-import it. But you can’t do that because you hit the same error in export.

There are two potential ways forward:

  • Go through your backups looking for a keychain that isn’t broken.

  • Delete everything and start again, which burns one of your limited number of Developer ID signing identities.

I generally recommend the first option. I just added a Recover a Signing Identity from a Mac Backup section to the The Care and Feeding of Developer ID that explains the basic process.

Good hunting!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
errSecInternalComponent building locally with Xcode
First post date Last post date
 
 
Q