unsatisfied entitlements macOS app

Question

Created Jan ’24

Replies 4

Boosts 0

Views 1.1k

Participants 2

I recently built an update to one of our apps, which installs a driver extension. The new version won't launch on my Mac, Finder says it "can't be opened".

I captured the logs, which say "no matching profile found":

error	2024-01-10 14:36:03.306061 -0800	taskgated-helper	<app-bundle-id>: Unsatisfied entitlements: com.apple.developer.system-extension.install, com.apple.developer.team-identifier
info	2024-01-10 14:36:03.306279 -0800	amfid	Requirements for restricted entitlements failed to validate, error -67671, requirements: '<private>'
error	2024-01-10 14:36:03.306287 -0800	amfid	Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=<private>, unsatisfiedEntitlements=<private>, NSLocalizedDescription=No matching profile found}
default	2024-01-10 14:36:03.306432 -0800	amfid	/Applications/<app-bundle-id>/Contents/MacOS/<app-name> not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/C<escaped-app-name>/, unsatisfiedEntitlements=<CFArray 0x14f3041d0 [0x1dd7d39a0]>{type = immutable, count = 2, values = (
	0 : <CFString 0x14f3055a0 [0x1dd7d39a0]>{contents = "com.apple.developer.system-extension.install"}
	1 : <CFString 0x14f304130 [0x1dd7d39a0]>{contents = "com.apple.developer.team-identifier"}
)}, NSLocalizedDescription=No matching profile found}
default	2024-01-10 14:36:03.306514 -0800	kernel	AMFI: bailing out because of restricted entitlements.
default	2024-01-10 14:36:03.306523 -0800	kernel	mac_vnode_check_signature: /Applications/<app-bundle-id>/Contents/MacOS/<app-name>: code signature validation failed fatally: When validating /Applications/<app-bundle-id>/Contents/MacOS/<app-name>:
  Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements: com.apple.developer.system-extension.installcom.apple.developer.team-identifier

The thing is, when I run this command

codesign -v -vvv  <path-to-app>

the app is valid on disk and satisfies its Designated Requirement

and these two commands:

codesign --display --entitlements - security cms -D -i <path-to-app>/Contents/embedded.provisionprofile

when run against the old app (which works) and the new app (which doesn't) have absolutely identical outputs. The certificates haven't expired yet.

Where else should we be looking to figure out where we've messed up? We know we changed the signing and notarization flow; the working build was made by a person using Xcode, the new app was built, signed and notarized using the command line tools (xcodebuild and notarytool).

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’24

That list of unsatisfied entitlements is kinda weird, in that I’d expect to see the App ID entitlement (com.apple.application-identifier) there too because that’s how the system matches your code to your profile.

The certificates haven't expired yet.

You should check that the profile lists the right certificates. Also check the profile expiration date. I have a bunch of info about debugging this stuff in TN3125 Inside Code Signing: Provisioning Profiles and the various posts hanging off Resolving Trusted Execution Problems.

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

0

Answer 2

ssmith_c OP

Jan ’24

@eskimo thanks for the reply codesign --display --entitlements does show a com.apple.application-identifier is present, it is the same for both apps - the bundleID prefixed by our teamID.

security cms -D on the embedded.provisionprofile shows the same result for both apps, including the same com.apple.application-identifier value in the Entitlements section.

The working and non-working app both refer to the same certificate, with the same serial number, hash and expiration date.

The profile for both the working and non-working app expires Sep 23, 2040 at 9:36:53 AM PDT

The The plists differ a little, because the two apps were built on different Macs with different toolchains.

BuildMachineOSBuild good 22A400, bad 22G90
DTPlatformBuild, good 14A309, bad <empty string>
DTPlatformVersion, good 12.3, bad 13.3
DTSDKBuild good 21E226, bad 22E245
DTSDKName good macosx12.3, bad macosx13.3
DTXcode good 1400 bad 1430
DTXcodeBuild good 14A309, bad 14E222b

I ran spctl --assess -vvv on the bad app, which said accepted

I edited this post, previously I said spctl claimed the bundle format was unrecognized. That was my error - I passed it a path to the app which has spaces in its name with un-escaped spaces. Instead of it telling you that the path doesn't exist, spctl says it is broken.

I don't know whether to believe that, because the system log tells me something else. Also, the bundles are almost identical. The "good" app has an additional profile, "embedded.mobileprovision". Which one does the OS use, and why is there an embedded.mobileprovision file in a macOS app?

I'll have another look at those links you cited, thanks

0

Answer 3

ssmith_c OP

Jan ’24

I tried the new tool, syspolicy_check. It said (rightly) that we'd forgotten to staple the notarization. My Mac has Internet access to that won't make any difference, but I stapled it anyway. The results didn't change - the app won't launch.

0

Answer 4

ssmith_c OP

Jan ’24

Further progress here. Following the instructions in TN3125, I find that the certificate inside the .mobileprovision file is expired after all! The steps were:

remove the cms (Cryptographic Message Syntax wrapper)

security cms -D -i <path-to-app>/embedded.provisionprofile -o badapp-payload.plist

eyeball the badapp-payload.plist file, verifying that it includes a DeveloperCertificates section

extract the first certificate

plutil -extract DeveloperCertificates.0 raw -o - badapp-payload.plist | base64 -D > cert0.cer

inspect the certificate

certtool d cert0.cer

which says

Not After : 21:10:25 Sep 21, 2023

so, big oops on our part. Hopefully someone aside from myself can learn something from this, I'll post if the problems are all fixed by using a valid certificate.

0