Azure Artifact Signing Public Trust returns HTTP 403 Forbidden when submitting digest

Question

Azure Artifact Signing Public Trust returns HTTP 403 Forbidden when submitting digest

Sandra Wolff 0

(Yes, I work with an AI, and I just asked it to concisely put all this together. I just want to be able to sign my own apps that I develop in Visual Studio, as a way of claiming my work.)


I am unable to sign a Windows EXE using Azure Artifact Signing Public Trust. The signing client successfully reaches the Artifact Signing service and begins submitting the digest, but the service returns HTTP 403 Forbidden.

**Configuration**

- Artifact Signing account: `SandraWolffCodeSigning`

- Certificate profile: `SandraWolffPublicSigning`

- Profile type: Public Trust

- Region: West US

- Endpoint: `https://wus.codesigning.azure.net`

- Certificate profile status: Active

- Identity validation: Completed

- `Microsoft.CodeSigning` resource provider: Registered

**RBAC**

The Azure identity performing the signing has:

- `Artifact Signing Certificate Profile Signer`

- `Artifact Signing Identity Verifier`

Both role assignments are on the `SandraWolffCodeSigning` Artifact Signing account scope. I verified through Azure CLI that the authenticated Azure user is the same identity to which these roles are assigned.

**Signing methods tested**

I initially tested with Microsoft's Artifact Signing Dlib and Windows SDK SignTool. I then reproduced the problem using the Microsoft `ArtifactSigning` PowerShell module version `0.1.20` and `Invoke-ArtifactSigning`.

The PowerShell module successfully loads, finds the EXE, invokes the Artifact Signing client, and reaches the Artifact Signing service. The failure occurs specifically at:

`Submitting digest for signing...`

The resulting exception is:

`Azure.RequestFailedException: Service request failed.` `Status: 403 (Forbidden)`

followed by:

`SignerSign() failed. (-2147467259/0x80004005)`

The failed request occurred at approximately **2026-09-18 02:01:59 UTC**.

**Troubleshooting already completed**

I have verified:

- Correct Artifact Signing account and certificate profile names

- Correct West US Artifact Signing endpoint

- Public Trust certificate profile is Active

- Identity validation is Completed

- `Microsoft.CodeSigning` is Registered

- `Artifact Signing Certificate Profile Signer` is assigned to the authenticated signing identity at the Artifact Signing account scope

- Current Windows SDK SignTool installed

- Current Artifact Signing client/Dlib installed

- .NET 8 runtime installed

- Required Visual C++ x64 runtime installed

- Azure CLI authentication and subscription selection verified

- The failure is reproducible through Microsoft's `Invoke-ArtifactSigning` PowerShell integration

Since the client reaches the Artifact Signing service and the service itself returns HTTP 403 despite the above configuration, this appears potentially to be a service-side authorization/provisioning issue.

My Azure subscription does not include paid technical support. Could a Microsoft Artifact Signing engineer or moderator please advise why the signing service is returning 403 or provide an appropriate escalation path? If server-side logs can be checked, the failed request timestamp above may help identify the request.I am unable to sign a Windows EXE using Azure Artifact Signing Public Trust. The signing client successfully reaches the Artifact Signing service and begins submitting the digest, but the service returns HTTP 403 Forbidden.

**Configuration**

-  Artifact Signing account: `SandraWolffCodeSigning` 

-  Certificate profile: `SandraWolffPublicSigning` 

-  Profile type: Public Trust 

-  Region: West US 

-  Endpoint: `https://wus.codesigning.azure.net` 

-  Certificate profile status: Active 

-  Identity validation: Completed 

- `Microsoft.CodeSigning` resource provider: Registered 

**RBAC**

The Azure identity performing the signing has:

- `Artifact Signing Certificate Profile Signer` 

- `Artifact Signing Identity Verifier` 

Both role assignments are on the `SandraWolffCodeSigning` Artifact Signing account scope. I verified through Azure CLI that the authenticated Azure user is the same identity to which these roles are assigned.

**Signing methods tested**

I initially tested with Microsoft's Artifact Signing Dlib and Windows SDK SignTool. I then reproduced the problem using the Microsoft `ArtifactSigning` PowerShell module version `0.1.20` and `Invoke-ArtifactSigning`.

The PowerShell module successfully loads, finds the EXE, invokes the Artifact Signing client, and reaches the Artifact Signing service. The failure occurs specifically at:

`Submitting digest for signing...`

The resulting exception is:

`Azure.RequestFailedException: Service request failed.`  
 `Status: 403 (Forbidden)`

followed by:

`SignerSign() failed. (-2147467259/0x80004005)`

The failed request occurred at approximately **2026-09-18 02:01:59 UTC**.

**Troubleshooting already completed**

I have verified:

-  Correct Artifact Signing account and certificate profile names 

-  Correct West US Artifact Signing endpoint 

-  Public Trust certificate profile is Active 

-  Identity validation is Completed 

- `Microsoft.CodeSigning` is Registered 

- `Artifact Signing Certificate Profile Signer` is assigned to the authenticated signing identity at the Artifact Signing account scope 

-  Current Windows SDK SignTool installed 

-  Current Artifact Signing client/Dlib installed 

-  .NET 8 runtime installed 

-  Required Visual C++ x64 runtime installed 

-  Azure CLI authentication and subscription selection verified 

-  The failure is reproducible through Microsoft's `Invoke-ArtifactSigning` PowerShell integration 

Since the client reaches the Artifact Signing service and the service itself returns HTTP 403 despite the above configuration, this appears potentially to be a service-side authorization/provisioning issue.

My Azure subscription does not include paid technical support. Could a Microsoft Artifact Signing engineer or moderator please advise why the signing service is returning 403 or provide an appropriate escalation path? If server-side logs can be checked, the failed request timestamp above may help identify the request.

Sandra Wolff 0 Reputation points

2026-09-18T02:33:14.7133333+00:00

No. These checks were completed before the question was posted. The Certificate Profile Signer role, account/profile names, Completed identity validation, Active profile, x64 Dlib/SignTool, .NET 8+, VC++ x64 runtime, provider registration, and credential exclusions have all been verified. The same HTTP 403 is reproducible with both SignTool+dlib and Invoke-ArtifactSigning.

I am looking for Microsoft Artifact Signing engineering/moderator assistance determining why the service returns 403 at “Submitting digest for signing...” despite the documented prerequisites and RBAC configuration being satisfied.
Meha-MSFT 2,460 Reputation points Microsoft Employee Moderator

2026-09-18T17:30:03.5733333+00:00

Looking into this.
Dawn-MSFT 80 Reputation points Microsoft Employee

2026-09-18T18:22:56.9466667+00:00

For the 403 error, please double-check and confirm that the identity being used for signing is the same identity that has the Signer role assigned.

Could you also try running az logout and then az login to make sure you get a fresh access token?

1 answer

Your answer

Sandra Wolff 0 Reputation points

2026-09-18T02:33:14.7133333+00:00

No. These checks were completed before the question was posted. The Certificate Profile Signer role, account/profile names, Completed identity validation, Active profile, x64 Dlib/SignTool, .NET 8+, VC++ x64 runtime, provider registration, and credential exclusions have all been verified. The same HTTP 403 is reproducible with both SignTool+dlib and Invoke-ArtifactSigning.

I am looking for Microsoft Artifact Signing engineering/moderator assistance determining why the service returns 403 at “Submitting digest for signing...” despite the documented prerequisites and RBAC configuration being satisfied.
Meha-MSFT 2,460 Reputation points Microsoft Employee Moderator

2026-09-18T17:30:03.5733333+00:00

Looking into this.
Dawn-MSFT 80 Reputation points Microsoft Employee

2026-09-18T18:22:56.9466667+00:00

For the 403 error, please double-check and confirm that the identity being used for signing is the same identity that has the Signer role assigned.

Could you also try running az logout and then az login to make sure you get a fresh access token?

Answer 1

For HTTP 403 from Artifact Signing, the supported checks are these:

Verify the signing identity has Artifact Signing Certificate Profile Signer.
Verify the Artifact Signing account name and certificate profile name in metadata.json exactly match the Azure resource names.
Verify the identity validation status is Completed.
Verify the certificate profile status is Active.
Verify the dlib and dlib path.
Verify the .NET version, dlib version, and Windows SDK version are compatible.
Install the Microsoft Visual C++ Redistributable (x64).
Verify the machine can reach the Artifact Signing endpoint; if needed, try the same signing operation from a different VM or computer because 403 can indicate a network issue.
For authentication-chain issues, exclude unwanted credentials in the manifest/JSON. A documented mitigation for Azure authentication and a moderator-recommended fix for 403 cases is to add ExcludeCredentials entries so the client does not pick the wrong cached identity.

Since the same 403 occurs with both SignTool+dlib and Invoke-ArtifactSigning, and the failure happens at Submitting digest for signing..., that narrows the issue to service authorization, identity selection, endpoint access, or profile/account state rather than the EXE itself.

A focused next pass is:

In the signing JSON, add ExcludeCredentials to eliminate cached or unintended identities, especially if multiple Azure sign-in methods exist on the machine.
Reconfirm the exact Artifact Signing account name is the resource name, not a user name or app registration name.
Reconfirm the signing identity has the Artifact Signing Certificate Profile Signer role on the Artifact Signing account.
Test from a different machine or VM to rule out local network or endpoint-access issues.
If using service principal with certificate-based authentication, verify the required environment variables.

If the issue is specifically a wrong credential being selected, excluding credentials such as EnvironmentCredential, ManagedIdentityCredential, SharedTokenCacheCredential, VisualStudioCredential, VisualStudioCodeCredential, AzurePowerShellCredential, and AzureDeveloperCliCredential has resolved 403 cases.

Also verify the local tooling prerequisites because silent or misleading failures can occur when dependencies are missing:

Use the matching x64 SignTool with the corresponding x64 Azure.CodeSigning.Dlib.dll.
Use the recommended Windows SDK version.
Ensure x64 .NET 8 or later is installed.
Ensure the VC++ x64 redistributable is installed.

References: