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.