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

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)

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)

HI @DTS Engineer! I think my reply on your suggestion where miss under comment section. Here is the link for libapr for arm architecture. https://we.tl/t-49G2iDOINJ And this is for intel architecture https://we.tl/t-i1sw6BTwEI 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

Hi @DTS Engineer! Coming back to your last comment, finally we have time to come back and try the dirty workaround. For the sake of delivering our app, by removing the signature and adding it with ours fix the issue. As you pointed out, I will need to raise a issue on Github, to at least make them aware of it. Thanks for all the help with this.