Developer ID Application certificate creation

Hello,

We are currently in the process of creating our Developer ID Application certificate which is due to expire. While creating the certificate, we were posed with the option of choosing a Developer ID Certificate Intermediary

  1. G2 Sub CA which is supported by Xcode 11.4.1 and later
  2. Previous Sub CA

We currently build our application out of Xcode using Make or CMake files and perform the codesign and productsign using the codesign commands.

We also use 2 different build machines,

  1. Ventura with Xcode 14.3 for our latest releases
  2. High Sierra (10.13) with Xcode 10.1 for legacy releases to support some customers.

Can you please let us know which Developer ID Certificate Intermediary we should choose for generating the new Developer ID Application certificate?

Answered by DTS Engineer in 887830022
we were posed with the option of choosing a Developer ID Certificate Intermediary

Oh, that’s a new one.

Can you please let us know which Developer ID Certificate Intermediary we should choose … ?

I don’t think there’s a one-size-fits-all answer to that, which is why we give you the choice. My general advice is that you pick the new one, but the old one might make sense if:

  • You have infrastructure that relies on ancient versions of Xcode (or the Command Line Tools package).
  • Or infrastructure that’s tied to a specific intermediate.

Picking the new one may require you to install the new intermediate on your build infrastructure, but that’s not a particularly onerous task.

From a deployment perspective, this choice shouldn’t matter. When codesign signs code, it builds a chain of trust and embeds that full chain into the code signature. So when a Mac goes to verify the signature, it automatically has access to all the necessary intermediates. See TN3161 Inside Code Signing: Certificates for more about this.

ps I just want to reiterate that Developer ID signing identities are precious and you should manage them carefully. I have a bunch of advice on this in The Care and Feeding of Developer ID.

Share and Enjoy

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

Accepted Answer
we were posed with the option of choosing a Developer ID Certificate Intermediary

Oh, that’s a new one.

Can you please let us know which Developer ID Certificate Intermediary we should choose … ?

I don’t think there’s a one-size-fits-all answer to that, which is why we give you the choice. My general advice is that you pick the new one, but the old one might make sense if:

  • You have infrastructure that relies on ancient versions of Xcode (or the Command Line Tools package).
  • Or infrastructure that’s tied to a specific intermediate.

Picking the new one may require you to install the new intermediate on your build infrastructure, but that’s not a particularly onerous task.

From a deployment perspective, this choice shouldn’t matter. When codesign signs code, it builds a chain of trust and embeds that full chain into the code signature. So when a Mac goes to verify the signature, it automatically has access to all the necessary intermediates. See TN3161 Inside Code Signing: Certificates for more about this.

ps I just want to reiterate that Developer ID signing identities are precious and you should manage them carefully. I have a bunch of advice on this in The Care and Feeding of Developer ID.

Share and Enjoy

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

Developer ID Application certificate creation
 
 
Q