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