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

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

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

я получаю сообщение об ошибке:

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

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

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

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


code-signing hudson authenticode
person Tim    schedule 23.04.2010    source источник

Ответы (5)


arrow_upward
15
arrow_downward

Взято из вывода 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 maker: пожалуйста, задокументируйте это!). Дополнительная сложность заключается в том, что трудно определить, к какому магазину Hudson предоставляет доступ - это не локальная учетная запись Hudson, как вы могли ожидать.

Примечание: «Личное» хранилище, указанное в представлениях mmc, является «МОИМ» хранилищем при доступе из signtool.

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

person Will Bickford    schedule 17.11.2011

arrow_upward
4
arrow_downward

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

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

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

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

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

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

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

    C: \> psexec -i -s cmd

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

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

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

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

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

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

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

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

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

person Grimace of Despair    schedule 21.03.2013

arrow_upward
1
arrow_downward

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

У меня есть сервер 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.

person Gerard Sexton    schedule 03.12.2012

arrow_upward
0
arrow_downward

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

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

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

person Tim    schedule 24.04.2010

arrow_upward
0
arrow_downward

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

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

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

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

  • Удаленный рабочий стол для вашего подчиненного устройства Windows
  • Откройте windows mmc (выберите «Выполнить» в меню «Пуск» и введите mmc)
  • Создайте новую оснастку сертификата (Файл -> Добавить / удалить оснастку)
  • Выберите оснастку Certificates и добавьте ее
  • Настройте оснастку для управления сертификатами для Computer Account
  • Щелкните OK, а затем Finish
  • Добавьте новую оснастку, нажав OK
  • Теперь перейдите и разверните Trusted Root Certificates Authorities, щелкните правой кнопкой мыши Сертификаты-> Все задачи-> Импорт.
  • Импортируйте сертификат подписи, следуйте инструкциям, и все готово.
person Brikend Rama    schedule 20.09.2019