Issues while signing macOS app

Hi everyone!

We use to have an intel Mac machine where we generate the Developer ID Installer & Application certs for signing and notarization process. This process works sweet.

Now, we move from an intel to a m1 Mac machine, where we want to do the same process as before. I had try two different approaches, but ending up with the same result.

  1. I export the cert with the private key from my intel to the m1 machine, but when I try to sign, I get: Invalid signature. (Not sure what this error means in this case as everything works on the intel machine. I am guessing the cipher for creating either the private key or the signature differs between the architecture)
  2. I try to generate new certs for this m1 machine, but I get the following error: You already have a current Developer ID installer certificate or a pending certificate request. I try with the same account, but also with a different account. In both cases got the same error.

I create a ticket for apple, where they said to expect a reply between one and two business days, but no luck yet.

Up vote post of JosephSalazar Down vote post of JosephSalazar
221 views
Posted by
JosephSalazar
Reply

  • In the first approach, do you see your imported certificate and private key under "My Certificates" in Keychain Access? Do you see your imported certificate in Xcode's Settings > Accounts when you click "Manage Certificates"?

    —
    JWWalker

  • I check Keychain to make sure I can see the cert + private key. Everything looks well on Keychain. We are not using Xcode for it, the code is written in another language. (Electron.js)

    —
    JosephSalazar
Add a Comment

Replies

I try to generate new certs for this m1 machine

It sounds like you’re trying to create a new Developer ID certificate. That’s not a good way forward. I talk about this in depth in The Care and Feeding of Developer ID.

I export the cert with the private key from my intel to the m1 machine

Moving a Developer ID signing identity via a .p12 file should work. I do that regularly.

but when I try to sign, I get: Invalid signature.

Can you elaborate on that? Is it failing in Xcode? Or are you signing with codesign? Does it fail with all programs? Or just with your main product? And are you signing from Terminal? Or in some other context, like SSH or in a CI environment?

For context, here’s a simple way to test your codesign setup:

% cp /usr/bin/true MyTrue
% codesign -s "Developer ID Application" -f "./MyTrue" 
./MyTrue: replacing existing signature

If you run that from Terminal, what do you see?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

It sounds like you’re trying to create a new Developer ID certificate

Yes, it is not the best approach as you highlight here and in the other thread, but was a desperate approach as we had tight time before releasing 😅

Can you elaborate on that? Is it failing in Xcode? Or are you signing with codesign? Does it fail with all programs? Or just with your main product? And are you signing from Terminal? Or in some other context, like SSH or in a CI environment?

We ship an application as a pkg. This PKG includes a progressive web app coded in Electron.js. Inside this Electron app we add two binaries plus some dependencies to run. One of it is an executable binary and the other one is a dynamic library. For all of them, we signed and notarized (Works well on the intel machine). Also, important to mention we ship outside AppStore that is why we follow a process outside Xcode.

We run: codesign --sign "Developer ID Application:TTT" --deep --force --options runtime --entitlements entitlements.mac.plist <file>, where file are all the binaries (the ones we code and the third-party libraries. Also, the ones we code are in c++).

This is the output of the error when we try to sign an external library or our executables:

<name>.dylib: invalid or unsupported format for signature

Something important to mention is this libraries comes from each native architecture. We downloaded through brew. The ones owned by use, are built for each native architecture as well.

Also, try your suggestion for testing codesign. It kind of work, but I get an extra line:

MyTrue: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Developer ID Application: TTT"
/MyTrue: errSecInternalComponent
Posted by
JosephSalazar
Up vote reply of JosephSalazar Down vote reply of JosephSalazar
Add a Comment

try your suggestion for testing codesign. It kind of work, but I get an extra line:

Getting that working is a first step. See Resolving errSecInternalComponent errors during code signing.

We run: codesign … --deep …

Don’t signed code with --deep. See --deep Considered Harmful.

Rather, sign your code and installer package using the processes described in:

That’ll either fix the problem or it won’t. If it doesn’t, it’ll at least show you which code item is failing, and you can debug from there.

This is the output of the error when we try to sign an external library or our executables:

… invalid or unsupported format for signature

Hmmm, that’s a new one on me. If you put that .dylib in a directory by itself and run the equivalent of my MyTrue example, do you see the same problem?

If so, what does file report?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

errSecInternalComponent

I was able to fix this issue by noticing in keychain the cert were checked to Always Trust. As soon as I change it to "Use System Defaults", the extra warning was gone.

Hmmm, that’s a new one on me. If you put that .dylib in a directory by itself and run the equivalent of my MyTrue example, do you see the same problem?

I try to sign a third-party lib with the same command as MyTest codesign -s "Developer ID Application" -f "./libapr.dylib" and it gives the same output: libapr.dylib: invalid or unsupported format for signature

I can attach the dylib, or you can downloaded from internet. The name is libapr. (I get it from brew as a dependency of liblog4cxx)

Posted by
JosephSalazar
Up vote reply of JosephSalazar Down vote reply of JosephSalazar
Add a Comment

I was able to fix this issue

Yay!

As to the libapr.dylib, I can’t seem to find a binary to download (and I don’t have time to build it from source). Can you post the binary to a file sharing service and then reply here with the link?

Post the link in the clear, per Quinn’s Top Ten DevForums Tips.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • Here is the link for libapr for arm architecture.

    https://we.tl/t-ioE6QZmlb2

    And this is for intel architecture

    https://we.tl/t-fKKJKYaLx6

    Something I try, and works in terms of signing is to create a universal binary with lipo command. But in this case, we need to shipped them for the native architecture

    —
    JosephSalazar
Add a Comment