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

I’m still hoping that someone can explain under what circumstances xCode or KeyChain Access would generate a new certificate and private key that are not paired (code signed).

My M4 Mac Mini was setup using a Time Machine backup but I lost the private key. I used Claude and Gemini AI to guide me but none of their ‘solutions’ worked. Their latest suggestion was to create this post.

A complete factory reset and rebuild of my Mac Mini without using a Time Machine backup would probably solve the problem but without understanding what caused it.

Additional Finding (using Claude AI)

— Possible Secure Enclave SEID Mismatch Running system_profiler SPSecureElementDataType reveals a potential discrepancy between the hardware SEID and System OS SEID: SEID: 04472C8BB9209002413205682832707603DBF0E05E8753C1 System OS SEID: 04472C8BB92090024132056828327076FFDBF0E05E8753C1

These values differ at bytes 17-18 — 03DB vs FFDB.

Could a SEID mismatch resulting from a Time Machine restore cause private keys to be generated with incorrect internal application labels, preventing codesigning identity pairing on an M4 Mac Mini?

This would explain why the problem has persisted across multiple macOS versions and survived complete keychain resets — if the Secure Enclave was improperly initialized during the Time Machine restore, no software level fix would resolve it.

Refined SEID Analysis — Possible Data Corruption Rather Than Migration Error

Closer analysis of the SEID discrepancy reveals a suspicious bit pattern:

Hardware SEID: ...03DB... System OS SEID: ...FFDB...

The lower byte DB is identical. Only the upper byte differs — 03 vs FF — a 6-bit difference where the upper 6 bits are all set to 1 while the lower 2 bits are preserved.

This pattern is more consistent with a data corruption event during SEID registration than two unrelated values from different machines.

Could a corrupted System OS SEID registration during Time Machine restore initialization explain why codesigning identity pairing consistently fails on this Mac Mini?

Is there a way to force re-registration of the System OS SEID from the hardware SEID without a complete factory reset?

This is a follow up to my November 2024 thread

Just so everyone is on that same page, here’s a link to that thread.

My DTS case 102877839447 is open

That’s not a DTS case number. DTS case numbers currently look like 20nnnnnn.

You do have a DTS case number, but in that case I simply referred you back to this forums thread.

Could a corrupted System OS SEID registration … explain why codesigning identity pairing consistently fails on this Mac Mini?

No.

Our code signing infrastructure still uses the file-based keychain (see TN3137). That is completely divorced from the Secure Element, which is what the SEID value is all about.

Try this:

1. Create a new user account on your Mac mini.
2. Log in as that user.
3. Launch Xcode.
4. In Xcode > Apple Accounts, sign in to your Apple Account.
5. Create a new project from the iOS > App template.
6. In Signing & Capabilities, select the team from step 4.
7. Select Any iOS Device as your run destination.
8. Build the project.

Does that work?

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

Case-ID: 20272957

As suggested, I logged in using a new admin account on my M4 Mac Mini, and then signed in to Xcode with my Apple account

I built and ran a test app successfully but archiving it failed. I tried this a few months ago with the same result. I noticed that Xcode can now automatically revoke any existing certificates. Although code signing failed, a new certificate and private key were created - but not paired

I can still build, run, and archive Apps on my M1 MacBook Air using the same Apple account.

I have tried a complete keychain reset, importing a p12 file from my MacBook Air, creating certificates manually and other ‘solutions’ suggested by AI help.

I was surprised that you say that code signing is (only) a keychain process. I read your TN3137 document which explains your statement in excellent detail but it does not mention SEIDs

My limited understanding is that the newer chips introduced an extra level of security. The hardware SEID and OS SEID are shown separately (and mismatched) on my M4 Mac mini but only the OS SEID is shown on my M1 MacBook Air.

Gemini AI indicates that the SEID is used at the server to verify the physical Mac.

"When an app or MDM profile uses Managed Device Attestation, it asks the operating system to generate an asymmetric key pair. Instead of storing that key pair in the standard user keychain where a local administrator or malicious script might try to intercept it, the operating system isolates it within the Secure Element chip.

The key pair is signed by Apple’s servers alongside the SEID, ensuring that the enterprise server can verify the request came from that exact physical Mac motherboard, completely independent of the user's local software keychain configuration."

If Apple’s server reads the OS SEID on my Mac mini it would not match the saved H/W SEID. Would this cause the server to refuse to sign the App?

Thanks for taking time to review this non-urgent case. I used to manage a s/w support group so I appreciate how busy you must be.

Michael Birch

p.s. Apple Developer Support assigned me to 102877839447. I uploaded images etc as requested and got a generic reply. I switched to DTS code level support Case-ID: 20272957 you replied via this post

Please ignore the quote (above) re Managed Device Attestation. It is not relevant to this issue regarding standard App Store codesigning.

I built and ran a test app successfully but archiving it failed.

I’d like to clarify that last point. Did it fail when you did the Product > Archive? Or fail when you tried to export that archive from the Xcode organiser?

And what where the symptoms of the failure?

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

The test app failed when i tried to archive it, with the error "code signing failed with a non zero exit code". and the message in the screen shot.

If Apple's servers now check the SEID to confirm the physical Mac the SEID mismatch on my Mac Mini M4 could explain why codesigning fails.

The test app failed when i tried to archive it, with the error "code signing failed with a non zero exit code".

OK. Please grab a full build log and post it here at a text attachment. See Command [something] failed with a nonzero exit code for more about that.

Also, please post a screenshot of the Signing & Capabilities editor for the app target in your test project. For example, here’s what I get when I follow steps 5 through 7 in my earlier post:

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

OK. I logged in as my testdev admin and took screen shots of the previous archiving test that failed. I hope I got the report you asked for as it doesn't look similar to your example.

I can still do archiving/codesigning with the same Apple account (and projects) on my wife's M1 MacBook Air.

I spent many hours trying possible solutions over the last year. When I found the SEID mismatch I thought this might be causing codesigning to fail, as the mismatch is specific to my M4 Mac Mini.

Thanks again MB

Following is the exported text file corresponding to the above screen images --------

Showing Recent Issues

Build target NewTest of project NewTest with configuration Release

CodeSign /Users/testdev/Library/Developer/Xcode/DerivedData/NewTest-fcddxpsazkibpgfjnkbnsqhyriwm/Build/Intermediates.noindex/ArchiveIntermediates/NewTest/InstallationBuildProductsLocation/Applications/NewTest.app (in target 'NewTest' from project 'NewTest') cd /Users/testdev/Desktop/NewTest

Signing Identity:     "Apple Development: Michael Birch (9KD5TCGGHG)"
Provisioning Profile: "iOS Team Provisioning Profile: *"
                      (6a85af2a-5024-4216-aaa3-f83109071c96)

/usr/bin/codesign --force --sign C93E9726CF89DA616AEA0C888F9B236480026AB6 -o runtime --entitlements /Users/testdev/Library/Developer/Xcode/DerivedData/NewTest-fcddxpsazkibpgfjnkbnsqhyriwm/Build/Intermediates.noindex/ArchiveIntermediates/NewTest/IntermediateBuildFilesPath/NewTest.build/Release-iphoneos/NewTest.build/NewTest.app.xcent --generate-entitlement-der /Users/testdev/Library/Developer/Xcode/DerivedData/NewTest-fcddxpsazkibpgfjnkbnsqhyriwm/Build/Intermediates.noindex/ArchiveIntermediates/NewTest/InstallationBuildProductsLocation/Applications/NewTest.app

C93E9726CF89DA616AEA0C888F9B236480026AB6: no identity found Command CodeSign failed with a nonzero exit code

Command CodeSign failed with a nonzero exit code

With reference to your reply with the screenshots, the first screenshot is showing what I’d expect. Cool.

it doesn't look similar to your example.

It looks close enough. The difference is that you created an app from the Multiplatform > App template, rather than the iOS > App template. Hence it lists all the other platforms. However, you have an iOS device selected as your run destination, meaning that it’s only the iOS setup that matters. And your iOS setup is what I’d expect.

The remaining screenshots, and the text in your last reply, indicate that Xcode is attempting to use your Apple Development signing identity when doing the Product > Archive. That’s also what I’d expect.

The weird thing is that this is failing even though you do have a valid Apple Development signing identity because you’re able to run the test app on your device.

OK, so another test:

1. On your Mac, switch to your test user.
2. Open your project.
3. Choose Product > Clean Build Folder.
4. Make sure your iOS device is still selected at the run destination.
5. Choose Product > Run.
6. Based on your earlier comments, I’d expect this to work. Save a copy of the full build log for that as success.txt.
7. Stop the app.
8. Choose Product > Archive.
9. Based on your earlier comments, I’d expect this to fail. Save a copy of the full build log for that as failure.txt.
10. Reply here, including both build logs as text attachments.

To add a text attachment to a forums reply, click the paperclip icon in the editor and then choose Add File.

To save a copy of full build log:

1. Choose View > Navigators > Reports.
2. Make sure that Local is selected at the top.
3. In the list on the left, select the relevant Build step (for the Product > Run case, this will be nested within the Run group).
4. In the main editor pane, at the top, towards the right, click the Export button.

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

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

You took a misstep when generating success.txt. You seem to have selected the Clean action rather than the Run > Build action. Thus, success.txt doesn’t include any meaningful build steps. Please repeat this process and make sure you select Run > Build when you save a copy of the successful full build log in step 6.

And lemme provide you with some background here. Upthread you wrote:

I logged in using a new admin account [and] I built and ran a test app successfully but archiving it failed.

This is weird because both Product > Run and Product > Archive should use the same Apple Developer signing identity. So the fact that the first works and the second fails is… well… odd.

I’m trying to work out why that’s the case. When I asked for screenshots of your Signing & Capabilities setup, I was hoping that’d reveal something weird. It did not, so now I want to look at the code signing steps in the full build log. In the failure.txt you just posted, I see this:

CodeSign …
    cd /Users/testdev/Desktop/NewTest
    
    Signing Identity:     "Apple Development: Michael Birch (9KD5TCGGHG)"
    Provisioning Profile: "iOS Team Provisioning Profile: *"
                          (6a85af2a-5024-4216-aaa3-f83109071c96)
    
    /usr/bin/codesign --force --sign C93E9726CF89DA616AEA0C888F9B236480026AB6 …

C93E9726CF89DA616AEA0C888F9B236480026AB6: no identity found
Command CodeSign failed with a nonzero exit code

which is a very clear indication that your Apple Development is missing. I want to compare that to what happened with the Product > Run case, where the Apple Development signing identity is obviously present otherwise the app wouldn’t run.

And I’ve asked for the full build because, depending on what I see, I might want to look at other aspects of your build.

Claude AI seems to disagree.

I can either spend my time explaining this stuff to you or critiquing your LLM. I believe that the first option is the better option.

However, in the interest of getting your off this misguided track, lemme critique just this one bit:

On Apple Silicon Macs private keys used for codesigning are generated inside the Secure Enclave — a dedicated security chip that is physically unique to each Mac.

This is patently incorrect. The SE only operates on EC keys, but Apple’s code signing keys are all RSA.

Note It is possible to work with a code signing identity where the private key is stored in a hardware token — see Signing code with a hardware-based code-signing identity — but the key still has to be RSA because the Developer website will only accept certificate signing requests that contain RSA keys.

Which isn’t to say that the SE is completely divorced from code signing. For example, you could imagine a world where cloud signing might require a functioning SE. However, I don’t see any evidence for that. Cloud signing, if it kicks in, usually kicks in when you go to distribute your app via the Xcode organiser. But your setup is failing before you get to that step.

IMPORTANT I’m not saying that cloud signing does require a working SE, just that it could. I’ve never explored that aspect of the code signing landscape in depth, and I don’t intend to do that here (unless we resolve your Product > Archive issue and continue to have problems).

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

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

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

Thanks for the latest info.

This snippet from success-run.txt explains the mystery I outlined in my previous reply:

CodeSign …/Debug-iphonesimulator/NewTest.app …
    cd /Users/testdev/Desktop/NewTest
    
    Signing Identity:     "Sign to Run Locally"
    
    /usr/bin/codesign --force --sign - …/Debug-iphonesimulator/NewTest.app

In the successful case you’re building the app for the simulator. This uses ad hoc code signing — aka Sign to Run Locally — and thus doesn’t need an Apple Development signing identity.

Earlier I wrote:

4. Make sure your iOS device is still selected at the run destination.

and:

5. Choose Product > Run.

so I was expecting to see the full build log from a device build, not a simulator build.

Please retry steps 1 through 6 and see what you get.

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

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.

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.

My LLM says

Again, I caution you about putting too much trust in the output generated by your LLM, especially when it comes to code signing. There’s a lot of bad information on that topic out there on the Internet, and the LLMs have ingested it all.

Regarding the names of your credentials, that’s not the smoking gun you think it is. I built and ran an app using the DTS account. In the Xcode full build log I see this:

    Signing Identity:     "Apple Development: Quinn Quinn (EW7W773AA7)"

If I look in Keychain Access, I see that the certificate has the name Apple Development: Quinn Quinn (EW7W773AA7) and the private key has the name Apple Development: Quinn Quinn (TEAM_NAME), where TEAM_NAME is the DTS test team name. So that discrepancy is expected.

I have done lots of tests involving creating keys, certificates and importing p12 files.

Right. I fear all of that work has confused things more than necessary. However, it’s hard to tell exactly what the problem is from afar.

Here’s a new test:

1. Create a new user account on your Mac mini. (Yep, another one. Don’t reuse the account from your previous tests.)

2. Log in as that user.

3. Dump the login keychain and the digital identity list:

   % security dump-keychain ~/Library/Keychains/login.keychain-db
   % security find-identity
   

   Save this to a before.txt file.

4. Launch Xcode.

5. In Xcode > Settings > Apple Accounts, sign in to your Apple Account.

6. Create a new project from the iOS > App template.

7. In Signing & Capabilities, select the team from step 4.

8. Select Any iOS Device as your run destination.

9. Build the project. This should fail as before.

10. Now repeat step 3:

    % security dump-keychain ~/Library/Keychains/login.keychain-db
    % security find-identity
    

    Save this to a after.txt file.

If you diff before.txt and after.txt you should see an item like this show up in the keychain dump:

keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x00000010 
attributes:
    0x00000000 <uint32>=0x00000010 
    0x00000001 <blob>="Apple Development: …"
    …
    0x00000006 <blob>=0xB1A1A627A1A2B9DEDB5BF16BEBA0360E6D01768B  …
    …

The class: 0x00000010 indicates that this is a private key.

You’ll also see a bunch of certificate items show up, all with class: 0x80001000. Most of these are intermediates:

keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x80001000 
attributes:
    …
    "labl"<blob>="Apple Worldwide Developer Relations Certification Authority"
    …
keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x80001000 
attributes:
    …
    "labl"<blob>="Apple Worldwide Developer Relations Certification Authority"
    …
keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x80001000 
attributes:
    …
    "labl"<blob>="Developer ID Certification Authority"
    …
keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x80001000 
attributes:
    …
    "labl"<blob>="Developer ID Certification Authority"
    …

These don’t matter for the purposes of this test. However, there should be an item like this:

keychain: "/Users/quinn/Library/Keychains/login.keychain-db"
version: 512
class: 0x80001000 
attributes:
    …
    "hpky"<blob>=0xB1A1A627A1A2B9DEDB5BF16BEBA0360E6D01768B …
    …
    "labl"<blob>="Apple Development: MY_EMAIL (…)"
    …

Note how the hpky attribute on the certificate matches the 0x00000006 attribute on the private key. This is what the system uses to pair up the private key and certificate to form a digital identity.

Please run this test and reply back here with the results.

IMPORTANT It should be reasonably safe to share before.txt and after.txt here, but if you have any concerns about that you can send them privately by replying to the email I sent you on DTS case 20272957. But make sure to reply here as well, because I look at the forums more often.

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

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

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.

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

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.

the private key and certificate are correctly paired

It certainly looks that way to me. Is that reflected in Keychain Access as well:

1. Log in as your test user.
2. Launch Keychain Access.
3. Switch to the Certificates tab.
4. Find your “Apple Development: XYZ” certificate.
5. Does it have a disclosure chevron next to it?
6. And, if so, does clicking that reveal the expected “Apple Development: ABC” private key?

Regardless of the answers to questions 5 and 6, please take a screenshot of the Keychain Access window and post it here.

Also, in after3.txt, I see the output from security find-identity but not the specific command you ran. I want to make sure you ran the command I specified:

% security find-identity

rather than the command that you mentioned in your original post.

Your command applies additional search criteria, and if you did run that then there are other possibilities for me to explore.

Finally, one last test:

1. Log in as your test user.

2. In Terminal, run this command:

   % security list-keychains
   

3. And these commands:

   % security dump-trust-settings
   SecTrustSettingsCopyCertificates: No Trust Settings were found.
   % security dump-trust-settings -d
   SecTrustSettingsCopyCertificates: No Trust Settings were found.
   

4. And then post the results here as a text attachment.

Note The easiest way to do this is to choose Shell > Export Text As in terminal. That way you get both the command and its output.

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

[1] That is, security find-identity -v -p codesigning.

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

I'm not proficient using Terminal and Export Text didn't work for me

I was referring to the Export Text As menu item. You can find it on the Shell menu. But…

so I posted screenshots of Keychain Access, the terminal commands … and part of the info for the Certificate.

That’s good enough. It successfully ruled out my other theory as to what might be going wrong.

Thanks again for your time looking into this

No worries. I’ve investigated a lot of code signing problems over the years, and this is probably one of the weirdest ones. I’m gonna resort to some desperate measures soon, but first… one more test.

Your Keychain Access screenshot shows that you’ve selected All Items at the top. To see the chevron you need to select either My Certificates or Certificates. If My Certificates is empty, please post a screenshot of Keychain Access with Certificates selected.

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