Code signature validation failed fatally

seeing this error when I am trying to install my network extension:

_macvnodechecksignature: /Applications/abc.app/Contents/MacOS/abc: code signature validation failed fatally: When validating /Applications/abc.app/Contents/MacOS/abc:
  Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements:
__

I have set the right entitlements as far as I know . is this error about entitlements or signature that is not obvious from the message .

this is sseen on Catalina 10.15.6
the macOS Network extension is Developer ID signed .
still facing this error . any idea what will fix this error ??

Post not yet marked as solved Up vote post of Babse Down vote post of Babse
5.8k views

Replies

In this context “restricted entitlements” means “entitlements that must be allowlisted by a provisioning profile”. I recommend you do the following and check that everything in the first list is allowed by the second list:

Code Block
% codesign -d --entitlements :- /Applications/abc.app
% security cms -D -i /Applications/abc.app/Contents/embedded.provisionprofile


Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
  • I came here from google trying to resolve a similar issue but I don't have a file called embedded.provisionprofile anywhere in my .app folder. I also don't see it in other apps I've installed from the App Store. Did something change in the last year since this post was made where these aren't distributed any longer? Is there an equivalent way today for me to compare my entitlements against the prov profile?

Add a Comment
thank you --!

i see that everything in the first is allowed in second . Dumping the output here

Entitlement for app
Code Block
<dict>
    <key>com.apple.application-identifier</key>
    <string>TeamID.com.company.abcappn</string>
    <key>com.apple.developer.networking.networkextension</key>
    <array>
        <string>content-filter-provider</string>
    </array>
    <key>com.apple.developer.system-extension.install</key>
    <true/>
    <key>com.apple.developer.team-identifier</key>
    <string>TeamID</string>
</dict>
 

 In the Embedded Profile for app
Code Block
key>Entitlements</key>
      <dict>                   
                      <key>com.apple.developer.system-extension.install</key>
           <true/>
                      <key>com.apple.developer.networking.networkextension</key>
           <array>
                      <string>packet-tunnel-provider-systemextension</string>
                      <string>app-proxy-provider-systemextension</string>
                      <string>content-filter-provider-systemextension</string>
                      <string>dns-proxy-systemextension</string>
                      <string>dns-settings</string>
           </array>
                      <key>com.apple.application-identifier</key>
           <string>TeamID.com.company.abcappn</string>
                      
                      <key>keychain-access-groups</key>
           <array>
                      <string>TeamID.*</string>
           </array>
                      
                      <key>com.apple.developer.team-identifier</key>
           <string>TeamID</string>
 
      </dict>


Anything else you suggest need to be examined .
Do you have entitlements set on any non-main-executable code? Like frameworks? Or shared libraries?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
No . only on container app and extension .

No. Only on container app and extension.

OK, thanks for checking.



Looking back through this thread I just noticed something (sorry I didn’t pick this up before). Earlier you wrote:

i see that everything in the first is allowed in second.

but that’s not the case. Specifically, in the app’s entitlements you have content-filter-provider but profile you have content-filter-provider-systemextension. If you’re distributing independently using Developer ID, you must use content-filter-provider-systemextension.

Share and Enjoy

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

Do you have entitlements set on any non-main-executable code? Like frameworks? Or shared libraries?

@eskimo, I do codesign using entitlements on frameworks and I'm seeing this error in macOS 10.15, 11.* and 13.* mapping to one of my frameworks when I launch the app. Any idea what the entitlements should look like when code signing frameworks?

My current entitlements

  [Key] com.apple.application-identifier
	[Value]
		[String] HXXXXXXX.bundle.id
	[Key] com.apple.developer.aps-environment
	[Value]
		[String] production
	[Key] com.apple.developer.team-identifier
	[Value]
		[String] HXXXXXXX
	[Key] com.apple.security.automation.apple-events
	[Value]
		[Bool] true
	[Key] com.apple.security.cs.disable-library-validation
	[Value]
		[Bool] true
	[Key] com.apple.security.device.audio-input
	[Value]
		[Bool] true
	[Key] com.apple.security.device.camera
	[Value]
		[Bool] true
	[Key] com.apple.security.temporary-exception.mach-lookup.global-name
	[Value]
		[Array]
			[String] $(PRODUCT_BUNDLE_IDENTIFIER)-spks
			[String] $(PRODUCT_BUNDLE_IDENTIFIER)-spki

Provisioning profile entitlements

&lt;key>com.apple.developer.aps-environment&lt;&#x2F;key>
		&lt;string>production&lt;&#x2F;string>
				
				&lt;key>com.apple.application-identifier&lt;&#x2F;key>
		&lt;string>HXXXXXXX.bundle.id&lt;&#x2F;string>
				
				&lt;key>keychain-access-groups&lt;&#x2F;key>
		&lt;array>
				&lt;string>HXXXXXXX.*&lt;&#x2F;string>
		&lt;&#x2F;array>
				
				&lt;key>com.apple.developer.team-identifier&lt;&#x2F;key>
		&lt;string>HXXXXXXX&lt;&#x2F;string>

Any idea what the entitlements should look like when code signing frameworks?

Frameworks should not claim entitlements. There are two reasons for this:

  • Such claims are ineffective. The system only honours the entitlements applied to the a process’s main executable.

  • Such claims can cause trusted execution problems, as the system tries to authorise the claims with a provisioning profile that doesn’t exist.

I call this out specifically in Creating Distribution-Signed Code for Mac.

Most folks who run into the problem do so because they sign with the --deep flag. I specifically recommend against that; see --deep Considered Harmful for the details.

Share and Enjoy

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

@eskimo, thanks for the reply. I tried removing --deep flag while signing and still see below error when I launch the app.

Notes:                 Translocated Process

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x5] Code Signature

Dyld Error Message:
  Library not loaded: @rpath&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;***
  Referenced from: &#x2F;private&#x2F;var&#x2F;folders&#x2F;*&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;***
  Reason: no suitable image found.  Did find:
	&#x2F;private&#x2F;var&#x2F;folders&#x2F;8k&#x2F;lq520j255vx959w2gz3rl1sw0000gn&#x2F;T&#x2F;AppTranslocation&#x2F;A032D364-17F7-4515-A59C-B9CCBAC0A539&#x2F;d&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;..&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;***: code signature invalid for &#039;&#x2F;private&#x2F;var&#x2F;folders&#x2F;8k&#x2F;lq520j255vx959w2gz3rl1sw0000gn&#x2F;T&#x2F;AppTranslocation&#x2F;A032D364-17F7-4515-A59C-B9CCBAC0A539&#x2F;d&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;..&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;***&#039;

And below is my codesign order

codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;***\ ***.driver
codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Library&#x2F;LaunchServices&#x2F;com.xxxx.privilegedHelper
codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;***&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;***
codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;daemon&#x2F;xxxr.app&#x2F;Contents&#x2F;MacOS&#x2F;***
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Resources&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;***
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Resources&#x2F;***
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Libraries&#x2F;***.dylib
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Libraries&#x2F;***.dylib
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Libraries&#x2F;***.dylib
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Resources&#x2F;upload-symbols
codesign -s "Developer ID Application" -f --timestamp -o runtime --entitlements $entitlement -f ***.app

It’s likely that your code signature is simply borked. Try this:

% codesign --verify -vvv --strict --deep &#x2F;path&#x2F;to&#x2F;your.app

Note that using --deep in a --verify operation is just fine (-:

The most common cause of this problem for frameworks is folks copying the framework using cp -r, which doesn’t preserve symlinks.

And below is my codesign order

Hmmm…

codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;***\ ***.driver

This is a worry. Presumably this .driver bundle contains code, which means it shouldn’t be in the Resources directory. See Placing Content in a Bundle.

codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;***&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;***

I’m presuming that’s this is some sort of helper tool rather than the main executable for the containing .app.

codesign -s "Developer ID Application" --options=runtime,library --timestamp -f ***.app&#x2F;Contents&#x2F;Resources&#x2F;daemon&#x2F;xxxr.app&#x2F;Contents&#x2F;MacOS&#x2F;***

This is also worrying. In general, when signing bundled code, you should sign the bundle, not the specific executable.

Also, this is nested code and doesn’t belong in the Resources directory.

codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Resources&#x2F;***.app&#x2F;Contents&#x2F;MacOS&#x2F;***

This has the same issues as above.

codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Resources&#x2F;***
…
codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Resources&#x2F;upload-symbols
…

I suspect that these are both helper tools and thus, again, don’t belong in Resources.

codesign -s "Developer ID Application" --options=runtime --timestamp -f ***.app&#x2F;Contents&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;A&#x2F;Frameworks&#x2F;***.framework&#x2F;Versions&#x2F;Current&#x2F;Libraries&#x2F;***.dylib
…

I see you signing the dynamic libraries embedded within your framework but I don’t see you sign your framework as a whole.

Share and Enjoy

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

Thank you @eskimo, codesigning framework as a whole fixed my issue. Although, I do see issues when notarizing the app now

"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,

{
      "severity": "error",
      "code": null,
      "path": "***(arm64).pkg&#x2F;***.pkg Contents&#x2F;Payload&#x2F;Applications&#x2F;***&#x2F;***.app&#x2F;Contents&#x2F;Library&#x2F;LaunchServices&#x2F;com.***.PrivilegedHelper",
      "message": "The executable does not have the hardened runtime enabled.",
      "docUrl": "https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;security&#x2F;notarizing_macos_software_before_distribution&#x2F;resolving_common_notarization_issues#3087724",
      "architecture": "arm64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "***(arm64).pkg&#x2F;***.pkg Contents&#x2F;Payload&#x2F;Applications&#x2F;***&#x2F;***.app&#x2F;Contents&#x2F;Frameworks&#x2F;Sparkle.framework&#x2F;Versions&#x2F;B&#x2F;Autoupdate",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": "https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;security&#x2F;notarizing_macos_software_before_distribution&#x2F;resolving_common_notarization_issues#3087733",
      "architecture": "arm64"
    }

It gave more errors with same info. But, I already add --timestamp and --options=runtime when codesigning my app. Not sure what's missing here. Could you please take a look. I can provide more logs if needed

Regarding, your privileged helper, each executable inside your app needs to signed with the hardened runtime enabled. So, just because you’ve signed the main app that way, doesn’t help your privileged helper.

Regarding your framework, you’ll have its embedded helper tool as a separate code item.

Have another read of Creating Distribution-Signed Code for Mac. It has a general algorithm — albeit a complex one! — for signing code that covers both of these cases.

Share and Enjoy

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