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

Question

jmb2013 OP

Created 1w

Replies 2

Boosts 0

Participants 1

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

Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer.

Environment

Mac Mini M4, macOS 15.4.1 (Build 25E253)
Xcode 26.4.1 (17E202)
Team ID: Q23726668V (Computerade Products)
Working comparison machine: MacBook Air, macOS 15.3

Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities.

Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates:

Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F
Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff

These do not match ❌

Confirmed Eliminated As Causes

Keychain search list corruption — found and fixed
Partition list — set correctly
Access control — set to allow all applications
Full Disk Access — granted to Xcode
Xcode caches and preferences — completely cleared
Login keychain — completely reset
Orphaned certificates and keys — all removed
SIP enabled, system fully up to date

Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini:

security import returns MAC verification failed
Keychain Access import returns OSStatus -2
Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7

Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides?

The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

Boost

Answer 1

jmb2013 OP

1d

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.

0

Answer 2

jmb2013 OP

17h

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.

0