Azure Code Signing for plugin developers (guide)

Windows
103

I’ve just had a session with a fellow developer and based on their feedback clarified the guide a bit more and updated to the latest state of affairs :slight_smile:

If anyone is interested in the changes: doc: Current state of affairs, more clarification based on feedback. · koaladsp/KoalaDocs@9bf5180 · GitHub

Small note to other developers: wrapping PACE binaries (as opposed to just signing for AAX plugin purposes) is also totally possible, just use wrap instead of sign. That’s also been clarified in the guide now.

3 Likes
104

Apologies for responding late, but hopefully you already managed to fix this. Quote handling in these scripts is a bit of a pain. The spaces seem to work on our systems. You might to add or perhaps even remove any and all quotes in case of the binary you’re trying to sign.

Also thanks for the suggestion on the Windows SDK version and quoting the python script, I’ve added that to the guide as well now.

105

I think the issue lies in aax-signtool.bat:

set file="%args%"

should be instead (for consistency with SIGNTOOL_PATH and easier concatenation):

set "file=%args%"

(the user should set SIGNTOOL_PATH, ACS_DLIB, ACS_JSON in a similar way too)

So the last line reads:
“%SIGNTOOL_PATH%” sign /v /debug /fd SHA256 /tr “http://timestamp.acs.microsoft.com” /td SHA256 /dlib “%ACS_DLIB%” /dmdf “%ACS_JSON%” “%file%”

PS. Waiting for the day where bash scripts will be adopted by windows…

107

Has anyone got any advice on how to solve an Insufficient privileges to complete the operation. error?

I verified that I was successfully logged in*. This is the command that provoked the error.
az ad sp create --id cf2ab426-f71a-4b61-bb8a-9e505b85bc2e
(I put my own unique id in there of course)

Here’s what I’ve done so far:

  • Created a Trusted Signing account
  • Created a User in Microsoft Entra ID
  • Assigned Role of Global Administrator to that User
  • Verified my public identity
  • Created a public Certificate Profile, which is now “active”
  • Registered an App for signing related purposes
  • Granted Microsoft Graph User.Read permissions to that App
  • Setup “Certificates and Secrets”
  • Created a Key Vault (although I don’t know if this is needed with ACS, so I’v not done anything with it yet)
  • Checked existing role assignments and identified missing roles like Owner & Contributor

I do have two Subscriptions in Azure. One initially created, and the other I created to potentially get some tech support. Maybe theres a conflict there?

Any ideas, I’m stuck on this privileges error…?

*

  {
    "cloudName": "AzureCloud",
    "homeTenantId": "<my tenant id>",
    "id": "<my id>",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "<my tenant id>",
    "user": {
      "name": "<my name id>",
      "type": "servicePrincipal"
    }
  }
108

Seems like this error is related to the ACL or permissions. Have you assigned the “Trusted Signing Identity Verifier” role already?

1 Like
109

For those disheartened by the requirement for a full 3-year history to be eligible for Azure Trusted Signing, there are options! We helped one of our merchants get up-and-running using AWS KMS instead, with an off-the-shelf certificate from GlobalSign. It’s more expensive, and not as good as the Azure options, but still a much better solution than the stone-age tools from the incumbent CAs.

I wrote a small tutorial on our blog, it’s a bit technical, but happy to help anyone looking for simpler code signing: Signing Windows binaries using AWS KMS

Should note that this approach also works with the magic wrapper script made by @koaladsp-cecill, just using your own AWS infra instead of Azure stuff. :slight_smile:

3 Likes
110

I fell foul of the 3-year history from Azure (sole proprietorship) EV Trusted Signing.
However, the Azure rep said they had plans to, quote, “loosen” the restrictions this year, and he would contact me when this would happen.

111

Yeah, they’ve been also telling me something to the effect of soon, we're working on it, but no timeline in May of last year…

I have 2 existing businesses with 3-year history that are both on Azure TS and I wouldn’t change it - and if you have that 3-year tax history or can wait for Microsoft to come through for younger businesses, I would pick Azure TS any day.

But I’m also in the process of setting up a new business - we want to go to market soon and need EV certs now. So @TobbenTM helped me setup the AWS KMS approach, after I’ve now waited for over 6 months to join AZ TS and I couldn’t be happier - I now got fully cloud based EV signatures on a business that is not even to market yet and I was able to just slightly modify everything I’ve setup for AZ TS, to make it work with the KMS approach.

So I highly recommend checking this out if you want to get your EV signatures going on the cloud while having no access to MS Azure TS.

1 Like
112

fyi here’s the exact quote from my Azure rep hopefully in early 2025 when the restrictions may loosen

113

Just got an email from Sergio, who pointed me to the --explicitsigningoptions which is available since Eden 5.10.

With that no patching or wrapper scripts are necessary. You can supply the necessary parameters directly.
In the pace online documation there is even a working example.

4 Likes
114

Great, thanks for pointing this out. This will help a lot.

115

Thanks so much for these guides, they got me up and going with azure and i’m able to wrap successfully. My initial signtool attempts(despite me thinking i had downloaded and was running the correct version) failed, giving me a silent error. (Nothing in event logs either). Approaching on a different day, downloading from Set up signing integrations to use Trusted Signing | Microsoft Learn the TrustedSigningClientTools then worked. Signtool was in Program Files(x86)\Windows Kits\10\bin\10.0.22621.0\x64 and the DLL was in %APPDATA%\Microsoft\MicrosoftTrustedSigningTools\Azure.CodeSigning.Dlib.dll. Thanks everyone! (Oh and as Daniel pointed out, no patching is needed anymore)

116

Note that as of Jan 2026, Microsoft renamed the Azure “Trusted Signing Account” to now be an “Artifact Signing Account”. This change in terminology might be confusing at first for those attempting to follow @koaladsp-cecill’s helpful guide that is linked here.

For more on this change, see this Reddit thread and also Microsoft’s own Quickstart: Set up Artifact Signing page.

2 Likes
117

Related update:

As of October 31, 2025 Microsoft has dropped the “in business for minimum of 3 years” requirement for validation:

Trusted Signing is now available to all organizations incorporated in USA, Canada, European Union and the UK. This includes organizations incorporated less than 3 years ago.

https://github.com/Azure/artifact-signing-action/issues/72#issuecomment-3475063851

Can confirm this is true at least for US entities.

2 Likes
118

Indeed. What started out as Azure Code Signing turned into Azure Trusted Signing and has now evolved into Artifact Signing. At this rate we can expect another rename next year. In any case, the tutorial has been updated!

3 Likes
119

Adding another data point on Azure artifact signing: we had CI signing working after following Sudara’s thorough guide (:folded_hands:), then after a few weeks, our account got suspended with zero explanation…

To open a support ticket we had to upgrade to their $100/month “standard support plan”. After pulling the trigger on that I spent about three weeks slowly going back and forth with their support, sending them screenshots of Azure dashboards. Eventually they came back to us with - Microsoft security says the suspension stays, no available path to reinstatement and can’t share any details about why. Infuriating experience overall.

I’ve cancelled the subscription, requested a refund for everything paid so far and am looking at other cert options.

Not sure if others have had similar experiences, but worth knowing it’s a possibility before building a release pipeline around it

2 Likes
120

not good.

Also got an email from GlobalSign which says: the CA/B Forum guidelines on code-signing certificates, the maximum validity period for code-signing certificates will be reduced from 39 months to 460 days effective March 1, 2026.

This means that you have to go through this extremely complicated process every year in order to maintain continuous certification.

121

That might “just” be a new requirement that applies to all CAs. I’ve recently got a new one for 3 years*, but due to the new limitations (whoever makes those up) require a new certificate every year. So certificate vendors typically give you a new one each year (without jumping through all the hoops again, hopefully).

* The reason I had to get a new one and migrate away from Azure once again is that they don’t approve individual businesses in Europe anymore. So now I’ve got one of those cursed dongles, which as it turns out by the way, require entering a PIN on every use (which can be fixed by using a third party signtool wrapper where you can supply the PIN via command line, which doesn’t feel exactly great).

This whole code signing business on Windows is completely cursed and broken from top to bottom.

4 Likes
122

Really? I am tired of this :face_with_bags_under_eyes:

123

I believe it is - SSL have this statement on their page:

Effective March 1, 2026, new industry requirements from the CA/Browser Forum will limit the maximum validity period of publicly trusted code signing certificates to 458 days.