App Extension Network Extension - failed to start, signature check failed

App is not sandboxed, NE is sandboxed. Network extension entitlements (packet-tunnel) are specified for both targets.

The first thing to rule out is the device not actually being included in the profile. Do this:

1. Dump the profile of the app:

   % security cms -D -i MyApp.app/Contents/embedded.provisionprofile 
   

2. Dump the profile of the provider:

   % security cms -D -i MyApp.app/Contents/PlugIns/MyAppEx.appex/Contents/embedded.provisionprofile
   

3. Check that the ProvisionedDevices lists match.

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

Failing device is mentioned in provisioning profiles for both app and appex (matching Provisioning UDID).

This log also appears on another device where everything's fine, not sure if it's relevant or what to make of it:

(NetworkExtension) [com.apple.networkextension:] Provider is not signed with a Developer ID certificate

For now assuming it's just noise and the true issue is in signature/smth else validation.

Noticed an interesting thing: if I try to run .app built and signed on the failing device after allowing it via security settings ("Open Anyway") and removing quarantine, then NE gets registered and also started successfully.

I also compared entitlements, signatures and provisioning profiles for both app and appex. They all seem to match for .app bundles done on both devices.

Hmmm. You are somewhat crossing the streams here. Development-signed builds are intended for development machines, and there’s an implicit assumption that apps built on development won’t be quarantined.

Normally I’d suggest you get around that by following the Developer ID path — signing with Developer ID and then notarisation — but that’s not really feasible for an NE appex, because we don’t support those for Developer ID. Directly distributed apps have to use a sysex. And converting an appex to a sysex is not a trivial task.

Except…

Are you ultimately planning to ship this app on the Mac App Store? If not, you might as well grasp the sysex nettle now.

For detailed info about NE distribution limitations, see TN3134 Network Extension provider deployment.

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

Looking into the sysex vs appex, thanks. We probably want to support both eventually, but at the moment the app is distributed on our own with Developer ID signing + notarizing.

Also, somehow the issue in the post was cause by a previously installed (6 months ago or more) iOS version of the very same app (same identifier for the app and NE). TestFlight iOS app was also somewhere in /Applications and probably affected developer build of the mac version.

After deleting the iOS TestFlight version of the app we managed to finally run in Debug mode on the failing device.

issue … was cause by a previously installed … iOS version of the very same app

Oh, wow. That makes sense [1], but it’s not something I would’ve thought of. Thanks for the titbit.

at the moment the app is distributed on our own with Developer ID signing + notarizing.

OK. In that case you need to get on to the sysex train, because we only support appex packaging in Mac App Store apps. Again, TN3134 is a key reference here.

I really need to write up a doc that explains… oh wait, Past Quinn™ has done as a solid here! See Network Extension Provider Packaging.

Finally, watch out for the pitfall described in Exporting a Developer ID Network Extension.

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

[1] TN3134 explains how macOS is able to use NE tunnel provider from iOS Apps on Mac, and it’s easy to see how that could cause problems if you then tried to start a native version.