Nothing new to report. I'm waiting for guidance from Quinn on running a debug test project. I now seem to be the only one with this problem and I can transfer projects to my wife's laptop to sign them. Using Migration Assistant to setup a new Mac may be causing the problem. I have not used the nuclear option to wipe my Mac as I think it's important to understand what could cause a correctly generated certificate and key pair to not be recognized as a secure identity.

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

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

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 .

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.

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

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

Keychain Access shows the certificate and private key but the certificate chevron is not there and the My Certificates tab is empty. The % security dump-trust-settings reported that No Trust Settings were found. This is consistent with my own tests where although new certificates and keys were created (or imported as a p12 file) and seemed to be matched, they were never shown in My Certificates or with the chevron. However this is the first time this behavior has been documented using a clean new account. I'm not proficient using Terminal and Export Text didn't work for me, so I posted screenshots of KeyChain Access, the terminal commands (with result) and part of the info for the Certificate. Thanks again for your time looking into this, and re [1] I used security find-identity without the -v or -p MB

Reviewing the before and after files (with help from an LLM), the private key and certificate are correctly paired but security find-identity reports 0 identities. Private key 0x00000006: 9FBCE9C3680FC2DB6E896517311458DCCD406FE8 Certificate hpky: 9FBCE9C3680FC2DB6E896517311458DCCD406FE8 This is mostly beyond my understanding, but I hope it helps you to isolate the problem.

I noticed that after.txt did not include the result of security find-identity >> ~/Desktop/after.txt. I reran it and it shows no security identities found after3.txt

I ran the new tests with a new admin account. Xcode initially stated that "I need to revoke the existing development certificate". I did so and saved before.txt. I then ran Build and it failed. I saved the after.txt. I forgot to change the destination from 'my Mac' to 'any iOS device' but a redo created an identical after.txt file. I hope the files are as requested and useful before.txt after.txt diff.txt I agree with you re LLMs. However as an old retired developer I have no other support. I'm very concerned about not wasting your time with a silly mistake. Codesigning has never worked on my M4 Mac Mini, and with the same account it works OK on our M1 MacBook.

Sorry! I use the Simulators 99% of the time and RUN does fail with a real device (my iPad). The report using a test admin account or my regular account shows an invalid certificate. I have done lots of tests involving creating keys, certificates and importing p12 files. New ones are created but they are never paired. My LLM says: "The private key is consistently named 'Apple Development: Michael Birch (Computerade Products)' while the certificate is named 'Apple Development: Michael Birch (9KD5TCGGHG)'. The internal application labels are cryptographically unrelated — confirming the key and certificate are not a matched pair despite being created simultaneously by Xcode." I hope this failed Run report for destination iPad is what you requested to give us new clues. iPadRunTest.txt p.s. a Run with destination iPad on our laptop failed, but it was due to insufficient disk space. I had to delete the 3GB iPad support (not my wife's files!). Archiving with destination 'this Mac' then succeeded.

Your instructions were clear so I hope I created the reports as requested. I also copied the test project to our laptop where run and archive both succeeded. I did not revoke old certificates or keys. When new certificates and private keys are created they are not paired and do not appear in Keychain My Certificates success-run.txt failed-archive.txt laptop-success-archive.txt laptop-success-run.txt

Thanks! Your reply helps me understand why you are focussed on why RUN works but ARCHIVE fails. I appreciate your comments re SEID_mismatch. I could not have discovered this without LLM help but I was too quick to assume that it causes archiving to fail. Archiving fails quickly so it's unlikely to be a cloud related issue. I will run new tests over the holiday weekend and also run them (successfully) on my wife's M1 MacBook and provide full reports. Thanks again. MB

I did not delete the unpaired certificate and key in KeyChain but I did run Clean Build OK. The success and failed reports are attached. My understanding is that you don't think codesigning could fail due to a corrupted secure enclave SEID mismatch. Claude AI seems to disagree. Please see attached file. Thanks - and have a great July 4th! MB success.txt failed.txt SEID_Mismatch.txt