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.
Set certificate access to "Always Trust" for all certificate uses
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"