Title: Developer ID + DNS Proxy system extension: profile mismatch for `com.apple.developer.networking.networkextension`

Question

Created 2w

Replies 4

Boosts 0

Participants 2

I’m building a macOS app with a DNS Proxy system extension for Developer ID + notarization, deployed via MDM, and Xcode fails the Developer ID Release build with a provisioning profile mismatch for com.apple.developer.networking.networkextension.

Environment

macOS: Sequoia (15.7.2)
Xcode: 26.2
Distribution: Developer ID + notarization, deployed via MDM
Host bundle ID: com.mydns.agent.MyDNSMacProxy

DNS Proxy system extension bundle ID: com.mydns.agent.MyDNSMacProxy.dnsProxy

Host entitlements (Release):

File: MyDNSMacProxy/MyDNSMacProxyRelease.entitlements:

 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.application-identifier</key>
    <string>B234657989.com.mydns.agent.MyDNSMacProxy</string>
<key>com.apple.developer.networking.networkextension</key>
    <array>
        <string>dns-proxy</string>
    </array>
    <key>com.apple.developer.system-extension.install</key>
    <true/>
    <key>com.apple.developer.team-identifier</key>
    <string>B234657989</string>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>group.com.mydns.MyDNSmac</string>
    </array>
    <key>keychain-access-groups</key>
    <array>
        <string>B234657989.*</string>
    </array>
</dict>
</plist>

xcodebuild -showBuildSettings -scheme MyDNSMacProxy -configuration Release :

PROVISIONING_PROFILE_SPECIFIER = main MyDNSMacProxy5
CODE_SIGN_IDENTITY = Developer ID Application

Host Developer ID profile main_MyDNSMacProxy5.provisionprofile (via security cms -D):

"Entitlements" => {
  "com.apple.application-identifier" => "B234657989.com.mydns.agent.MyDNSMacProxy"
  "com.apple.developer.team-identifier" => "B234657989"
  "com.apple.security.application-groups" => [ "group.com.mydns.MyDNSmac", ..., "B234657989.*" ]
  "keychain-access-groups" => [ "B234657989.*" ]
  "com.apple.developer.system-extension.install" => 1
  "com.apple.developer.networking.networkextension" => [
    "packet-tunnel-provider-systemextension",
    "app-proxy-provider-systemextension",
    "content-filter-provider-systemextension",
    "dns-proxy-systemextension",
    "dns-settings",
    "relay",
    "url-filter-provider",
    "hotspot-provider"
  ]
}

So:

App ID, team ID, keychain and system‑extension.install match.
The profile’s com.apple.developer.networking.networkextension is a superset of what I request in the host entitlements (dns-proxy only).

System extension (for context) DNS Proxy system extension target:

NSExtensionPointIdentifier = com.apple.dns-proxy
NetworkExtension → NEProviderClasses → com.apple.networkextension.dns-proxy → my provider class
Entitlements: com.apple.developer.networking.networkextension = ["dns-proxy-systemextension"]

This target uses a separate Developer ID profile and builds successfully.

Xcode error Release build of the host fails with:

…MyDNSMacProxy.xcodeproj: error: Provisioning profile "main MyDNSMacProxy5" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. (in target 'MyDNSMacProxy' from project 'MyDNSMacProxy')

Xcode UI also says:

Entitlements: 6 Included, 1 Missing Includes com.apple.developer.team-identifier, com.apple.application-identifier, keychain-access-groups, com.apple.developer.system-extension.install, and com.apple.security.application-groups. Doesn’t match entitlements file value for com.apple.developer.networking.networkextension.

Because of this, the app bundle isn’t produced and I can’t inspect the final signed entitlements.

Questions:

For com.apple.developer.networking.networkextension, should Xcode accept a subset of values in the entitlements (here just dns-proxy) as long as that value is allowed by the Developer ID profile, or does it currently require a stricter match?
Is the following configuration valid for Developer ID + MDM with a DNS Proxy system extension:

Host entitlements: ["dns-proxy"]
System extension entitlements: ["dns-proxy-systemextension"]
Host profile’s NE array includes the DNS Proxy system extension types.

If this is a known limitation or bug in how Xcode validates NE entitlements for Developer ID, is there a recommended workaround?

Thanks for any guidance.

Answered by DTS Engineer in 875905022

If this is a known limitation or bug in how Xcode validates NE entitlements for Developer ID

Indeed, this is a known bug in Xcode’s code-signing support )-:

is there a recommended workaround?

You have to sign your product manually, outside of Xcode.

Exporting a Developer ID Network Extension has all the details here.

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

Boost

Answer 1

DTS Engineer OP

Apple

2w

Recommended

If this is a known limitation or bug in how Xcode validates NE entitlements for Developer ID

Indeed, this is a known bug in Xcode’s code-signing support )-:

is there a recommended workaround?

You have to sign your product manually, outside of Xcode.

Exporting a Developer ID Network Extension has all the details here.

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

0

Answer 2

Leo_Nagano OP

2d

As a follow‑up for anyone hitting the same issue:

Per Quinn’s advice, I switched to manual signing outside Xcode and followed the “Exporting a Developer ID Network Extension” guidance. The code signing / notarization side now looks correct and works locally:

Host app and DNS Proxy system extension are both signed with Developer ID Application for our team (for example, TEAMID1234).
com.apple.developer.networking.networkextension in both host and system extension entitlements uses `dns-proxy-systemextension.
The app bundle identifier is com.myapp.agent.MyProxy.
The installer pkg is signed with Developer ID Installer: MyApp Inc (TEAMID1234), notarized with notarytool (status: Accepted), stapled, and passes `pkgutil --check-signature.
On the test Mac (macOS 14.4, Apple Silicon), sudo installer -pkg MyProxy_…pkg -target / succeeds, the app appears in/Applications, and spctl --assess -vvv -t exec reportssource=Notarized Developer ID`. The app launches and the DNS Proxy system extension runs (any remaining issues are now inside our Network Extension code, not related to installation).

The remaining problem is MDM deployment (third‑party MDM):

The notarized pkg is uploaded as a Custom macOS app (Delivery shows “MDM, Munki”).
In the relevant group, the Install Method for this app is set to MDM; the device is not in any Munki assignment group and has no Munki client installed.
Other macOS apps from the same group generate InstallApplication commands and install successfully on this device.
This particular app (bundle id com.myapp.agent.MyProxy) never gets an InstallApplication / InstallEnterpriseApplication command for this Mac, despite the assignment being present. From the vendor’s description it appears to be evaluated as “NotApplicable” on their backend
A System Extension Policy profile is present on the device, allowing our Team ID (e.g. TEAMID1234) and system extension bundle ID com.myapp.agent.MyProxy.dnsProxy for the Network extension type.
Device‑level installation has been tested both enabled and disabled in the app settings; manual installation via installer works in both cases.

So we effectively have:

A Developer ID–signed, notarized pkg that installs and runs correctly when executed manually on the same Mac.
A healthy MDM‑managed device that successfully installs other apps via InstallApplication.
Only this one Developer ID DNS Proxy app being treated as “not applicable” for MDM installation.

My questions for DTS / anyone familiar with the MDM side of Developer ID Network Extensions:

Are there any additional constraints (beyond code signing and notarization) that could cause an MDM server to treat a notarized Developer ID pkg containing a dns-proxy-systemextension as NotApplicable on macOS 14.x Apple Silicon, even when the same pkg installs and runs correctly via installer?
Are there any recommended pkg‑level metadata or structure requirements (minimum OS version, architecture filters, specific Info.plist keys, etc.) that MDM implementations are expected to enforce for Developer ID Network Extensions when deciding whether to send InstallApplication?
Is there any Apple guidance or known limitation around using `InstallApplication with Developer ID DNS Proxy system extensions on macOS 14.x that MDM vendors should be following?

Any pointers on how to verify that a given Developer ID DNS Proxy pkg is “MDM‑deployable” (beyond notarization and spctl) would be greatly appreciated.

0

Answer 3

Leo_Nagano OP

1d

Update (MDM‑managed macOS 14.4 device):

After some additional testing with our third‑party MDM, the Custom macOS app now does get installed via MDM (the notarized Developer ID PKG is assigned to a group with Install Method = MDM and Auto Deploy, and /Applications/MyProxy.app appears on the target Mac with the expected bundle id and version). However, on that MDM‑managed macOS 14.4 (Apple Silicon) device the app still cannot be launched. Finder shows a generic “MyProxy can’t be opened” error, and the process is killed immediately on launch.

The key detail from the system log is that the decision is coming from the ConfigurationProfiles / MDM side rather than from Gatekeeper:

taskgated-helper[…]: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles]
Disallowing com.myapp.agent.MyProxy because no eligible provisioning profiles found

At the same time:

spctl --assess -vvv -t exec /Applications/MyProxy.app reports source=Notarized Developer ID.
codesign -dvv confirms the app is signed with our Developer ID Application certificate and has com.apple.developer.networking.networkextension = dns-proxy-systemextension, com.apple.developer.system-extension.install, sandbox, and app group entitlements only.
The PKG is signed with Developer ID Installer, notarized with notarytool (status: Accepted), and passes pkgutil --check-signature.

So on a non‑MDM machine the same notarized Developer ID PKG installs and the app launches and runs its DNS Proxy system extension successfully. On an MDM‑managed machine, the app installs via MDM but taskgated-helper (ConfigurationProfiles) blocks the launch with “no eligible provisioning profiles found”, as if a provisioning profile were required for these entitlements even though this is a Developer ID distribution. This leads to a follow‑up question for DTS:

Is this behavior (ConfigurationProfiles / taskgated-helper requiring an “eligible provisioning profile” for a Developer ID app that has dns-proxy-systemextension entitlements and was delivered via MDM as a Custom macOS app) expected, or is it a bug in how macOS 14.x applies MDM/ConfigurationProfiles policy to Developer ID Network Extensions?

If this is expected, any clarification on the intended model for deploying Developer ID DNS Proxy system extensions via MDM (in particular, whether MDM delivery is supposed to place additional provisioning‑profile‑like requirements on such apps) would be very helpful.

0

Answer 4

DTS Engineer OP

Apple

1d

I can’t really help you with MDM stuff. If you need help in that space, you can try over in Business & Education > Device Management but you might have more luck over in the Apple Support Community, run by Apple Support, and specifically in the Business and Education topic areas.

However, I can help you with this:

on that MDM‑managed macOS 14.4 (Apple Silicon) device the app still cannot be launched.

That sounds less like an MDM issue and more like a Gatekeeper issue.

codesign -dvv confirms the app is signed with our Developer ID Application certificate and has …

I see no mention of the App ID (com.apple.application-identifier) and Team ID (com.apple.developer.team-identifier) entitlements. Any app that uses restricted entitlement should be signed with those entitlements because they tie the app to its provisioning profile. I talk about this, in a very different context, in TestFlight, Provisioning Profiles, and the Mac App Store.

Oh, and in your case this applies to both the app and the appex, which need separate App ID and thus separate profiles.

If that’s not the issue then I recommend that you work through the process in Resolving Trusted Execution Problems to see if that turns up anything.

Oh, and it’d also be good to install macOS 14 in a ‘victim’ VM and install your app there without involving MDM, just in confirm that MDM isn’t a factor.

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

1