Artifact Signing signing operation returns status:Failed with null signature

Zoiko Tech 0 Reputation points
2026-08-11T11:06:15.3366667+00:00

Signing consistently fails server-side using Dongle.TrustedSigning.dll (tested v1.0.55 and v1.0.62).

Setup:

  • Account: ZoikoTimeSigning (Basic SKU, eastus)
  • Profile: ZoikoTimeProfile (PublicTrust, status: Active)
  • Subscription: fd72e3c3-4124-44d5-b3bb-be1376a7122e
  • Auth: az login with ******@zoikotech.com, role "Artifact Signing Certificate Profile Signer" confirmed assigned

Behavior: Auth succeeds, operation ID is generated, Azure returns HTTP 200 but with status:Failed and null signature/signingCertificate/counterSignature. No error detail returned.

Failed Operation IDs:

  • e783fff2-2ebe-4643-9baf-fd6765226dfc
  • 2087cdf3-a845-44fb-8a4a-973607000592
  • d832da22-1c90-4e68-9776-a8742712de28

All local config verified: endpoint, account name, profile name correct. Subscription enabled. Resource provider registered. What is causing the server-side failure?

Artifact Signing
Artifact Signing

A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)

0 comments No comments

2 answers

Sort by: Most helpful
  1. Meha-MSFT 2,375 Reputation points Microsoft Employee Moderator
    2026-08-18T04:56:14.86+00:00

    Is your identity validation in completed status and all cert profiles are in Active state?

    Was this answer helpful?

    0 comments No comments

  2. Abdul Waqas 345 Reputation points
    2026-08-11T13:13:03.16+00:00

    Good news / bad news on this one I dug around and this exact signature (status: Failed, null signature, null errorResponse, HTTP 200/202 on the operation itself) has come up multiple times recently on Microsoft's own Q&A under the Artifact Signing tag, and none of them turned out to be a caller-side config problem. That's a fairly strong signal, given how thorough your checklist already is.

    A few things worth knowing:

    This looks like an account-level, service-side issue, not your setup. One recent report with basically identical symptoms (POST .../sign returns 202, resolves to {"status": "Failed", "signature": null, "errorResponse": null}, zero useful detail) traced back to the account itself being in a bad state server-side specifically, that account's subscription had briefly gone through a Disabled → re-enabled cycle at some point, and even though everything looked healthy in ARM/portal afterward (provisioningState: Succeeded, profile Active, role assigned correctly same checklist you've already done), signing stayed broken and certificate issuance silently stopped working at the account level. Another thread with the same status:Failed/null pattern was also tied to a "reinstated" signing identity. So: has this subscription/account ever been suspended, disabled for billing, or had any kind of hold even briefly since it was created? That's the one common thread across the reports I found.

    No error detail is apparently expected/known-bad behavior right now, not something you're missing on your end several people confirmed they get literally nothing else back from the API or portal to explain the failure, which matches what you're seeing.

    What actually gets these resolved: in the reports I saw, none were self-fixable they needed the Artifact Signing engineering team to intervene and reset the account state. So:

    1. Post your Operation IDs (which you've already got, good) and mention the exact account/subscription details in an Azure support ticket, even on a plan without technical support for Trusted Signing/Artifact Signing specifically, subscription and account-provisioning issues are usually still actionable as a non-technical/billing-adjacent request.
    2. Also flag it on the Microsoft Q&A "Artifact Signing" tag if you haven't Microsoft employees actively monitor that tag and have been the ones unblocking these specific account-state issues, since it's not something visible or fixable from the customer side.
    3. Worth double-checking Azure Resource Health for the CodeSigning resource type specifically (not just generic Service Health) account-level holds like this don't always surface as a public service health event.

    Given you're hitting three consecutive Operation IDs with the exact same null-signature pattern and everything local checks out, I wouldn't spend more time re-verifying config this really does look like it needs a poke from Microsoft's side.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.