A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
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:
- 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.
- 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.
- 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.