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

Question

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

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

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

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

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

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

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

Answer 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 для безопасности, как вы могли бы ожидать.

Примечание.Магазин «MY» при доступе из signtool.

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

Answer 2

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

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

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

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

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

   Затем я щелкнул правой кнопкой мыши сертификат и [Export] 'ed. Я поставил галочку [Экспортировать личный ключ] и выбрал формат 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 создал свойство , которое является наиболее важным для запуска его на сервере сборки.

   Обратите внимание, что я также добавил Сервер отметок времени , который не обязателен, но настоятельно рекомендуется для подписи программного обеспечения. В противном случае ваше программное обеспечение может прекратить проверку по истечении срока действия вашего сертификата. Для 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. Ура!

Answer 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.

Answer 4

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

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

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