Signing applications with jpackage: Is a distribution certificate sufficient, and, if so, how do I use it?

Question

Created Jan ’24

Replies 2

Boosts 1

Views 1.1k

Participants 2

I've developed a Java application for ad hoc distribution, not intended for the Apple Store. Using the jpackage utility and the parameters...

--mac-sign
--mac-signing-keychain
--mac-signing-key-user-name

...I'm able to point the software to a signing certificate.

My problem is that jpackage requires a certificate with a "Developer ID Application" type/prefix, and I'm not authorized to create a certificate of this type, as "This operation can only be performed by the account holder."

I thought it might be sufficient to create a "Distribution" certificate, since this allows a developer to "Sign your iOS, iPadOS, macOS, tvOS, watchOS, and visionOS apps for release testing using Ad Hoc distribution or for submission to the App Store." However, there doesn't appear to be any way to get jpackage to accept anything other than a "Developer ID Application" -prefixed certificate.

I gather from this, and the fact that the Developer ID Application certificate is described as "This certificate is used to code sign your app for distribution outside of the Mac App Store," that this is the only type of "legitimate" security certificate Apple will accept when launching out-of-store apps. I'm not certain of this, however, and I'd like to be certain before pestering my client about it.

My questions are:

Is a "Developer ID Application" certificate specifically required, or can I sign the app using, e.g., a "Distribution" certificate without issues?
If a "Developer ID Application" certificate is required, is it possible for my client (the "Account Holder") to grant me access to download it and use it?
If a "Developer ID Application" certificate is required, what exactly is a "Distribution" certificate good for? Why isn't it sufficient to distribute software?
If I can sign the app using a Distribution certificate, is there a way to force jpackage to do this, or do I have to it manually using, e.g., codesign ex post facto?

Note that this issue has cropped up before on this thread, but the developer there ultimately found his developer ID certificate and the discussion was abandoned before any answers were forthcoming.

Answered by DTS Engineer in 777596022

This boils down to your deployment channel:

For App Store apps, use Apple Distribution: TTT or the older 3rd Party Mac Developer Application: TTT, where TTT identifies your team.
For direct distribution, use Developer ID Application: TTT.

For general background on this, see Creating Distribution-Signed Code for Mac.

For my advice on managing Developer ID signing identities, see The Care and Feeding of Developer ID.

And finally, your specific questions:

1. Is a "Developer ID Application" certificate specifically required … ?

For direct distribution, yes.

2. If a "Developer ID Application" certificate is required, is it possible for my client (the "Account Holder") to grant me access to download it and use it?

It’s not as simple as that, because you need both the certificate and the private key to form a code-signing identity. The Care and Feeding of Developer ID discusses this exact situation.

3. If a "Developer ID Application" certificate is required, what exactly is a "Distribution" certificate good for?

For distributing on the Mac App Store.

4. If I can sign the app using a Distribution certificate, is there a way to force jpackage to do this … ?

I can’t answer this because I don’t maintain expertise in third-party tools

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

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’24

Accepted Answer

This boils down to your deployment channel:

For App Store apps, use Apple Distribution: TTT or the older 3rd Party Mac Developer Application: TTT, where TTT identifies your team.
For direct distribution, use Developer ID Application: TTT.

For general background on this, see Creating Distribution-Signed Code for Mac.

For my advice on managing Developer ID signing identities, see The Care and Feeding of Developer ID.

And finally, your specific questions:

1. Is a "Developer ID Application" certificate specifically required … ?

For direct distribution, yes.

2. If a "Developer ID Application" certificate is required, is it possible for my client (the "Account Holder") to grant me access to download it and use it?

It’s not as simple as that, because you need both the certificate and the private key to form a code-signing identity. The Care and Feeding of Developer ID discusses this exact situation.

3. If a "Developer ID Application" certificate is required, what exactly is a "Distribution" certificate good for?

For distributing on the Mac App Store.

4. If I can sign the app using a Distribution certificate, is there a way to force jpackage to do this … ?

I can’t answer this because I don’t maintain expertise in third-party tools

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

1

Answer 2

EricKopp OP

Jan ’24

Thanks for the information, @eskimo. One follow-up question:

Based on the information in your Care & Feeding (C&F) post and CSRs Explained post, I gather that the following process is tenable:

Client creates a signing ID on his Mac.
Client exports the signing ID (i.e., certificate + private key) to a .p12 files using the steps described in "Back Up Your Signing Identities" section of C&F.
Client distributes, via secure means, the .p12 file to developers authorized to sign on behalf of organization.
Authorized developer X (myself) imports signing ID from the .p12 file using the steps described in "Back Up Your Signing Identities" section of C&F.
Authorized developer X now has all components necessary to sign code on behalf of organization on X's Mac.
Once everything is confirmed working, client should delete signing identity from his Mac, retaining only the .p12 file.

Is this correct?

(If this is correct, you might consider amending "Back Up Your Signing Identities" in C&F to "Back Up/Export Your Signing Identities" and adding a paragraph that states, e.g., "The .p12 file created by this process can be given to authorized team members who can then import it and use it to sign applications on behalf of your organization.")

Thanks again for the help.

0