A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
The 403 (Forbidden) with SignerSign() failed indicates that Artifact Signing is rejecting the sign request, not that SignTool itself is broken. In the context of Artifact Signing, common 403 causes are:
- Subscription or account not in a valid state
- Identity no longer having the Artifact Signing Certificate Profile Signer role
- Endpoint / profile metadata mismatch
- Certificate profile not in an active/valid state from the service’s perspective
For Artifact Signing specifically, the documented mitigations for 403 are:
- Verify the Azure subscription status is Registered.
- Confirm that the identity used to sign (user, service principal, or managed identity) still has the Artifact Signing Certificate Profile Signer role on the resource group or subscription that contains the Artifact Signing account.
- Check that the
CodeSigningAccountNameandCertificateProfileNamein themetadata.jsonfile exactly match the Artifact Signing account and certificate profile names. - Ensure the dlib path and dlib version are correct and supported, and that the recommended Windows SDK and .NET versions are installed.
- Confirm that the certificate profile’s Status is Active and that the identity validation for that profile shows Completed.
- Verify that the
Endpointinmetadata.jsonmatches the region where the Artifact Signing account and certificate profile were created. A region/endpoint mismatch commonly produces 403 and an internalSignerSign()failure. - If using Private Trust, ensure the same user object ID that calls
Get-AzCodeSigningRootCertis the one doing the signing and that it has the Artifact Signing Certificate Profile Signer role. - Try the signing operation from a different VM or machine to rule out local or network issues reaching the Artifact Signing endpoint.
Regarding the expiry date shown in the portal: Artifact Signing certificates themselves are short-lived (three-day validity) and are managed by the service; time stamping is required so signatures remain valid beyond that period. The service documentation does not describe automatic renewal behavior for the certificate profile’s portal “Expiry date” field, and it does not expose the underlying Authenticode certificate to the customer. If the profile shows an expiry date in the past while the status is still Active but signing returns 403, this aligns with the general guidance that the profile or its validation/state in the service must be checked and, if necessary, recreated.
Because Artifact Signing resources cannot be migrated across subscriptions or tenants and must be recreated when those change, if there has been any change to subscription or tenant, all Artifact Signing resources (including certificate profiles) must be recreated.
Actionable steps:
- In Azure portal, open the subscription that contains the Artifact Signing account and confirm the subscription is Registered.
- On the Artifact Signing account and certificate profile:
- Confirm Status is Active.
- Confirm identity validation status is Completed.
- In Access control (IAM) for the resource group or subscription, verify that the signing identity has the Artifact Signing Certificate Profile Signer role.
- Open the
metadata.jsonused by SignTool and verify:-
Endpointmatches the region of the Artifact Signing account. -
CodeSigningAccountNameandCertificateProfileNameexactly match the portal values.
-
- Ensure the latest Azure.CodeSigning.Dlib.dll, Windows SDK, .NET runtime, and C++ Redistributables are installed as required.
- If all of the above are correct and the profile still shows a past expiry date with 403 responses, create a new certificate profile in the same Artifact Signing account, update
metadata.jsonto point to the new profile, and test signing again.
References: