Microsoft Trusted Code Signing - Steps to set it up

42

Ok, I’m confused. Isn’t Microsoft’s Trusted Code Signing supposed to remove the need for a regular code signing certificate?

43

Hi Jeff,

thank you for your order!

It’s an automated process in SetupBuilder 2025. You don’t need Marks instructions, because our “SignInstall (x86/x64) for SetupBuilder” tool downloads and installs the required runtimes (for Trusted Signing). For eTokens (with and without SafeNet support), we have developed the “eToken Config” tool (written in SetupBuilder 2025) to configure all settings.

We are busy preparing the BETA invitations and updating our servers…

Friedrich

44

Yes and no . At the moment the service is limited to new customer subscriptions from organizations based in the US and Canada with at least three years of verifiable (tax) history. Organizations from other countries are currently unable to submit new validation requests. New individual developer onboarding has been paused worldwide (including US and Canada).

Trusted Signing is a game changer (IMO). I really hope they’ll continue the service for new subscribers soon.

OV and especially EV certificates will continue to exist and remain available for purchase from major CAs (the Cartel).

Friedrich

45

For clarity you’ll still need my instructions to work with Azure to get the code signing service setup.

That said my directions for using the trusted signing service with setup builder will be quite different in setup builder 2025 than prior versions

46

Yes, sorry . I meant you do not need the instruction to setup the Trusted Signing system in SetupBuilder :grinning_face:. It’s fully automated now. Download the SignInstall tool from within the SetupBuilder 2025 IDE and this will configure everything (on x86 and x64 machines). Point.Click.Sign

It’s a hell of a job to work with Azure to get the code-signing service setup. Of course, the step-by-step instructions from Mark are worth their weight in gold!!!

Sorry for my miscommunication!

Friedrich

47

I had the Microsoft Trusted Signing working well. I logged on with the credentials the first time, then it automatically used those with subsequent signings.

Then I had to implement signing for a second entity, which meant it could no longer use the single set of stored credentials. Instead, every time I signed something, it prompted me for the applicable user, preventing me from automating things.

After futzing for a while, I finally determined how to resolve it, using a combination of adjustments to the metadata.json and the signing script. My json looks like this:

{
  "Endpoint": "https://wcus.codesigning.azure.net/",
  "CodeSigningAccountName": "BoxSoftCodeSigningInst",
  "CertificateProfileName": "BoxSoftCodeSigningCert",
  "CorrelationId": "",
  "ExcludeCredentials": [
    "WorkloadIdentityCredential",
    "ManagedIdentityCredential",
    "VisualStudioCredential",
    "VisualStudioCodeCredential",
    "AzureCliCredential",
    "AzurePowerShellCredential",
    "AzureDeveloperCliCredential"
  ],
  "_NotExcludedAbove_": [
    "EnvironmentCredential",
    "SharedTokenCacheCredential",
    "InteractiveBrowserCredential"
  ] 
}

Of course, for the other signing entity, I have another metadata.json with different Account and Profile entries, but the rest is the same.

Then in the top of CallCodeSign.cmd, I set two additional environment variables. Again, these are different for the other signing entity.

Set AZURE_TENANT_ID=d56f00a3-your-id-here-fb023a4e9e82
Set [email protected]

Hopefully, this saves you some time with this rather quirky service. :slight_smile:

2 Likes