Подтвердить что ты не робот

Как правильно использовать signtool.exe в hudson, запущенном как служба?

Я только что купил сертификат подписи кода (MS authenticode) от THAWTE и установил его, очевидно, на мою машину сборки. Я зарегистрировался как пользователь, и когда я открываю приглашение cmd, я могу подписывать EXE, используя cert с signtool.exe.

К сожалению, эта же командная строка не работает в процессе hudson, который запущен на машине.

появляется сообщение об ошибке:

Ошибка SignTool: сертификаты не были что соответствует всем заданным критериям.

Я предполагаю, что это потому, что служба hudson работает под другой учетной записью, чем учетная запись, в которой я запускал signtool.exe из и из учетной записи, которую я использовал для получения сертификата от thawte.

Итак, мой вопрос: как я могу исправить эту проблему? Я думал, что собираюсь загрузить файл из thawte, но вместо этого он просто использовал IE, чтобы каким-то образом установить сертификат в кеш пользователя. Я, вероятно, хочу экспортировать (или какой бы то ни было правильный термин) в файл, который я могу хранить/сохранять или использовать на любом другом компьютере.

Как мне это сделать и как я могу правильно вызвать signtool с файлом или сертификатом от другого пользователя в учетной записи системы/служб?

4b9b3361

ОТВЕТЫ

Ответ 1

Взято из вывода signtool sign -h:

/s <name>   Specify the Store to open when searching for the cert. The default
is the "MY" Store.
/sm         Open a Machine store instead of a User store.

Добиться того, чтобы это работало, немного сложно... Я смог заставить его работать, добавив сертификаты в локальное хранилище компьютеров и используя ключ /sm.

Параметр/s позволяет вам выбрать, какое заранее определенное хранилище использовать. К сожалению, я не могу найти какую-либо документацию, в которой перечислены доступные параметры (@Microsoft signtool сопровождающий: пожалуйста, задокументируйте это!). Дополнительным осложнением является то, что трудно определить, к какому магазину Хадсон предоставляет доступ - это не локальная учетная запись Hudson, как вы могли бы ожидать.

Примечание. "Персональное" хранилище, указанное в представлениях mmc, является "MY" хранилищем при доступе из signtool.

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

Ответ 2

В качестве справочной информации я расскажу о нашем опыте. Мы используем TeamCity для создания подписанного приложения ClickOnce. Мне потребовалось несколько часов, чтобы все было правильно, поэтому я надеюсь, что это еще немного спасет кого-то.

Примечание. Я запускаю это на сервере Windows 2k3, который также является сервером домена (да, я знаю).

  • Мы используем сертификат Code Signing Certificate от GoDaddy. CSR был создан с помощью Internet Explorer. Итак, завершая выпуск с помощью Internet Explorer, я в основном оказался с сертификатом подписи кода, установленным в моей учетной записи.

  • Поскольку мне нужен сертификат на сервере сборки, я выбрал в IE:

    [Дополнительно] > [Свойства обозревателя] > [Содержание] > [Сертификаты]

    Затем я щелкнул правой кнопкой мыши сертификат и [Экспорт]. Я отметил [Экспорт личного ключа] и выбрал формат PFX с [Экспорт всех сертификатов] и [Экспортировать все свойства] (не уверен, что что последний действительно необходим). Наконец, после указания местоположения, у меня было мое Драгоценное.

  • Теперь я был готов к настоящей боли, но, чтобы сэкономить вам подробности, я пропущу неприятные хикки. Поскольку TeamCity работает под учетной записью System, мне нужно было иметь этот сертификат на нашем сервере сборки в той же самой учетной записи. Итак, на сервере сборки я вызвал:

    C: \ > psexec -i -s cmd

  • Это запустило для меня командную строку, запущенную как пользователь System. Теперь я снова вызвал свой ржавый IE:

    C: \ > C:\Program Files (x86)\Internet Explorer\iexplore.exe

  • Я перешел к сертификатам, и вместо экспорта я выбрал Импорт и выбрал сертификат, который я ранее экспортировал. я пусть Windows выбирает, где их хранить.

  • Теперь все было на месте, чтобы использовать ClickOnce сертификат для подписи нашего приложения. Нам просто нужно было убедиться, что ClickOnce знает об этом. Я не хотел помещать наш ключевой файл в репозиторий кода, поэтому в моей локальной Visual Studio на вкладке [Подписывание] свойств проекта я отметил [ClickOnce manifestests] и использовал [Выбрать из магазина...] вместо [Выбрать из файла...]. Это позволило мне выбрать мой локально установленный сертификат. В этот самый момент VS создал свойство <ManifestCertificateThumbprint> что является самым важным моментом в его запуске на сервере сборки.

    Обратите внимание, что я также добавил Timestamp server, который не является обязательным, но настоятельно рекомендуется для подписания программного обеспечения. В противном случае ваше программное обеспечение может перестать проверять, когда истечет срок действия вашего сертификата. Для GoDaddy сервер времени http://tsa.starfieldtech.com.

    Также обратите внимание, что я не подписал сборку (пока). Просто сообщите, чтобы вы знали, что это возможно.

  • Теперь сервер сборки забирает файл проекта и новое свойство ManifestCertificateThumbprint и передает его в задачу SignTool. Чтобы запустить этот запуск, мне пришлось скопировать над signtool.exe из C:\Program Files (x86)\Microsoft SDK\Windows\v7.0A\Bin в то же место на сборке сервер.

    Серьезная отвратительная отладка выяснила, почему знак не работал. Я вытащил инструменты, такие как ProcMon и Process Explorer, чтобы узнать какие ключи реестра запрашивались с помощью командной строки. Я воссоздал фактическую командную строку, вызываемую SignTool, и наблюдал за эффектами с помощью этих инструментов.

Наконец, после большого интенсивного развития и системной боли, я смог развернуть наше подписанное приложение ClickOnce. Ура!

Ответ 3

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

У меня есть сервер Jenkins CI, работающий на Win2008R2 как служба, которая не смогла найти сертификат при выполнении задания, но вручную я мог подписывать что-либо на одной машине.

signtool sign /sha1 ### file.dll  
SignTool Error: No certificates were found that met all the given criteria.

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

signtool sign /sm /sha1 ### file.dll

Те же ошибки. /a тоже ничего не делал.

Я начал работать, создав пользователя "Jenkins" в качестве члена группы "Администраторы", запустив службу как пользователь "Jenkins", войдя в систему как пользователь Jenkins и установив сертификат в хранилище пользователей.

Да, я установил сертификат в локальный магазин. Я даже подтвердил, что хранилище услуг имело сертификат, используя mmc и добавляя учетную запись службы - магазин Jenkins.

Ответ 4

Я думал, что это будет простая проблема для решения. Вместо этого он превращается в греческую трагедию.

Поставщик, Thawte, по-видимому, считает необходимым потребовать, чтобы все действия сертификата выполнялись на том же компьютере и в браузере, с которого инициировался запрос. К сожалению, в моем случае я сделал это с Windows7. Из-за некоторой бессмыслицы MS это означает, что когда я получил сертификат, я не могу экспортировать его с помощью закрытого ключа. Это возможно только на Win2000 XP. Поэтому мне нужно использовать 7-летнюю ОС, чтобы сделать что-то принципиальное для моего бизнеса. Это умопомрачительно.

Оказывается, теперь я жду, когда будет выполнен третий запрос сертификата.

Ответ 5

У меня была похожая проблема при попытке подписать исполняемый файл через подчиненный Jenkins на Windows. Проблема заключалась в том, что, поскольку jenkins работал в качестве службы на ведомом устройстве Windows, инструменту подписи не удалось найти импортированный сертификат в хранилище личных сертификатов (которое должно быть хранилищем по умолчанию, выбранным средством подписи в соответствии с справкой Microsoft)

Я получал следующую ошибку из консоли jenkins:

SignTool Error: No certificates were found that met all the given criteria.

С помощью следующего обходного пути мне удалось исправить проблему подписи на jenkins:

  • Удаленный рабочий стол для вашего ведомого окна
  • Откройте Windows MMC (выберите "Выполнить" в меню "Пуск", а затем введите "MMC")
  • Создать новую оснастку сертификата (Файл → Добавить/удалить оснастку)
  • Выберите оснастку Certificates и добавьте ее
  • Настройте оснастку для управления сертификатами для Computer Account
  • Нажмите OK, а затем Finish
  • Добавьте новую оснастку, нажав OK
  • Теперь перейдите и разверните Trusted Root Certificates Authorities, щелкните правой кнопкой мыши на Certificats-> Все Tasks-> Импорт
  • Импортируйте свой сертификат подписи, следуйте инструкциям, и все должно быть готово