Apple code signing uses a key pair. The private key is generated on your Mac when you create a CSR, and it never leaves that machine. What you send Apple is the public half, and what Apple sends back is a certificate wrapping that public half with their signature on it. Signing a build needs the private half, so a certificate on its own is useless for signing.
That is the whole explanation for this error. The certificate imported fine. The key it belongs to is somewhere else, or nowhere at all.
How to confirm it
In Keychain Access, look under My Certificates. A certificate with a usable key has a disclosure triangle next to it that expands to show the key. If the entry only appears under Certificates, with no triangle, the key is missing. From the terminal, the check is one command.
# Lists ONLY certificates that have a matching private key security find-identity -v -p codesigning # Lists certificates regardless of whether a key exists security find-certificate -a -c "Apple Distribution" -Z login.keychain-db
A certificate that shows up in the second command and not the first is the exact condition this error describes. That pair of commands is also the fastest way to check a build machine before wasting a pipeline run on it.
How it happens
- You downloaded the .cer and double-clicked it
- The most common route by a wide margin. A .cer is certificate-only by design. Downloading it on a machine that did not generate the CSR gives you exactly this state, and macOS imports it without complaint.
- New Mac, old certificate
- Machine migration that copied the certificates but not the keys, or a clean install where only the portal downloads were restored. The key was on the old disk.
- The colleague who created it has left
- The certificate is valid and in the portal, and the only copy of its key went out of the door on somebody's laptop. Apple cannot help: they never had it.
- Certificate and key ended up in different keychains
- macOS will not pair a certificate in one keychain with a key in another. Both halves have to live in the same keychain for an identity to form.
- The key was deleted during a keychain cleanup
- Private keys have unhelpful names in Keychain Access and get tidied away by people who do not recognise them. Deleting a key does not invalidate the certificate, it just makes it unusable.
If someone still has the key
- 1
Export a .p12 from the machine that has it
Keychain Access, My Certificates, right-click the certificate (not the key), Export, choose Personal Information Exchange (.p12), and set a password. Exporting the certificate entry takes the key with it.
- 2
Move it across safely
The .p12 plus its password is a complete signing identity for your team. Send it through a password manager or secret store, and send the password separately. Do not put it in a git repo or a chat thread.
- 3
Import it on the machine that needs it
Double-click the file, or use security import for a scripted setup. Then re-run security find-identity -v -p codesigning to confirm an identity now exists.
- 4
Restart Xcode
Xcode caches its view of available identities and will sometimes keep showing Missing Private Key after a successful import until it is relaunched.
# Scripted export from the source machine security export -k login.keychain-db -t identities -f pkcs12 -o signing.p12 # Import on the target machine security import signing.p12 -k login.keychain-db -P "$P12_PASSWORD" \ -T /usr/bin/codesign -T /usr/bin/security
If the key is genuinely gone
There is no recovery path. Apple only ever received the public half, so there is nothing for them to resend, and no support request will change that. What you do instead is start over with a new key.
- 1
Generate a new CSR
Keychain Access, Certificate Assistant, Request a Certificate From a Certificate Authority. Save to disk. This creates a fresh key pair in your keychain.
- 2
Create a replacement certificate in the portal
Upload the CSR and download the resulting certificate on the same machine. Apple limits how many certificates of some types a team may hold at once, so you may need to revoke the orphaned one to make room.
- 3
Regenerate every profile that referenced the old certificate
Profiles embed the certificates they authorize, so none of the existing ones know about the new certificate. This is the step people forget, and it produces a different error on the next build.
- 4
Back the new identity up properly
Export a .p12 immediately and store it where the team can get at it. A signing key that exists on exactly one laptop is a future incident.