Unable to codesign my *.app (error: unable to build chain to self-signed root for signer)

Have you installed the Apple Worldwide Developer Relations Certification Authority intermediate? Most folks use Xcode which takes care of this for them. If you’re signing directly from the command line, you may need to install that yourself.

You can get it from the Apple PKI page.

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

Hi Eskimo,

As you suggested, I have added WWDR Certificate (Expiring 02/07/2023 21:48:47 UTC)
WWDR Certificate (Expiring 02/20/2030 12:00:00 UTC) and
Worldwide Developer Relations - G2 Certificate to Keychain Access.

Code Block 
λ ~/ sudo security find-identity /Users/ambu/Library/Keychains/login.keychain-db
Policy: X.509 Basic
  Matching identities
  1) AFF80D6344B85AC51D5A44443B9AA5FF7B09A824 "Apple Development: Amritpal Singh (KC65BTVN4Z)" (CSSMERR_TP_NOT_TRUSTED)
     1 identities found
  Valid identities only
  1) AFF80D6344B85AC51D5A44443B9AA5FF7B09A824 "Apple Development: Amritpal Singh (KC65BTVN4Z)" (CSSMERR_TP_NOT_TRUSTED)
     1 valid identities found
λ ~/ sudo security find-identity -v -p codesigning
  1) AFF80D6344B85AC51D5A44443B9AA5FF7B09A824 "Apple Development: Amritpal Singh (KC65BTVN4Z)" (CSSMERR_TP_NOT_TRUSTED)
     1 valid identities found

But, while code sign *.app, I still getting same error:

Code Block 
λ ~/ sudo codesign  --force -s "Apple Development: Amritpal Singh (KC65BTVN4Z)" /Users/ambu/Documents/creoox/FreeCAD-AppImage/conda/osx_dev/APP/HyperBIM-v0.36.app/
Password:
/Users/ambu/Documents/creoox/FreeCAD-AppImage/conda/osx_dev/APP/HyperBIM-v0.36.app/: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development: Amritpal Singh (KC65BTVN4Z)"
/Users/ambu/Documents/creoox/FreeCAD-AppImage/conda/osx_dev/APP/HyperBIM-v0.36.app/: errSecInternalComponent

Do you have any guess where I am wrong?

Thanks in advance!

The next most common cause of this problem is a custom trust setting on one of the certificates involved. Use Certificate Assistant to view that chain of certificates:

1. Run Keychain Access.

2. Select your Apple Development: Amritpal Singh (KC65BTVN4Z) certificate.

3. Choose Keychain Access > Certificate Assistant > Evaluate “Apple Development: Amritpal Singh (KC65BTVN4Z)”.

4. Select Code Signing and click Continue.

5. Click Show Certificates to view the chain.

You can then open each certificate in Keychain Access and check its trust settings. To do this:

1. Find the certificate in Keychain Access.

2. Double click it

3. Click the disclosure triangle to display the Trust section.

4. Confirm that the first popup is set to Use System Defaults and the remaining ones are set to “no value specified”.

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

The next most common cause of this problem is a custom trust setting on one of the certificates involved. Use Certificate Assistant to view that chain of certificates:
Run Keychain Access.
Select your Apple Development: Amritpal Singh (KC65BTVN4Z) certificate.
Choose Keychain Access > Certificate Assistant > Evaluate “Apple Development: Amritpal Singh (KC65BTVN4Z)”.
Select Code Signing and click Continue.
Click Show Certificates to view the chain.

As you suggested, I able to see the whole chain

Apple Root CA -> Apple Worldwide Developer Relations Certification Authority -> Apple Development: Amritpal Singh (KC65BTVN4Z)

and clicking on all three certificates in Certificate Assistant dialog, it shows This certificate is valid.

You can then open each certificate in Keychain Access and check its trust settings. To do this:
Find the certificate in Keychain Access.
Double click it
Click the disclosure triangle to display the Trust section.
Confirm that the first popup is set to Use System Defaults and the remaining ones are set to “no value specified”.

Unfortunately, after changing trust of certificate to "Use System Defaults" and the remaining ones are set to “no value specified” I still getting same error. I also tried to change trust to "Always Trust" but it also not change anything.


If codesign tool create problem here, then can we use Xcode to sign my *.app folder. I tried to open *.app folder but Xcode but it throw an error Could not open file. (<path>/my.app).

Could you tell me the tutorial/process to sign *.app folder using Xcode (GUI or CLI)?

Thanks

If codesign tool create problem here, then can we use Xcode to sign my
*.app folder.

Xcode can only sign code that it builds. Based on the snippets in your original post I presumed that you’re not building your app with Xcode.

Could you tell me the tutorial/process to sign *.app folder using …
CLI … ?

I generally point folks to my Signing a Mac Product For Distribution. This won’t help here though, because you’ve fallen at the first hurdle.

Unfortunately, after changing trust of certificate to "Use System
Defaults" and the remaining ones are set to “no value specified” I
still getting same error.

Does that mean they were previously set to different values?

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

Xcode can only sign code that it builds. Based on the snippets in your original post I presumed that you’re not building your app with Xcode.

Yes, *.app is build without using Xcode.

Does that mean they were previously set to different values?

By default trust of certificates is set to "Use System Defaults" and the remaining ones are set to "no value specified". I mean I tried to signing my app with both permission "Use System Defaults" and "Always Trust" but none them solve this problem.

Oh, one more thing: Why are you running codesign using sudo? That’s generally not necessary and can cause problems [1].

I recommend that you retest this as follows:

1. Log in to the GUI of the Mac that has the Apple Development: Amritpal Singh (…) identity in its keychain.

2. In Terminal, run security find-identity -v -p codesigning (without the sudo) to confirm that it’s available.

3. Then use codesign (again without the sudo) to sign a simple test tool.

What do you see in that case?

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

[1] sudo switches the traditional BSD execution context to root but it does not switch the macOS-specific execution context. The codesign tool relies on the Security framework which relies on the security context. See Technote 2083 Daemons and Agents for more background on this.

Oh, one more thing: Why are you running codesign using sudo? That’s generally not necessary and can cause problems [1].
I recommend that you retest this as follows:
Log in to the GUI of the Mac that has the Apple Development: Amritpal Singh (…) identity in its keychain.
In Terminal, run security find-identity -v -p codesigning (without the sudo) to confirm that it’s available.
Then use codesign (again without the sudo) to sign a simple test tool.
What do you see in that case?

Yes, without sudo I able to signed the image.

Code Block 
$ codesign --deep -s "Apple Development: Amritpal Singh (KC65BTVN4Z)" ./HyperBIM-v0.36.app
$ codesign -d --verbose  ./HyperBIM-v0.36.app
Executable=<path>/APP/HyperBIM-v0.36.app/Contents/MacOS/HyperBIM-v0.36
Identifier=Creoox AG
Format=app bundle with generic
CodeDirectory v=20200 size=201 flags=0x0(none) hashes=1+3 location=embedded
Signature size=4816
Signed Time=03-Nov-2020 at 8:21:29 PM
Info.plist entries=17
TeamIdentifier=787KY3SBUJ
Sealed Resources version=2 rules=13 files=23070
Internal requirements count=2 size=228

Thanks Eskimo!