Microsoft Trusted Code Signing - Steps to set it up

4

Thanks @MarkGoldberg, your guide helped clear up a few things and I finally got it working. I initially could not get code signing to work when trying to use the personal Microsoft Account username/password during the browser flow, but your instruction regarding “Users” helped me find a solution, one that doesn’t actually require a second/dummy user. Read on for my slight tweaks to your very thorough guide!

A few things worth noting, during the quoted step below…

…you can alternatively click the “Organization” dropdown and opt for “Individual” here if you want an individual identity, associated only with yourself, e.g. your name, and a house address. Don’t worry, even with a “Public” identity/certificate, when setting up a “Certificate profile” later, you can conceal that address. You will then follow through identity verification like submitting a picture of your ID and a recent billing statement with your name and address on it.

Now, here’s the other slight tweak compared with your approach, which allowed me to avoid creating a second alt/dummy user. This has to do with a “mirror account” that already exists and is tied to your personal Microsoft account, and can be logged into using the “user principal name” found in Azure (which differs from your actual email/password login).

Here is the relevant section of your guide…

and here is how I would modify it…

  • Click On Microsoft Entra ID
    (you may need to click on All Services first)
    (later Entra ID is shown as Home > Default Directory)
    • Click on Manage > Users
      • Click on yourself, the only user
      • Click the “copy to clipboard” icon on the User principal name entry
      • Open an Incognito window to https://login.microsoftonline.com/ and sign in with that username, e.g. [email protected]. When prompted with a password, click “forgot” and proceed to reset your password via email to your primary email address (this is and will be a different, unique password from your Microsoft account password!)
      • Configure 2FA, again this will be a unique 2FA method independent of the one for your personal Microsoft account
      • Complete the login flow, save the username/password for logging in to sign your software later!

Then, when assigning roles to myself, the only user (as opposed to your two-user flow), I gave myself BOTH of the “Trusted Signing Identity Verifier” and “Trusted Signing Certificate Profile Signer” roles.

I would also specify some ExcludeCredentials in the JSON, modifying yours to be…

{
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "LearnTrustedSigning-Instance",
  "CertificateProfileName": "LearnTrustedSigning-Cert",
  "CorrelationId": "UNIQUE-MACHINE-NAME-IF-DESIRED-OR-EMPTY-STRING"
  "ExcludeCredentials": [
    "AzureCliCredential",
    "AzureDeveloperCliCredential",
    "AzurePowerShellCredential",
    "EnvironmentCredential",
    "ManagedIdentityCredential",
    "SharedTokenCacheCredential",
    "VisualStudioCodeCredential",
    "VisualStudioCredential",
    "WorkloadIdentityCredential"
  ]
}

Though your endpoint may vary, e.g. wus or something. Also, it’s notable that wus3 supports Azure Trusted Signing despite one of their official help articles suggesting maybe it doesn’t.

Most of those ExcludeCredentials entries speeds up the signing flow, and we omit InteractiveBrowserCredential so that we can force that one. Notice that SharedTokenCacheCredential seems to sort of magically cache your signing key, not sure for how long and how it gets invalidated, but it’s probably best to exclude that one too! That way you’re always forced through the browser flow when signing (which should be an infrequent but very security-sensitive action).

Anyways this took me all day to sort out, so I’m really glad I found your guide. It’s awesome that code signing is now available to any individual for $10/mo. but clearly there’s still a ton of very devops/IT flaming hoops to jump through, and easy to get burned.

2 Likes