S/MIME Signing Breaks After a Keychain Reset
A 45-person law office signs and encrypts mail with S/MIME in Apple Mail and Outlook for Mac. Certificates come from an internal CA and are delivered by an MDM PKCS#12 payload scoped to a smart group of Macs; the same certificate is published to the directory so outsiders can encrypt to users. A user's login keychain was corrupted; a technician deleted and recreated it without backing it up, then reset the login password. Mail now lists the certificate but reports no private key when signing, and colleagues who fetch the directory certificate cannot encrypt to the user. The certificate expires in three weeks. The Mac is FileVault-enabled; the user and an MDM admin account hold secure tokens. The MDM payload's private key has 'allow export' disabled, and the payload is still installed.
1. The certificate is visible in Mail, but signing reports no private key. Explain what was lost and why reinstalling the same MDM payload may not restore it.
Read the worked answer
An S/MIME identity is a certificate plus its matching private key. The certificate can be imported or fetched from the directory independently, which is why Mail lists it. The private key lived in the login keychain that the technician deleted. If the MDM payload is still recorded as installed, the MDM will not re-push it just because the keychain item vanished; and even a re-push may fail if the PKCS#12 password or keychain ACL is stale. The keychain password reset also matters: the recreated login keychain has a new password, and the old keychain items are gone unless a backup exists. Secure tokens do not recreate private keys. The only reliable fix is to obtain a new identity with a new keypair from the CA, unless an archived copy of the original PKCS#12 exists in a controlled escrow.
2. Give the order for restoring signing and encryption for this user, including directory publication and revocation.
Read the worked answer
Generate a new keypair and CSR on the Mac or via the MDM, have the CA issue a new certificate, and install it with its private key into the login keychain. Verify the identity with security find-identity -v -p smime and sign a test message. Set Mail's signing preference to the new identity. Publish the new certificate to the directory before revoking the old one; otherwise colleagues may fetch a revoked certificate and encryption will fail. Keep the old certificate and, if available, its private key for decrypting archived mail until the retention period ends. Revoke the old certificate only after the new one is published and the user has sent a successful signed message. Because the old certificate expires in three weeks, this overlap is short but still necessary. Do not simply delete the old certificate from the login keychain; that can make old messages unreadable.
3. What changes prevent a repeat when a help-desk technician encounters a corrupt login keychain?
Read the worked answer
Treat the login keychain as data, not a cache. The runbook should require a backup or export of keychain items before any deletion, and a check for S/MIME identities and other private keys. If the keychain is corrupt, create a new keychain and migrate items rather than deleting the only copy; if that is impossible, escalate to the security team before proceeding. Keep an inventory that maps users to certificate serial numbers and expiration dates so a missing identity is detected. For S/MIME, use a CA that supports reissuance and a documented escrow or recovery process; escrowing private keys is a policy decision with real risk, so it should be explicit rather than accidental. Finally, test signing and encryption after any keychain or password reset, not just login.