9

I'm setting up a new development laptop, and have installed a self-issued code signing certificate. I can see it in certmgr under my Current Users's Personal Certificates.

When I try to build from the Developer Command Prompt For Visual Studio 2017 I get:
error : SignTool Error: No certificates were found that met all the given criteria.

This always worked fine on my old laptop.

I have found if I run the same build from the command prompt after starting it as admin that signtool succeeds and can find the cert.

This has happened to 3/4 colleagues when we've set up new laptops. One guy is ok and can sign without running as admin. On our old laptops we never had to run as admin.

I've tried googling to find what could be the cause because I wasn't aware that running as admin or not should have any affect over this. I haven't found any reference to this problem.

How can we use signtool.exe without running it as admin?

When not running as admin it appears to be at the Private Key filter step where the cert I'm expecting to be selected gets filtered out:

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************

C:\>signtool sign /v /debug /ph  /i "<issuedby>"  /fd sha256 /td sha256 "C:\TestSign.dll"

The following certificates were considered:
    Issued to: Scott Langham
    Issued by: <issuedby>
    Expires:   Sun Sep 25 09:54:55 2022
    SHA1 hash: <a_hash>

    Issued to: Scott Langham
    Issued by: <issuedby_somethingelse>
    Expires:   Wed May 13 15:51:14 2020
    SHA1 hash: <b_hash>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Issuer Name filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.

I've ensured the version of signtool.exe I'm using is the same as the one that my colleague who has this working is using (10.0.18362.1). I've been able to spot any other differences between our systems.

Scott Langham
  • 58,735
  • 39
  • 131
  • 204
  • Looks like someone else had a similar issue. The solution is to run as admin. I was hoping to be able to run not as admin as I always have in the past. https://stackoverflow.com/a/56342401/11898 – Scott Langham Jun 13 '19 at 19:28
  • Have you tried to sign using the SHA1 thumbprint of the signing cert? (/sha1 option). I always found it was the easiest way. – Simon Mourier Jul 12 '19 at 06:13
  • this mean that `bool Certificate::HasPrivateKey()` inside your *signtool.exe* return *false*. because `CryptAcquireCertificatePrivateKey` fail. faster of all [`NCryptOpenKey`](https://learn.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptopenkey) fail. fail when try open file where your private key stored due access denied when run not as admin. this is strange, because it ask for read only access. need look under debuger where this is fail. i can not reproduce this issue – RbMm Jul 13 '19 at 00:44
  • You have written "This always worked fine on my old laptop." What OS was your old laptop and what OS is on your new laptop? – Aleksandar Jul 17 '19 at 19:07
  • @Aleksandar Old laptop was Win8.1 new is Win10. But this has also happened to colleagues who got new laptops too, and their old laptop was Win10. – Scott Langham Jul 20 '19 at 01:05

5 Answers5

4

I ran into this today and here is how I am now able to run signtool.exe via command line without elevating to admin.

  • Run 'mmc' and add the 'Certificates' snap-in
  • Select the correct key store location
    • (mine is in Local Computer so I select 'Computer account' here)
  • Find and select the certificate
  • Right click on the certificate, select All Tasks > Manage Private Keys...

enter image description here

  • In the 'Permissions for private keys' dialog, Add your user account and then give yourself 'Full Control'. You will now be able to sign using a normal command prompt.

Managing Certificate Permissions

  • Note: If you use a build machine, do the above steps for the account that performs the builds.
Roger Stewart
  • 1,105
  • 1
  • 15
  • 24
  • 1
    Great! I had my cert in the Current User\Personal store and don't see the "Manage Private Keys..." option there. But, after exporting and importing the certificate into the Local Computer\Personal store, I could access that option and adjust permissions. And now it's working for me! Thanks very much, this problem had been annoying me multiple times per day! – Scott Langham Nov 19 '19 at 16:43
2

Similar to what @Baget said, I'd compare the certificates on your machine to that of your colleague who can successfully run the SignTool.exe command without the elevation token. Here's a chunk of PowerShell to assist you:

get-childitem -Path Cert:\ | foreach-object ({
    $location = $_.Location
    foreach($store in $_.StoreNames.Keys) {         
        get-childitem -Path "Cert:\$location\$store" | foreach-object ({
            $thumb = $($_.ThumbPrint)
            $issuer = $($_.Issuer)

            if ($issuer -eq "CN=EXAMPLE, DC=EXAMPLE, DC=EXAMPLE, DC=EXAMPLE") {
                write-host "$location $store $issuer"
            }
        })
    }
})

Bear in mind that the output of the above may differ slightly if you run as a normal user and 'run as admin'.

Finally, do you and your colleague have the same UAC settings?

Captain_Planet
  • 1,228
  • 1
  • 12
  • 28
1

I found myself in a similar situation with signtool, it refused to work with an admin user but does work as actual Administrator.

In my case, I am not actually importing the certificate into the certificate store, but using a .pkcs12 file exported from a comodo certificate in firefox, so this makes things even stranger, as no permissions on any keys in the store are involved.

I tried granting myself permissions on some server key, but that did nothing.

I hope someone finds a solution to this problem.

In the meantime, I am signing my exe with osslsigncode instead, which works perfectly.

I extracted the exe and dependent dlls from the msys2 mingw64 build, here is a zip of everything in case it is of use to anyone, just extract it to a directory and put it in your PATH.

http://cachemiss.com/files/osslsigncode.zip

To extract this program yourself from an msys2 installation, you can use this command:

pacman --noconfirm -S mingw-w64-x86_64-osslsigncode
cd /mingw64/bin
mkdir ~/osslsigncode
cp osslsigncode.exe $(ldd osslsigncode.exe | sed -n 's,^.*\(/mingw64/[^ ]*\).*,\1,p' | sort -u) ~/osslsigncode/
cd
zip -9r osslsigncode.zip osslsigncode

I am using this in Visual Studio cmake builds with no issue.

Rafael Kitover
  • 967
  • 10
  • 13
0

There are two Certificate Store in Windows, User Store, and a machine store, you probably installed the certificate to the local machine, or you installed it when you run as elevated user.

Baget
  • 3,318
  • 1
  • 24
  • 44
0

Firstly you are getting such an error and you are using visual studio then See the signing tab in project properties. You will see a previously assigned signature (strong assembly)

If you enter the correct password here:

If your environment is the same as the environment in which the project is written, you will skip this error. Look the post on about the error

The reasons behind this error are:

1- Visual Studio needs some features when using certificate file to sign strong assembly.

ClickOnce Manifest Signing and Strong-Name Assembly Signing Using Visual Studio Project Designer's Signing Page

You can try this code to determine

signtool sign /debug /f mypfxfile.pfx /p <password> (mydllexectuable).exe

2- These settings can vary from machine to machine, and windows does not write these settings to the environment setting by default. check the config path

This part is just a deep note! not interested with the question you should add your private keystore file to request header and those all for this. My favorite steps about the creation of a certificate on this post

Hamit YILDIRIM
  • 4,224
  • 1
  • 32
  • 35