Ошибка подписи кода с помощью signtool из-за фильтра закрытого ключа

при попытке подписать какой-то установщик, созданный компанией, в которой я работаю, я столкнулся с ошибкой, которую я не смог решить. Я использую тот же сертификат, который был успешно использован на другой машине (Win7) таким же образом для подписания квази того же установщика. Во всяком случае, на нашем Windows Server 2008, который работает CruiseControl.net я попытался подписать установщик с помощью signtool.exe и он терпит неудачу со следующей ошибкой:

The following certificates were considered:
    Issued to: <our company>
    Issued by: <some ca>
    Expires:   <is valid>
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: <...>
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Subject 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.

Я попытался установить сертификат в разные хранилища сертификатов, пробовал разные версии signtool.exe и попытался использовать .файл cer напрямую, но это не имело значения. Я получаю ошибку, упомянутую выше, во всех случаях. Я попробовал следующие команды командной строки

signtool.exe sign /debug /n "MyCompany" C:myinstaller.exe
signtool.exe sign /debug /f C:pathtomycertificate.cer C:myinstaller.exe

но в некоторых случаях я оставил /debug. Есть все, что я делаю неправильно или отсутствует?

4 ответов


чтобы подписать файл, вам нужно иметь закрытый ключ сертификата, который не входит в *.файл cer, скопированный с компьютера Windows 7. Чтобы экспортировать сертификат с закрытым ключом, вы можете следовать инструкции, прилагаемые здесь.

обратите внимание, что вы сможете экспортировать закрытый ключ только в том случае, если сертификат был настроен на экспорт при его создании (путем передачи -pe до makecert)


я тот же симптом, а всего иначе. Как и многие разработчики, у меня есть куча различных цепочек инструментов, установленных в моей системе. Я просто обследовал их, чтобы показать, как это может выглядеть; прокрутите до нижней части этого ответа для полного списка.

я установил свой сертификат подписи кода из VeriSign в хранилище системных сертификатов (требуется /sm С signtool.exe) как обычно, используя certutil -importPFX cert.pfx в командной быстрый.

первые тесты выглядели многообещающими, но затем внезапно подпись начала терпеть неудачу.

для отладки проблемы я сначала начал использовать signtool.exe sign /debug /v /a /sm ... для того, чтобы увидеть, что идет не так. Вывод выглядел так (Также см. вопрос):

The following certificates were considered:
    Issued to: localhost
    Issued by: localhost
    Expires:   Tue Dec 26 00:00:00 2017
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Root 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.

я мог бы исключить отсутствующий закрытый ключ, как ясно указано в хранилище сертификатов у меня есть соответствующего закрытый ключ:

Property dialog for certificate

теперь я помню что были некоторые недавние патчи, которые позволяют Windows 7 принимать подписи, сделанные с сертификатом, который имеет хэш SHA256. Хотя, конечно, в большинстве старых статей будет указано, что Windows 7 не может обрабатывать хэши SHA-2 вообще.

так что это уже дало мне толчок в направлении "это должна быть старая версия чего-то, связанного с подписанием".

я еще решил удалить ключ certificate plus и повторно импортировать его с помощью вызов, показанный ранее.

затем, осмотрев мою систему (см. В нижней части ответа), я нашел колоссальный пять разные версии signtool.exe. Поэтому я начал с попытки новейшего (6.3.9600.17298, из Windows 8.1 SDK) и он сразу работал:

signtool.exe sign /debug /v /a /sm /r VeriSign /ac MSCV-VSClass3.cer /ph  /t "http://timestamp.verisign.com/scripts/timstamp.dll" *.exe

The following certificates were considered:
    Issued to: localhost
    Issued by: localhost
    Expires:   Tue Dec 26 00:00:00 2017
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Root Name filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

Cross certificate chain (using machine store):
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires:   Sat Nov 01 13:54:03 2025
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

        Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
        Issued by: Microsoft Code Verification Root
        Expires:   Mon Feb 22 19:35:17 2021
        SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B

            Issued to: Symantec Class 3 SHA256 Code Signing CA
            Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
            Expires:   Sat Dec 09 23:59:59 2023
            SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5

                Issued to: <...>
                Issued by: Symantec Class 3 SHA256 Code Signing CA
                Expires:   <...>
                SHA1 hash: <...>


The following additional certificates will be attached:
    Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
    Issued by: Microsoft Code Verification Root
    Expires:   Mon Feb 22 19:35:17 2021
    SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B

    Issued to: Symantec Class 3 SHA256 Code Signing CA
    Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
    Expires:   Sat Dec 09 23:59:59 2023
    SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5

Done Adding Additional Store
Successfully signed: <...>.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

отслеживая это дальше, я думал, что нашел проблему. Однако оказалось, что ошибка, которую я получил, - это не то, что я бы увидел со старшим signtool.exe версий. Вместо этого более старые версии жаловались бы на /ac, /fd и /ph быть нераспознанными параметрами командной строки, соответственно.

так что мне нужно копать немного глубже, и оказалось, что мой (альтернативный) файловый менеджер был виновником. Обычно я запускаю свои командные подсказки в соответствующей папке, используя этот файловый менеджер и удобную комбинацию клавиш. Оказывается, что он иногда не передает переменные среды-по сути, файловый менеджер "забывает" переменные среды. Это оказалось основной причиной. Командная строка, открытая с помощью Win+R а то cmd Enter не будет выставлять это поведение, несмотря на выполнение signtool.exe из той же папки.

мое лучшее предположение из этого заключается в том, что из-за беспорядка PATH переменная или аналогичная,signtool.exe в конечном итоге выбрал неправильную DLL. В частности mssign32.dll и wintrust.dll сопровождал signtool.exe в той же папке для Windows SDK 8.0 и 8.1, но не для любой из предыдущих версий signtool.exe который выберет" глобальные " общесистемные библиотеки DLL, какими бы они ни оказались.


в моей системе у меня было пять разные версии signtool.exe.

программы signtool.exe 5.2.3790.1830

не понимаю /ac и /ph аргументы, которые я использовал (также не /fd). Но, как ни странно, сработало и без этих двоих. аргументы.

  • C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\signtool.exe

программы signtool.exe 6.0.4002.0

не понимаю /ac и /ph аргументы, которые я использовал (также не /fd). Но, как ни странно, сработало и без этих двух аргументов.

  • C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\Bin\signtool.exe

программы signtool.exe 6.1.7600.16385

первая версия, чтобы понять /fd sha256.

  • C:\WINDDK00.16385.1\bin\amd64\SignTool.exe
  • C:\WINDDK00.16385.1\bin\x86\SignTool.exe
  • C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe
  • C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe
  • C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe

программы signtool.exe 6.2.9200.20789

  • C:\Program Files (x86)\Windows Kits.0\bin\x64\signtool.exe
  • C:\Program Files (x86)\Windows Kits.0\bin\x86\signtool.exe

программы signtool.exe 6.3.9600.17298

  • C:\Program Files (x86)\Windows Kits.1\bin\arm\signtool.exe
  • C:\Program Files (x86)\Windows Kits.1\bin\x64\signtool.exe
  • C:\Program Files (x86)\Windows Kits.1\bin\x86\signtool.exe

У меня была такая же проблема на машине Win7 и пробовал все, что хорошие люди предложили в этом посте без везения. Тогда даже моя машина имеет только одну учетную запись и имеет права администратора, я открыл окно командной строки "Запуск от имени администратора", а затем все версии signtool.exe, который я установил, начинает работать.


Мне тоже пришлось подписать файл, используя сертификат, который я получил из другого источника (похожего на вас). Для меня проблема заключалась в том, что я установил сертификат только на свой компьютер с опцией "текущий пользователь". Как только я установил его, используя опцию "локальная машина", он работал.

enter image description here