Platforms: Ventura and Big Sur
Steps to Reproduce:
- Create new application and installer CSRs with keypairs
- Generate new certificates in Apple web portal
- Repackage certificates as .p12 using exported private keys since they are not referenced in keychain app by default.
- Import certificates into MacOS Keychain
- Set certificate access to "Always Trust" for all certificate uses
- Sign binary fails using "codesign --force --sign <certificate> <filepath>"
- Sign installer package succeeds using "productsign --sign <certificate> <input filepath> <output filepath>
Additional Info:
- The private keys ware initially not recognized by the Keychain application resulting a certificate without a private key "leaf" beneath them. To resolve it I exported the private key and repackaged certificate as a .p12 file.
- Both certificates appear "good" when evaluated for code signing
- The installer certificate shows an intermediate and root while the application certificate does not
- Repackaging as .p12 with expected intermediate and root did not resolve the issue
- Installing all available intermediates and roots from Apple did not resolve the issue
- Signing a test app with XCode succeeds
- In production, we sign using CMake so we need to be able to sign code from the command line with codesign.
This is almost always a mistake. Code signing certificates should be trusted by default; if they’re not, it’s a sign that something has gone wrong, and doing this is just masking the real issue.
As to what’s actually going wrong, I talk about this in Resolving errSecInternalComponent
errors during code signing and the related Fixing an untrusted code signing certificate. The most common cause is a missing intermediate, as discussed in that second post.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"