M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible

This is the Certificates screen shot - no chevron - and nothing shows in My Certificates.

Is codesigning responsible for creating a security identity from a matched certificate and private key, or is it a separate process?

MB

Thanks for that.

And yeah, this just gets weirder.

I’ve run out of debugging steps that we can do on the forums. Given that, I’ve re-opened your DTS case and sent you an email response from there. My hope is that we can use that private conversation to figure out what’s going wrong, and then once we’re done one of us can post a summary of the results here.

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

Were you able to resolve this? I am running into the same issue on my brand new M5 Macbook pro. Incredibly frustrating, and I am hard blocked by this.

I read through the thread a bit more; I've run into similar weirdness but when using Xcode's Run command.

The Xcode error is:

no identity found 
Command CodeSign failed with a nonzero exit code

When I run security find-identity, my result is:

Policy: X.509 Basic

  Matching identities

     0 identities found



  Valid identities only

     0 valid identities found

Steps I have tried:

• Xcode's automatic signing (Deleting/recreating)

• Creating my own CertificateSigningRequest, signing it through the apple Cert management site, creating a P12 and imported into keychain

• Created fresh login Keychain

• Created new Admin user on my laptop, and attempted to run Xcode with new cert through there

• Used openssl to create my own RSA key pair/ CSR/ and signed through apple cert portal.

• Granted trusted status to all certificates for any operations

No matter what I try, I cannot get the private key associated to the cert with the chevron, and cannot create a valid signing identity.

For what its worth, this is a 2 day old M5 Macbook pro. Pretty disappointing so far, I'm at my wits end and have spent ~10 hours on this with 0 progress.

Wow! I didn't see your forum post until today Aug 27. Quinn at DTS moved the discussion to DTS Case-ID: 20272957 and direct emails.

Quinn ran my login chain with the paired (but not trusted) certificate and private key and it worked OK - codesigning worked. I can also use it on my wife's Macbook to sign Apps.

I ran a test with a new admin account. It failed and I submitted a sysdiagnose log. DTS engineers have not yet commented on it. I'm not sure it was captured at the best time so I'm reviewing the steps and I plan to submit a new sysdiagnose log.

It's a weird problem but it sounds very similar to your problem. Thanks for sharing. JMB

I wanted to post a quick update here.

The short answer is that we have no idea what’s going on )-:

At my request, jmb2013 filed a bug about this (FB24177273) and one of the keychain engineers dug deep into the issue and came back with… nothing. Specifically, we captured a copy of jmb2013 keychain and everyone on our side of the fence is able to add that keychain to Keychain Access and see the certificate and private key pair up. However, that doesn’t work for jmb2013.

We even went so far as to test this with an M4 Mac and the same OS release as jmb2013.

And clearly this isn’t a super widespread problem or lots more folks would be reporting it.

Mmmatiss, I’ll probably have more stuff for you tomorrow, but for the moment I wanted to ask for you to respond to this…

jmb2013 wrote:

Did you set up your M5 Macbook using a time machine backup from an older Mac?

That’s one thing that we haven’t tested, and if you took that step as well then we should probably look into it.

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

Thanks for the input Quinn.

Did you set up your M5 Macbook using a time machine backup from an older Mac?

I didn’t use Time Machine backup. I set up the new Mac by connecting it directly to my old Mac over USB-C and transferring everything that way.

So it was a direct Mac-to-Mac migration over usb-c, than restoring from Time Machine. I believe it still may have carried over Keychain/security data, though, so it could still be relevant to the current issue.

The old mac was a 2019 intel based macbook pro if that is useful info.

It's likely that a USB Mac to Mac transfer uses the same routine and copies the same data as a Time Machine restore. If so, something in that transfer that is invalid on new Macs, may be causing the new Mac not to be trusted.

It's likely that a USB Mac to Mac transfer uses the same routine

Yeah, but that’s not the only thing to consider here. The fact that you used two different migration processes increasing the ‘audience’ for this bug. If this problem only cropped up for folks who migrating by restoring from Time Machine, it might be reasonable to assume only a few users would encounter it. However, migrating over USB with Migration Assistant is likely to be a much more popular option, and thus I’d expect to have seen more reports of this.

I suspect there’s something else in play, I just don’t know what it is )-:

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

@Mmmatiss , If you’d like to help me dig deeper into this, please open a DTS code-level support request so that we can talk one-on-one.

IMPORTANT When the submission form asks who referred you to DTS, please enter my name and reference this thread.

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

My Mac has an expired developer relations certificate in the system keychain copied from my old Mac. This may be causing it not to trust valid certificate and private key pairs. I provided details in DTS Case-ID: 20272957     Bug Report 24177273 .

I tried the nuclear option - completely wiping my laptop and starting a new.

Then followed the same exact steps to create a dev cert that I had been followed when initially setting up. It worked immediately. I see the paired certificate + private key, I have a signing identity, and I am able to push a dummy app to my phone. This is fairly painful, since I now need to reconfigure my laptop but I think I am unblocked.

I think there is something that can go wrong in the migration process, which silently breaks security's ability to pair certs/keys into an identity

That's good news Mmmatiss! It confirms that something improper is being copied when using Migration Assistant. I've asked DTS/Quinn whether an old expired Developer Relations certificate copied from my old Mac could cause the problem. This old invalid certificate is in my system keychain which I think overrides any certificates in the login keychain.

Is it possible that your old Mac also has an old Developer Relations certificate (in the system keychain) that was transferred and has expired?

p.s. if you check your old system keychain make sure that the option "show expired certificates" is set ON

After suggesting that you check for the expired certificate I decided to check for it on my wife's laptop which is able to do codesigning correctly. I was surprised to find the expired certificate on this working laptop!

This shows that my theory that the expired developer relations certificate is causing the codesigning problem is incorrect. It may still be part of the problem as I have occasionally seen an expired certificate error when my codesiging tests fail.

I'm sorry for jumping to conclusions, and I will run some new tests requested by Quinn

jmb