Подписание кода с помощью osslsigncode — издатель неизвестен

Я столкнулся с немного странным поведением при попытке автоматизировать компиляцию и подписание определенного двоичного файла на основе NSIS. А именно, makensis запускается под wine для компиляции исполняемого файла, а затем osslsigncode используется для подписи двоичного файла.

Исполняемый файл, кажется, собран нормально, так как он работает в системах Windows, однако есть проблема (из-за отсутствия лучшего слова) с подписью. Поскольку сертификат подписи кода имеет формат PKCS#12, используемая команда предлагается здесь:

osslsigncode sign -pkcs12 <pkcs12-file> -pass <pkcs12-password> \ -n "Your Application" -i http://www.yourwebsite.com/ \ -in yourapp.exe -out yourapp-signed.exe

Я получаю сообщение «Успешно» от osslsigncode, как будто подписание прошло нормально, однако, когда двоичный файл запускается в Windows (в данном случае Win 7), UAC говорит:

Издатель: Неизвестно

Странно то, что когда я открыл извлеченный сертификат из исходного файла .p12, чтобы просмотреть его информацию, Windows впоследствии смогла распознать издателя и цифровую подпись, как будто она каким-то образом узнала путь сертификации...?

Любой совет будет принят во внимание.

EDIT 1
Используемые версии osslsigncode: 1.5.2 и 1.7.1

РЕДАКТИРОВАТЬ 2
Для сравнения я попробовал подписать с помощью SignTool, и, похоже, это работает без проблем. Итак, это похоже на проблему с сертификатом + osslsigncode, но я не могу точно сказать, что это такое.

Я также попробовал osslsigncode на том же EXE-файле с другим сертификатом, и, что еще интереснее, это сработало... (я заметил, что пути сертификации различаются для двух сертификатов).

Некоторые сведения о сертификате:

1) нерабочий сертификат
версия: V3
открытый ключ: RSA 2048 бит
алгоритм хеширования подписи: sha1
алгоритм подписи: sha1RSA
путь сертификации: USERTrust -> Comodo Code Signing CA 2 -> NonWorkingCert

2) рабочий сертификат
версия: V3
открытый ключ: RSA 2048 бит
алгоритм хеширования подписи: sha1
алгоритм подписи: sha1RSA
путь сертификации: USERTrust -> UTN-UserFirst-Object -> Comodo Code Signing CA 2 -> WorkingCert


openssl code-signing signtool nsis
person Less    schedule 10.09.2014    source источник
comment
Странный. У меня такая же проблема спустя годы. Вы когда-нибудь находили ответ?   -  person Mikey A. Leonetti    schedule 22.08.2018

Ответы (1)


arrow_upward
4
arrow_downward

Это стоило мне нескольких часов головокружения, но, кажется, теперь я понимаю.

  • Windows имеет внутреннюю базу данных доверенных сертификатов. К ним относятся корневые сертификаты (установленные и обновленные Windows) и дополнительные промежуточные сертификаты CA, которые он видел в разное время (подписанные корневым сертификатом или каким-либо другим доверенным сертификатом).
  • Когда Windows/UAC проверяет исполняемую подпись при запуске, она ищет в локальной базе данных доверенный сертификат, который подписал корень сертификатов, встроенных в исполняемую подпись.
  • Если Windows не может найти доверенный сертификат подписи (возможно, из-за того, что встроенный сертификат подписан промежуточным сертификатом, а не корневым сертификатом, и промежуточный сертификат отсутствует в локальной базе данных), это приводит к неизвестному издателю.
  • Если вы просматриваете вкладку «Цифровые подписи» в свойствах исполняемого файла, Windows делает еще один шаг и пытается автоматически загрузить и установить любые действительные промежуточные сертификаты, которым доверяет один из ее локальных сертификатов. Как только этот промежуточный сертификат будет добавлен в локальное хранилище сертификатов Windows, проверка подписи при запуске исполняемого файла также начнет проходить (т. е. отображается правильный издатель). (Этот ответ MSDN объясняет логику, хотя описываемая ими основная причина — еще не обновленный корневой сертификат — отличается.)

Решение состоит в том, чтобы передать промежуточный сертификат osslsigncode вместе с основным сертификатом. (H/T to Tor Project за подтверждение.)

  • Найдите правильный промежуточный сертификат CA. Это можно сделать через openssl x509 -text -in cert.pem, а затем найти «Доступ к информации об органах власти» -> URI «CA Issuers». Идентификаторы сертификатов (серийные номера и т. д.) также можно найти в Windows на вкладке «Цифровые сертификаты» -> «Просмотр сертификата» -> «Путь сертификации».

    (Совет: не всегда доверяйте страницам поддержки ЦС, чтобы получить правильную информацию о том, какой промежуточный сертификат нужно загрузить, я потратил много времени на загрузку неправильных промежуточных сертификатов с веб-страницы ЦС.)

  • При необходимости конвертируйте все сертификаты в формат PEM с помощью openssl x509 -in my_intermediate_ca.crt -inform der -outform pem -out my_intermediate_ca.pem или аналогичного.

  • Поместите всю цепочку ЦС в один файл PEM, начав с сертификата подписи кода: cat mycert.pem my_intermediate_ca.pem > certchain.pem

    (Если сертификат подписи кода не является первым в цепочке, Windows увидит недопустимую подпись, которая «подписана» промежуточным сертификатом.)

  • Беги osslsigncode -certs certchain.pem ...

    (Примечание: я также прошел -h sha256 и -ts http://timestamp.digicert.com, хотя я думаю, что все будет работать и с другими комбинациями параметров.)

person projectgus    schedule 03.10.2018