Unable to sign locally with Trusted Signing

TDao 45 Reputation points
2024-06-07T06:53:36.42+00:00

I followed the instructions here to sign my dll locally using the the certificate from my Azure Trusted Signing account. It kept looking at local certificates, instead of pulling from my Azure account. I did do az login before running signtool. The signtool version is from C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool.exe

Am I missing anything?

  • command I used:
signtool sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "dlib\bin\x64\Azure.CodeSigning.Dlib.dll" /dmdf "metadata.json" "O:\path\to\file.dll"
  • console output:
The following certificates were considered:
    Issued to: ...
    Issued by: ...
    Expires:   Mon Aug 18 08:18:42 2025
    SHA1 hash: ...
    Issued to: ...
    Issued by: ...
    Expires:   Sat Aug 17 17:51:07 2024
    SHA1 hash: ...

After EKU filter, 10 certs were left.
After expiry filter, 9 certs were left.
The following certificates have been found to be suitable for signing:
    Issued to: ...
    Issued by: ...
    Expires:   Mon Aug 18 08:18:42 2025
    SHA1 hash: ...
    Issued to: ...
    Issued by: ...
    Expires:   Sat Aug 17 17:51:07 2024
    SHA1 hash: ...

SignTool Error: Multiple certificates were found that meet all the given
        criteria. Use the /a option to allow SignTool to choose the best
        certificate automatically or use the /sha1 option with the hash of the
        desired certificate.

The following certificates meet all given criteria:
    Issued to: ...
    Issued by: ...
    Expires:   Mon Aug 18 08:18:42 2025
    SHA1 hash: ...
    Issued to: ...
    Issued by: ...
    Expires:   Sat Aug 04 12:37:58 2068
    SHA1 hash: ...

Azure Trusted Signing
Azure Trusted Signing
Trusted Signing is a Microsoft fully managed, end-to-end signing solution that simplifies the certificate signing process and helps partner developers more easily build and distribute applications.
17 questions
0 comments No comments
{count} votes

Accepted answer
  1. Givary-MSFT 30,071 Reputation points Microsoft Employee
    2024-06-09T16:55:43.0133333+00:00

    @TDao I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

    Issue: I followed the instructions here to sign my dll locally using the the certificate from my Azure Trusted Signing account. It kept looking at local certificates, instead of pulling from my Azure account. I did do az login before running signtool. The signtool version is from C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool.exe

    Resolution: Resolved by @TDao

    I got it working. Looks like when signing locally and use az login to authenticate, signtool expect certain tenant and subscription to be set as well. As long as I ran the following 2 commands, I was able to sign just fine after that, without the /sha1 or /a options.

    az login --tenant <tenant_id>

    az account set --subscription <sub_id>

    This seems not very intuitive since signtool should have been able to determine from my the metadata to find the corresponding tenant and subscription that have the expected signing account and profile.

    If you have any other questions or are still running into more issues, please let me know. Thank you again for your time and patience throughout this issue.

    Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

    0 comments No comments

2 additional answers

Sort by: Most helpful
  1. Teafatiller 156 Reputation points
    2024-06-07T07:00:43.13+00:00

    It seems like there is an issue with SignTool considering multiple certificates that meet the given criteria. This can occur if there are multiple valid certificates available on your system.

    The error message suggests two possible solutions:

    1. Use the /a option to allow SignTool to choose the best certificate automatically.
    2. Use the /sha1 option with the hash of the desired certificate.

    Here’s how you might modify your command:

    signtool sign /a /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "dlib\bin\x64\Azure.CodeSigning.Dlib.dll" /dmdf "metadata.json" "O:\
    

    or

    signtool sign /sha1 YOUR_CERTIFICATE_HASH /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "dlib\bin\x64\Azure.CodeSigning.Dlib.dll" /dmdf "metadata.json" "O:\
    

    Replace YOUR_CERTIFICATE_HASH with the SHA1 hash of the certificate you want to use.

    If you’re still experiencing issues, please check the Trusted Signing role, account name, and certificate profile name in your metadata.json. Also, ensure that your authentication method is functioning correctly.

    https://learn.microsoft.com/en-us/answers/questions/1665128/how-do-i-fix-azure-trusted-service-account-error-w

    https://learn.microsoft.com/en-us/azure/trusted-signing/faq

    https://learn.microsoft.com/en-us/azure/trusted-signing/concept-trusted-signing-cert-management

    https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-domain-ssl-certificates


  2. TDao 45 Reputation points
    2024-06-08T21:59:29.2433333+00:00

    Ok I got it working. Looks like when signing locally and use az login to authenticate, signtool expect certain tenant and subscription to be set as well. As long as I ran the following 2 commands, I was able to sign just fine after that, without the /sha1 or /a options.

    az login --tenant <tenant_id>
    az account set --subscription <sub_id>
    

    This seems not very intuitive since signtool should have been able to determine from my the metadata to find the corresponding tenant and subscription that have the expected signing account and profile.

    0 comments No comments