Archive Fails: Conflict with Existing KEXT Developer ID Certificate

Question

Created 4d

Replies 0

Boosts 0

Participants 1

Hi everyone,

We're trying to prepare a DriverKit App for a client test, and we've run into an unavoidable signing conflict that seems to be caused by the Xcode Archive process itself.

Background & Environment:

Environment: macOS 15.6.1, Xcode 16.4
Our project consists of a main App Target and a DEXT Target.
Both the Debug and Release configurations for both targets are set to Xcode's default: Automatically manage signing.
Our developer account holds a valid, active Developer ID Application (With Kext) certificate, which we use for signing our legacy KEXT.

The Action That Triggers Failure: From this clean state, we execute Product -> Archive.

The Archive process fails during the signing validation phase and presents the following three errors, completely halting the process:

There is a problem with the request entity - You already have a current Developer ID Application Managed (With Kext) certificate...
No profiles for 'com.company.Acxxx.driver' were found...
No profiles for 'com.company.Acxxx.app' were found...

This error seems to indicate that the Xcode Archive process:

Ignores the project's Release configuration (even the default 'Auto' setting).
Attempts to automatically create a new, standard Developer ID certificate for us.
This action conflicts with the existing (With Kext) certificate in our account, causing the entire Archive process to fail.

The "Failed Experiment" to Resolve This:

To work around this automation conflict, we tried the solution: configuring a fully manual signing process for the Release configuration to explicitly tell Xcode to use our existing KEXT certificate.

Our Steps: We disabled automatic signing for both the App and DEXT targets for the Release configuration and manually assigned the Developer ID Provisioning Profiles created for our Developer ID (With Kext) certificate.
The New Problem: After doing this, the Signing Certificate field for the DEXT Target's Signing & Capabilities interface now shows None, accompanied by the misleading warning about needing a DriverKit development profile.
The Outcome: This None issue now prevents us from even starting the Archive process, as the project fails to build due to the incorrect signing configuration. We've tried every debugging step — including rebuilding profiles, validating the keychain, and clearing caches — but nothing resolves this None issue.

Our Dilemma:

State A (Fully Automatic Signing): The Archive process fails due to the KEXT certificate conflict.
State B (Manual Release Signing): The project fails to build due to the Signing Certificate: None issue, preventing us from initiating an Archive.

For a development team holding a KEXT Developer ID certificate, how should an Xcode project be configured when migrating to DriverKit, so that the Archive process:

Does not trigger the flawed automation logic that attempts to create a new certificate?
And, does not fall into the Signing Certificate: None configuration trap?

Related Forum Threads We've Studied:

Best Reagrds,

Charles

Boost