Trusted Signing 404 Not Found for /sign endpoint using api-version=2022-06-15-preview

[michael-sabrnak-swi]

The issue:
Since yesterday we started to see 404 errors from Azure Trusted Signing when using JSign:

java.io.IOException: HTTP Error 404 - Not Found (<https://eus.codesigning.azure.net//codesigningaccounts/xyz/certificateprofiles/xyz/sign?api-version=2022-06-15-preview)>

This setup worked for months before without changes on our side.

What we see:

• All JSign signing calls to Azure Trusted Signing now fail with HTTP 404 on the /sign endpoint.
• The URL JSign calls includes api-version=2022-06-15-preview.
• The account and certificate profile exist and are healthy in Azure.
• The same Azure Trusted Signing account and profile work when we use SignTool.exe with the official Azure Code Signing / Trusted Signing Dlib client. So the service, account, and profile are fine.

This suggests that JSign might be using an outdated or no longer supported API version or endpoint for Azure Trusted Signing.

Can you please check if JSign is using an outdated API version for Azure Trusted Signing, and whether it can be updated or made configurable? It looks like newer API versions exist on the Azure side, for example: 2024-09-30-preview.

I have also engaged Microsoft support to get clarification from their side.

[michael-sabrnak-swi]

Quick update on the root cause from my side:

It turns out the problem was not the api-version, but the way the endpoint URL was constructed.

We had the endpoint configured with a trailing slash: https://eus.codesigning.azure.net/

This used to work, but now returns HTTP 404.

When I remove the trailing slash from the endpoint: https://eus.codesigning.azure.net and signing works again in my local tests.

It looks like something changed on the Microsoft side so that their frontend (probably Kestrel) no longer normalizes multiple consecutive slashes in the path, so //codesigningaccounts/... now results in a 404 instead of being treated the same as /codesigningaccounts/....

Note: Updating JSign to use a newer API version could still be beneficial. From the service response headers I see api-supported-versions: 2022-06-15-preview, 2023-06-15-preview, 2024-06-15

[ebourg]

Thank you for reporting this issue, Jsign could probably trim the trailing slash in the endpoint.

I no longer have an Azure Trusted Signing account, do you think you could recompile Jsign with the modified API version and check if it still works?

[michael-sabrnak-swi]

Hi @ebourg,

Quick follow up with some more detailed testing around the API versions while using --debug flag.

POST https://eus.codesigning.azure.net/codesigningaccounts/xyz/certificateprofiles/xyz/sign?api-version=2023-06-15-preview
User-Agent: Jsign (https://ebourg.github.io/jsign/)
Content-Type: application/json; charset=utf-8
Content:
{"digest":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=","signatureAlgorithm":"RS256"}

Response Code: 400
Content-Type: null
jsign: Unable to retrieve the certificate chain 'xyz/xyz'
java.security.KeyStoreException: Unable to retrieve the certificate chain 'xyz/xyz'
	at net.jsign.jca.AzureTrustedSigningService.getCertificateChain(AzureTrustedSigningService.java:109)
	at net.jsign.jca.SigningServiceKeyStore.engineGetCertificateChain(SigningServiceKeyStore.java:43)
	at java.base/java.security.KeyStore.getCertificateChain(KeyStore.java:1075)
	at net.jsign.SignerHelper.build(SignerHelper.java:388)
	at net.jsign.SignerHelper.sign(SignerHelper.java:471)
	at net.jsign.SignerHelper.execute(SignerHelper.java:325)
	at net.jsign.JsignCLI.execute(JsignCLI.java:229)
	at net.jsign.JsignCLI.main(JsignCLI.java:58)
Caused by: java.io.IOException: HTTP Error 400 - Bad Request (https://eus.codesigning.azure.net/codesigningaccounts/xyz/certificateprofiles/xyz/sign?api-version=2023-06-15-preview)
	at net.jsign.jca.RESTClient.query(RESTClient.java:192)
	at net.jsign.jca.RESTClient.post(RESTClient.java:74)
	at net.jsign.jca.AzureTrustedSigningService.sign(AzureTrustedSigningService.java:147)
	at net.jsign.jca.AzureTrustedSigningService.getCertificateChain(AzureTrustedSigningService.java:106)
	... 7 more
Try `java -jar jsign.jar --help' for more information.

Results:

api-version=2023-06-15-preview:

• Response: HTTP 400 Bad Request
• No Content-Type or body visible in JSign debug output

api-version=2024-06-15:

• Response: HTTP 400 Bad Request
• Same request body as above

api-version=2022-06-15-preview:

• Response: HTTP 202 Accepted
• JSign then polls the operation URL and gets a 200 with the signature and certificate, so signing succeeds

The only difference between these calls is the api-version query parameter. Same endpoint, same account/profile, same JSON payload.

So the server advertises all three versions, but the current JSign payload is only accepted by 2022-06-15-preview. The newer versions return 400 for the same JSON, which suggests that 2023 and 2024 expect a slightly different request shape or additional fields/headers compared to 2022.

I checked and the only official documentation is for 2023-06-15-preview where dataplane expects probably different format:

• POST /codesigningaccounts/{accountName}/certificateprofiles/{certificateProfile}:sign instead of older format POST /codesigningaccounts/{account}/certificateprofiles/{profile}/sign?api-version=...

[ebourg]

Thank you for the analysis. Did you also try with :sign instead of /sign?

[michael-sabrnak-swi]

@ebourg I was able to produce signed artifact on 2023-06-15-preview API in this PR: #333 - can you have a look?

[ebourg]

Thank you! I'll get a look