signtool + Azure.CodeSigning.Dlib returns "Access is denied" — REST sign API returns HTTP 202 with same user token

Question

Summary

signtool.exe sign /dlib Azure.CodeSigning.Dlib.dll consistently fails with SignTool Error: Access is denied. (exit 1). However, calling the same Sign endpoint directly via REST with the same user's az account get-access-token succeeds with HTTP 202 and a valid Sign-job operationId.

Tested 9 different signtool/dlib configurations over 2 days — all fail identically. RBAC, Cert Profile, Identity Validation, Defender, ACL, .NET 8 Runtime are all verified correct.

Account / Resource details

Subscription: c730db78-5d31-46be-9869-00e91c1703ba (Pay-as-you-go, Basic Support Plan)
Tenant: 0d92d460-b99d-4264-a83e-58667a6fe7da
Resource: synthrilla-signing (Artifact Signing Account, West Europe, SKU Basic)
Cert Profile: synthrilla-public (Public Trust, Status Active, 76 cert versions, fresh 3-day cert issued daily)
Identity Validation: valid until 2028
Endpoint: https://weu.codesigning.azure.net

What works

Direct REST POST to the Sign endpoint with a user-acquired token returns HTTP 202 Accepted:

$token = (az account get-access-token --resource "https://codesigning.azure.net" --output json | ConvertFrom-Json).accessToken
$body = @{ signatureAlgorithm = "RS256"; digest = "" } | ConvertTo-Json
Invoke-WebRequest -Uri "https://weu.codesigning.azure.net/codeSigningAccounts/synthrilla-signing/certificateProfiles/synthrilla-public:Sign?api-version=2023-06-15-preview" -Method Post -Headers @{ "Authorization" = "Bearer $token"; "Content-Type" = "application/json" } -Body $body

Response:

HTTP/1.1 202 Accepted
api-supported-versions: 2023-06-15-preview, 2024-06-15
{"id":"eee6d7fa-...","status":"InProgress","result":{...},"errorResponse":null}

Reproduced multiple times with different mise-correlation-ids — backend, auth, RBAC, certificate profile all confirmed working.

What does not work

signtool.exe sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /d "MyApp" /du "https://example.com" /dlib "\Azure.CodeSigning.Dlib.dll" /dmdf "\metadata.json" MyApp.exe

Output (with /debug):

SignTool Error: Access is denied.
SignTool Error: An error occurred while attempting to sign: MyApp.exe

Exit code 1. No additional log lines beyond "Access is denied" — even with /debug and AZURE_LOG_LEVEL=Verbose set in environment.

Configurations tested — all fail identically

#AuthdlibEndpointResult1SPN (EnvironmentCredential)Microsoft.Trusted.Signing.Client (June 2025)with trailing /denied2SPNas aboveno trailing /denied3SPNMicrosoft.ArtifactSigning.Client 1.0.128no /denied4User (AzureCliCredential, ExcludeCredentials)new dlibno /denied5User, SPN env vars removednew dlibno /denied6User, env vars strippedold dlibno /denied7User + AZURE_LOG_LEVEL=Verbosenew dlibno /denied — no log lines emitted8User, CWD set to dlib bin foldernew dlibno /denied9User, system-installed dlib via WinGet Microsoft.Azure.ArtifactSigningClientTools (Jan 2026)no /denied## Environment

Windows VM, Windows 11
Windows SDK SignTool: 10.0.26100.0\x64\signtool.exe (matches doc requirement, > 10.0.2261.755)
.NET runtimes installed: Microsoft.NETCore.App 8.0.23 and 10.0.2
dlib package: Microsoft.ArtifactSigning.Client 1.0.128 (latest from NuGet) and the system-installed one via the official MSI bundle
signtool sign /v /a (without /dlib) works correctly — informative "/fd missing" message — proving signtool itself runs OK
File ACL allows Authenticated Users: Modify; [IO.File]::OpenWrite() succeeds; file deletable; Defender real-time scan does not lock

Verified clean (per Microsoft's standard "Access is denied" troubleshooting)

IAM Role Assignments: SPN and user both have Artifact Signing Certificate Profile Signer and Artifact Signing Identity Verifier directly on the account, no conditions.
Deny Assignments: empty.
PIM: tenant has no Entra ID P2, no eligible/active assignments — roles are permanent.
Re-authentication: az logout, az account clear, fresh az login --use-device-code. JWT decoded — aud=https://codesigning.azure.net, tid and oid match expected values.
No resource changes in last 24h (per portal "Recent activity").

What is suspicious

AZURE_LOG_LEVEL=Verbose produces no log output at all when invoked through signtool/dlib. This suggests the dlib never reaches its internal credential resolution — the Access is denied is thrown before any Azure.Identity code runs.
The error is identical across completely different dlib binaries (Trusted.Signing.Client, ArtifactSigning.Client 1.0.128, system-installed via official MSI bundle) — this is a host/loader problem, not a binary one.
signtool itself works (no dlib involved); REST API works (with user token, HTTP 202). The breakage is specifically in the signtool→dlib bridge.

Question

Given that every standard "Access is denied" troubleshooting has been exhausted and the REST API confirms the entire backend chain works with the same user token, what else can cause signtool /dlib to fail before the dlib's credential resolution runs? Is there a known dependency, registry key, or security-policy requirement (e.g. admin rights for CSP loading, AppLocker, WDAC, MSI install state) that would cause the dlib to refuse loading silently with a generic "Access is denied"?

Any pointer to enable verbose loader diagnostics for the signtool→dlib boundary would also be very helpful — /debug and AZURE_LOG_LEVEL=Verbose produce no actionable output here.

Answer

The provided context only documents how to configure and invoke SignTool with Azure Artifact Signing and how to troubleshoot generic SignTool errors. It does not list any additional dependencies, registry keys, security policies, or known issues that would explain an Access is denied error occurring before the dlib’s credential resolution runs, nor does it describe loader‑level diagnostics for the SignTool→dlib boundary.

The only supported guidance from the context for using SignTool with Artifact Signing is:

Ensure the correct Windows SDK version is installed and that the SignTool architecture (x86/x64) matches the Azure.CodeSigning.Dlib.dll architecture.
Use the documented SignTool command line, including /fd and /td for SHA256, /dlib pointing to the dlib, and /dmdf pointing to a valid metadata.json that contains the correct Endpoint, CodeSigningAccountName, and CertificateProfileName for the Artifact Signing account.
Use the recommended timestamping authority http://timestamp.acs.microsoft.com/ so that signatures remain valid beyond the three‑day certificate validity.
Use /debug immediately after sign to enable SignTool’s own debug output.

From the context, there are no additional documented causes or configuration requirements (such as specific registry keys, WDAC/AppLocker policies, or admin‑rights requirements) that would explain a generic Access is denied at the point where SignTool loads the dlib, and no additional logging switches beyond /debug are documented.

References:

Share via