SignService failing with signing tool error -2145844844

[andrewmolyneux]

I had SignService working fine for one of my Azure Pipelines projects in early October but since then I've been working on other projects that don't use SignService. Yesterday, I started trying to work on the project again but signing failed when I tried to run the pipeline. This is perplexing as I haven't changed anything in the intervening time (running exactly the same SignService code as I was in October, for example).

Looking at the "traces" table in Application Insights for SignService, I'm seeing this when I try to sign any type of file: Sign tool completed with error -2145844844

I get the same error code whether the file in question is being signed with SignTool or Mage.

Googling the error code tells me that it's probably HTTP_E_STATUS_NOT_FOUND, so I guess it's sending an HTTP request and getting a 404 error. It occurred to me that the problem might be with a request to the Azure Key Vault, but we're using exactly the same Key Vault from another pipeline that uses AzureSignTool and that is still working absolutely fine.

Any idea what could be going on here?

[clairernovotny]

Spitballing but can you see the attempted HTTP call that's returning the 404? It should show up in App Insights under the dependencies/tracing stuff?

[andrewmolyneux]

Thanks for the swift response @clairernovotny 😄 When I try to get it to sign a PowerShell script (the simplest case I can think of) and look at the "dependencies" table, I see the following HTTP requests (paraphrased because I don't want to accidentally include some sensitive information):

• Successful POST to https://login.microsoftonline.com/[tenantId]/oauth2/token
• Successful GET to https://[keyVault]/certificates/[certName]?api-version=7.0

Then I see a record with a type of "Sign Tool" that looks like this:

name	value
target	AzureSignToolSignService
type	Sign Tool
success	False
resultCode	-2145844844
name	SIGN \test.ps1
data	\test.ps1

Then a couple more HTTP requests:

• Successful GET to https://[keyVault]/keys/[certName]/[128-bit hex string]?api-version=7.0
• Successful POST to https://[keyVault]/keys/[certName]/[same 128-bit hex string]/sign?api-version=7.0

Then when it retries (two more times) I see the following each time:

• Failed "Sign Tool" record looking exactly like the one I showed above
• Successful POST to https://[keyVault]/keys/[certName]/[same 128-bit hex string]/sign?api-version=7.0

[andrewmolyneux]

The only other thing that I've spotted is I sometimes get this warning in the "traces" table: Increasing the MaxRequestBodySize conflicts with the max value for IIS limit maxAllowedContentLength. HTTP requests that have a content length greater than maxAllowedContentLength will still be rejected by IIS. You can disable the limit by either removing or setting the maxAllowedContentLength value to a higher limit. However, I'm pretty sure that's not new - it was saying that occasionally when it was working as well.

[clairernovotny]

Are you able to use AzureSignTool directly? It might have some more verbose options (though you'll need to set the right ACL's creds on the vault for the tool

https://github.com/vcsjones/AzureSignTool

[andrewmolyneux]

We do in fact use AzureSignTool for other projects - that was obviously much easier to get working as there are far fewer moving parts, so I'll always prefer to use that whenever I can. Unfortunately this particular project includes a VSTO Office add-in so it's ClickOnce and as far as I'm aware, SignService is the only currently viable option for signing ClickOnce bundles from Azure pipelines where the private key is in Key Vault rather than a PFX file 😢 In fact, I'm using SignService (or at least trying to) because you recommended it based on that very requirement 😃 https://github.com/vcsjones/AzureSignTool/issues/82 Incidentally, despite using a PS1 file as the example here, I get the same results when I try to sign a ClickOnce manifest.

[clairernovotny]

Overall, SignService is "better" in that it handles the orchestration of multiple files. For a VSTO project, it'll make sure it signs the dlls and updates the manifest checksums before signing the manifest itself. For a NuGet, it'll sign the files inside before signing the nupkg. It also logs things for auditing.

I just thought that using AzureSignTool might help narrow down the underlying issue as it'd be easier to debug.

[andrewmolyneux]

I'm not sure what you mean by using AzureSignTool to narrow down the underlying issue - I do have other pipelines using AzureSignTool.exe with exactly the same certificate in Key Vault, and they're all working fine, so I don't think there's any problem with the certificate or Key Vault. Or have I misunderstood you?