Cannot activate Network Extension signed with a Developer ID certificate

I have a simple CLI app bundle that activates my system extension.

This isn’t something we support. See this post. I recommend that you repeat these tests with code in the container app running that app in the GUI.

The entitlements are adjusted to use the -systemextension suffix to work with Developer ID certificates.

Did you also update the provisioning profile? I talk about this in same detail in Exporting a Developer ID Network Extension.

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

Thanks for your reply @eskimo . I did update the provisioning profile.

I think I'm missing the bigger picture here. In my older post I was trying to make this run from a daemon, and you recommended that I bundle that daemon as a separate app. So I followed Signing a daemon with a restricted entitlement, and it complicated things a lot, but I made it work. I encountered this same issue back then, but decided to simplify the problem and re-write the interaction with the Network Extension as a CLI that could be started from that daemon more easily without any entitlements in the daemon. It's a simple CLI, only activates/deactivates starts/stops the network extension. During development it was fine, only when signing for distribution it would fail.

If I understand correctly, the problem is that the CLI doesn't have a GUI? Could I then have a very short lived window (or perhaps just something in the dock) that applies the same logic as the CLI and exits? That'd be strange, but besides it being annoying to users, why would that not work?

Thanks!

If I understand correctly, the problem is that the CLI doesn't have a GUI?

No. The issue with the System Extensions framework is that it was designed to be called by GUI apps in response to user interactions. It was never intended to be used from a command-line environment, from installer packages, and so on. That doesn’t stop folks from trying to use it that way, but my experience is that those techniques are brittle and thus DTS doesn’t support them.

If you plan to deploy your product in a managed environment, use MDM to do this stuff. If you plan to deploy your product to normal users, I recommend that you use System Extensions framework in the way that it was intended to be used.

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

In case anyone has a similar issue, here's a script condensing my learnings from @eskimo's posts.

Take it with a pinch of salt!

# Assumes all variables are populated already, with app and extension built using a development certificate.

# Extract the entitlements from the builds. They differ from the .entitlement files in the project!
codesign -d --entitlements :- "${app_bundle}" > app.entitlements
codesign -d --entitlements :- "${extension_bundle}" > sext.entitlements

# We only use one, specify any others as needed
sed -i '' 's/'$networkEntitlement'/'$networkEntitlement'-systemextension/g' app.entitlements
sed -i '' 's/'$networkEntitlement'/'$networkEntitlement'-systemextension/g' sext.entitlements

# Copy the system extension into the app bundle
mkdir -p ${app_bundle}/Contents/Library/SystemExtensions/
ditto ${extension_bundle} ${app_bundle}/Contents/Library/SystemExtensions/${extension_bundle}

# Replace the embedded provision profiles
ditto ${app_provision_profile_path} "${app_bundle}/Contents/embedded.provisionprofile"
ditto ${extension_provision_profile_path} "${app_bundle}/Contents/Library/SystemExtensions/${extension_bundle}/Contents/embedded.provisionprofile"

# Sign the System extension bundle first, then the binary with entitlements. Both require hardened runtime
codesign -f --timestamp --options runtime --sign "${certificate_name}" ${app_bundle}/Contents/Library/SystemExtensions/${extension_bundle}
codesign -f --timestamp --options runtime --entitlements "sext.entitlements" --sign "${certificate_name}" "${app_bundle}/Contents/Library/SystemExtensions/${extension_bundle}/Contents/MacOS/${extension_id}"

# Sign the App bundle first, then the binary with entitlements. Both require hardened runtime
codesign -f --timestamp --options runtime --sign "${certificate_name}" ${app_bundle}
codesign -f --timestamp --options runtime --entitlements "app.entitlements" --sign "${certificate_name}" "${app_bundle}/Contents/MacOS/${app_name}"

# We cannot send the bundle directly to notarytool (it is a dir), zip it first.
ditto -ck --rsrc --keepParent --sequesterRsrc "${app_bundle}" app.zip
xcrun notarytool submit app.zip --wait --apple-id=${NOTARIZATION_EMAIL} --password="${NOTARIZATION_PASSWORD}" --team-id="$TEAM_ID"
# Staple assuming notarization was Accepted. Even if it fails, notarytool returns 0, so stapler will fail then.
xcrun stapler staple "${app_bundle}"

My problem was in the runtime flag not being included in the bundle, only the binary. That's (as far as I could tell) what would break my system's connection.

Thanks again for your help @eskimo