Error using VPN profile from app extension in system extension

Question

buman56 OP

Created Oct ’24

Replies 2

Boosts 0

Participants 2

Hi,

We are currently working on porting our PacketTunnelProvider app extension to run as a system extension. Things are mostly working great, but we're now testing upgrades from the existing app extension to a system extension.

We have an existing configuration that gets created and runs perfectly fine with the app extension. Then, when we go and upgrade to the system extension, and attempt to connect using the same existing configuration.

We see this error in the nesessionmanager logs:

10:00:57.717694-0700 nesessionmanager Signature check failed: code failed to satisfy specified code requirement(s) error 
10:00:57.717914-0700 nesessionmanager Rejecting agent com.agentBundleID.bundleID because it does not satisfy the code signature requirements error 
10:00:57.717937-0700 nesessionmanager Failed to launch com.agentBundleID.bundleID

If we create a new configuration profile in our upgraded app w/system extension it works fine. The problem only occurs with existing profiles.

Our app doesn't even get any notification about this error, startVPNTunnelWithOptions:andReturnError: doesn't return any error that we can work with.

My gut tells me this has to do with the ProviderDesignatedRequirement not being correct, but I really have no way to confirm this at all. The NETunnelProviderProtocol has no way to specify that in its API. Our providerBundleIdentifier was unchanged between the two extensions.

Is there anything that we can do here? Or are we stuck re-creating the configuration profile after an upgrade?

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’24

Is there anything that we can do here?

I very much doubt it. macOS uses the designated requirement to track the identity of your code. See TN3127 Inside Code Signing: Requirements for more background on that. If the identity has changed, the configuration won’t work.

Did the DR actually change? What does it look like if you dump the DR of your old appex and the DR of your new sysex?

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

0

Answer 2

buman56 OP

Oct ’24

Did the DR actually change? What does it look like if you dump the DR of your old appex and the DR of your new sysex?

I believe this clued me in on the reason. The issue is that when we create a configuration profile in our app, it takes the designated requirement of that app. We would then install a TestFlight build, and that would have a different designated requirement. Since it's signed by the TestFlight signing cert vs the App Store signing cert.

I was able to verify that a configuration profile created in a TestFlight app extension build would work on a TestFlight system extension build, since their DRs would be the same for both.

But a profile created on an AppStore build would not work on a TestFlight build. I obviously can't verify from AppStore -> AppStore easily. But I believe that the fact that this works TestFlight -> TestFlight proves the hypothesis.

1