Forum Discussion
Azure Artifact Signing: SignTool "Access is denied" with active Public Trust profile
I’m blocked on Azure Artifact Signing for Windows EXE signing.
What is already confirmed:
- Account endpoint: https://wus2.codesigning.azure.net/
- Code signing account: notarios
- Certificate profile: notarios-public-trust (Public Trust, Active)
- Identity validation: Completed
- User object id: 9aa27294-c04d-4aab-a7b2-3a8b10be96f9
- RBAC includes:
- Artifact Signing Identity Verifier
- Artifact Signing Certificate Profile Signer
(also assigned at certificate profile scope)
Signing command (signtool 10.0.26100.0 x64 + dlib):
... sign /v /debug /fd SHA256 /tr http://timestamp.acs.microsoft.com /td SHA256 /dlib "<...>\\Azure.CodeSigning.Dlib.dll" /dmdf "C:\temp\metadata-corr.json" "C:\temp\notarial-app-test.exe"
Error every time:
- SignTool Error: Access is denied.
- Number of files successfully Signed: 0
I also tested Azure CLI auth and explicit AccessToken in metadata; same result.
CorrelationId for troubleshooting:
- notarios-20260425-1859
If anyone from Microsoft can check backend logs for that CorrelationId, I’d appreciate the exact reason and remediation.
5 Replies
For this specific SignTool + Artifact Signing path, I would treat Access is denied as either a local dlib/tooling load issue or a service-side authorization/profile mismatch.
The checks I would make first are:
1. Confirm the SignTool architecture matches the Azure.CodeSigning.Dlib.dll architecture.
2. Confirm .NET 8 runtime, the Windows SDK/SignTool version, and the Artifact Signing dlib package are all installed on the same signing machine.
3. Re-check metadata.json for Endpoint, CodeSigningAccountName, and CertificateProfileName. A tiny mismatch here can look like an auth issue.
4. Assign Artifact Signing Certificate Profile Signer at the certificate profile scope to the exact identity used by SignTool, then wait for RBAC propagation.
5. Test from a clean machine or clean profile to rule out WDAC/AppLocker/AV blocking the dlib load.
The Artifact Signing FAQ has a good checklist: https://learn.microsoft.com/azure/artifact-signing/faq
Quick update (May 10, 2026): the issue is still reproducible with no change in behavior.
I re-ran the signing flow on our Windows VM using the same Trusted Signing configuration:
- Endpoint: https://wus2.codesigning.azure.net/
- Account: notarios
- Certificate profile: notarios-public-trust
- SignTool: 10.0.26100.0 (x64)
- Dlib: Azure.CodeSigning.Dlib.dll (Microsoft Trusted Signing Client Tools)
Result remains:
- Number of files successfully Signed: 0
- SignTool Error: Access is denied.
- Exit code: 1
This happens for both:
- notarial-app.exe
- NotaRios-Setup.exe
Latest local diagnostic log timestamp:
- May 3, 2026, 9:03 AM (same failure pattern)
Could Microsoft please review backend logs for this scenario and advise the exact service-side authorization/policy condition causing “Access is denied” for this account/profile?
Quick update (May 10, 2026): the issue is still reproducible with no change in behavior.
I re-ran the signing flow on our Windows VM using the same Trusted Signing configuration:
- Endpoint: https://wus2.codesigning.azure.net/
- Account: notarios
- Certificate profile: notarios-public-trust
- SignTool: 10.0.26100.0 (x64)
- Dlib: Azure.CodeSigning.Dlib.dll (Microsoft Trusted Signing Client Tools)
Result remains:
- Number of files successfully Signed: 0
- SignTool Error: Access is denied.
- Exit code: 1
This happens for both:
- notarial-app.exe
- NotaRios-Setup.exe
Latest local diagnostic log timestamp:
- May 3, 2026, 9:03 AM (same failure pattern)
Could Microsoft please review backend logs for this scenario and advise the exact service-side authorization/policy condition causing “Access is denied” for this account/profile?
Worth to take a look at this in the meantime:
https://learn.microsoft.com/en-us/azure/artifact-signing/how-to-signing-integrations
Thanks. We have already followed that integration guide step-by-step (supported SignTool version, .NET runtime, Trusted Signing dlib, correct endpoint/account/profile metadata, and RBAC for the signing identity). The issue still reproduces with the same result:
SignTool Error: Access is denied.
Could Microsoft please check backend logs for our case and confirm the exact service-side authorization/policy reason?
