Azure Artifact Signing SignTool /dlib returns “Access is denied” although REST signing succeeds

Question

Azure Artifact Signing SignTool /dlib returns “Access is denied” although REST signing succeeds

Renáta Irinyi 0

We are trying to sign a Windows installer in a Forgejo CI pipeline using Azure Artifact Signing. Authentication succeeds, the signing account and certificate profile are active, and the service principal has the Artifact Signing Certificate Profile Signer role at the signing-account scope. However, every SignTool/DLIB attempt fails with:


SignTool Error: Access is denied.

SignTool Error: An error occurred while attempting to sign:

qz-tray-greeninfo-windows-x86_64.exe

Environment:

Artifact Signing region: Switzerland North
Endpoint: https://swn.codesigning.azure.net/
Public Trust certificate profile is active
Identity validation is completed
Service principal client-credential authentication succeeds
Windows signing VM, Windows PowerShell 5.1
Microsoft.ArtifactSigning.Client 1.0.128 and 1.0.115 tested
Official ArtifactSigningClientTools MSI tested
Windows SDK SignTool 10.0.26100 and 10.0.28000 tested
System-wide .NET 8 Runtime and SDK installed
ArtifactSigning PowerShell module 0.1.20 tested

Additional diagnostics:

A direct REST signing request is accepted with HTTP 202.
The local executable is writable and can be opened exclusively for writing.
The same failure occurs with a small local test executable.
Process Monitor shows no ACCESS DENIED filesystem or registry operation.
Recreating the client secret did not change the result.
All tested SignTool/DLIB combinations return the same error.

Correlation IDs for Microsoft investigation:

forgejo-7582
qz-rest-diagnostic-20260928

Because authentication, RBAC, the endpoint, the account, and the certificate profile work, this appears to be a failure in the SignTool-to-DLIB bridge or a service-side rejection that is not surfaced in the client output.

How can we obtain the underlying Artifact Signing error, and is there a known compatibility issue or required configuration for the current SignTool and Azure.CodeSigning.Dlib.dll versions?

Jaxel Rojas Lopez 50 Reputation points Microsoft Employee

2026-09-28T18:04:57.9566667+00:00

Usually, we see this error when signtool doesn't have access to the executable, whether it is permissions or the file being marked as read-only. I would suggest you try sign the file locally to confirm that indeed it is working as intended.

1 answer

Your answer

Jaxel Rojas Lopez 50 Reputation points Microsoft Employee

2026-09-28T18:04:57.9566667+00:00

Usually, we see this error when signtool doesn't have access to the executable, whether it is permissions or the file being marked as read-only. I would suggest you try sign the file locally to confirm that indeed it is working as intended.

Answer 1

Use SignTool with /debug first. The documented way to surface more detail from SignTool is:

SignTool sign /debug [options]

For MSIX-related internal signing errors, SignTool diagnostics can also be checked in Event Viewer:

Run Eventvwr.msc
Open Event Viewer (Local) -> Applications and Services Logs -> Microsoft -> Windows -> AppxPackagingOM -> Microsoft-Windows-AppxPackaging/Operational
Review the most recent error event

For Artifact Signing specifically, the supported mitigations for opaque SignTool/DLIB failures are:

Verify the endpoint exactly matches the account region. For Switzerland North, the documented endpoint is https://swn.codesigning.azure.net. A region/endpoint mismatch commonly causes 403 Forbidden and internal SignerSign() failure.
Use the latest SignTool. The FAQ explicitly calls out SignerSign() failed. (-2147024846/0x80070032) as a case where the latest SignTool should be used.
Check the metadata.json values exactly:
- Endpoint
- CodeSigningAccountName
- CertificateProfileName
Check .NET runtime presence. Silent SignTool failures are documented when the relevant .NET runtime version is missing.
Check DLIB path, DLIB version, DLIB name, and SignTool version. The FAQ lists these as causes when SignTool is not using Artifact Signing certificates correctly.
If running outside Azure, exclude Managed Identity in the manifest/JSON configuration. Azure.Identity.CredentialUnavailableException is documented for environments outside Azure, and the guidance is to add exclude ManagedIdentity.
If authentication is affected by cached credentials or certificate caching, exclude unneeded DefaultAzureCredential sources by adding "ExcludeCredentials": ["<include list of credentials to be excluded>"] to the JSON file.

Based on the documented guidance, there is no published compatibility matrix here that identifies a known broken combination of current SignTool and Azure.CodeSigning.Dlib.dll versions, and there is no documented method here to extract a deeper Artifact Signing service error from the DLIB path beyond SignTool /debug output and the standard troubleshooting checks above.

The strongest documented checks for the described scenario are:

confirm the Switzerland North endpoint is exactly https://swn.codesigning.azure.net
confirm metadata.json account/profile names are correct
run SignTool with /debug
ensure the relevant .NET runtime is installed
ensure the latest SignTool is being used
if the pipeline host is outside Azure, exclude Managed Identity and any other unnecessary credential types

If the REST signing request succeeds with HTTP 202 while every SignTool/DLIB path still returns only Access is denied, the available documentation here does not expose a more detailed client-side error retrieval mechanism than /debug and the listed configuration checks.