Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Техническая поддержка пользователей → Использование signtool c Рутокен ЭЦП 3.0 с не экспортируемым сертифика
Страницы Назад 1 2 3 4 … 13 Далее
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Попробуйте следующий алгоритм:
1. Открываем панель управления Рутокен, вкладка сертификаты. Снимаем галку регистрации сертификата.
2. Проверяем что в разделе криптопровайдер по-умолчанию стоит именно Aktiv CSP.
3. Отключаем токен.
4. Перезагружаем компьютер.
5. Подключаем токен.
6. В панели управления рутокен на вкладке сертификаты проверяем через какой криптопровайдер зарегистрирован сертификат.
Спасибо. Теперь всё заработало.
"Веселье" продолжается.
signtool при подписании digest-файла снова вываливает пинкод.
Т.е. настройки для запоминания пинкода сделал, при обычном подписании signtool работает как часы.
Но чтобы исключить передачу больших файлов пытаюсь реализовать подписания digest-файла.
Для этого экспортировал сертификат (публичную часть) в файл.
Генерирую digest
signtool sign /v /f exported.cer /fd SHA256 /dg . some.exe
Пытаюсь подписать сформированный dig файл
signtool sign /v /a /fd SHA256 /ds some.exe.dig - получаю ошибку "The specified private key container was not found"
signtool sign /v /f exported.cer /csp "Aktiv ruToken CSP v1.0" /k "имя контейнера" /fd SHA256 /ds some.exe.dig - опять ошибка "The specified private key container was not found"
signtool sign /v /f exported.cer /fd SHA256 /ds some.exe.dig - вот эта штука работает, но вылезает окно "Windows Security => Smart Card" с вводом пин-кода, т.е. будто он снова игнорирует установленный для токена криптопровайдер.
Это каким-то образом решается?
p.nick, попробуйте указать опцию /sha1 <отпечаток сертификата> вместо /csp "Aktiv ruToken CSP v1.0" /k "имя контейнера"
Это и ещё ряд других вариантов пробовал.
Если указать экспортированный сертификат и sha1:
signtool sign /a /v /f exported.cer /fd SHA256 /td SHA256 /sha1 XXX /ds some.exe.dig - запрашивает пин (Windows Security). Т.е. приватный ключ находит, но просит пин. При вводе пина - все подписывает
Если вообще не указывать экспортированные сертификат, но указать sha1:
signtool sign /a /v /fd SHA256 /td SHA256 /sha1 XXX /ds some.exe.dig - The specified private key container was not found.
Как я понимаю, решения нет, и про подписании dig-файла игнорирует выбранный провайдер, используя стандартный виндовый с вводом пин-кода?
Дополнительно проверил при подписании в режиме debug
signtool sign /v /debug /f test.cer /fd SHA256 /ds test.exe.dig
The following certificates were considered:
Issued to: ****
Issued by: GlobalSign GCC R45 CodeSigning CA 2020
Expires: Thu Dec 26 12:18:17 2024
SHA1 hash: ****
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
Issued to: ****
Issued by: GlobalSign GCC R45 CodeSigning CA 2020
Expires: Thu Dec 26 12:18:17 2024
SHA1 hash: ****
Done Adding Additional Store
SignTool Error: The specified private key container was not found.
SHA1 hash и все остальные поле в блоке "considered" и в блоке "selected" совпадают полностью. Т.е. signtool никак не может найти приватный ключ.
В итоге проблему не смог решить стандартными средствами.
Пришлось сделать свою реализацию подписания хеша (но оказалось даже удобнее для конкретных моих потребностей).
p.nick, отправил.
Добрый день. Возникла та же проблема: куплен сертификат GlobalSign на Рутокен носителе, стоит задача встроить его на сервер CI/CD. Если есть решение, просьба сообщить в личку либо здесь.
ivchpavel, в личку тут писать нельзя (кроме админов видимо).
Готового решения нет, есть самописная реализация конкретно под мои задачи.
Но если в общем, то процесс такой:
1. Экспортируем публичный ключ с токена
2. Генерируем *.dig файл для подписанного бинарника на машине, где нет токен (но должен быть файл, например my.cer с публичной экспортированной подписью):
signtool sign /v /f my.cer /fd SHA256 /dg . "my.exe"
3. Подписываем данные из dig-файла. В нём просто просто хеш, закодированный, в base64. Подписывать можно любым "внешним" софтом. Надо только понимать, что кому-то на вход нужны бинарные данные, а не base-64 (тогда его надо будет раскодировать).
4. Подписанные данные также сохраняем в base64 в файл my.exe.dig.signed и помещаем в папку рядом с основным и dig файлом.
5. Добавляем подпись в файл
signtool sign /di . "my.exe"
6. Ну и добавляем timestamp
signtool timestamp /tr http://timestamp.globalsign.com/tsa/r6advanced1 /td SHA256 "my.exe"
Всё что выше "my" - надо заменить на свои значение (в одном случае - свой сертификат, во втором - свой подписываемый файл).
Подписание msix в таком случае не работает - там процесс сложнее (но его тоже удалось решить).
По указанному выше принципу у меня был реализован свой веб-сервер с физическим токеном, который принимает base64 текст, подписывает его и отправляет обратно. А в ci/cd уже вся работа с signtool по генерации dig-файлов и добавлению итоговой подписи.
Есть более простой вариант, но более накладный с точки зрения сетки - можно просто передавать полностью бинарный файл и подписывать через signtool непосредственно на машине с физическим токеном (инструкцию, как в данном случае запомнить пин, можно запросить у Аверченко Кирилла, он направляет её на почту).
p.nick, спасибо за развернутый ответ. Я думаю многим пригодится. Вроде решение работает, по крайней мере на локальной машине, еще буду тестировать с сервером.
Некоторые детали:
- на шаге 2 после генерации dig файла, сам "my.exe" тоже становится подписанным, но как-то криво.
- на 3 шаге у меня команда signtool sign /v /sha1 <хэш SHA1 сертификата> /fd SHA256 /ds my.exe.dig
т.е. явно задаю нужный сертификат, т.к. /a находит не тот ( у меня на компе есть тестовый сертификат)
- на 3 шаге получается файл my.exe.dig.signed и если все действия в этой папке, то 4 шаг не нужен
- с последней версией Win 11 SDK команда "signtool sign /di . "my.exe"" не проходит, идет ошибка "SignTool Error: No file digest algorithm specified. Please specify the digest algorithm with the /fd flag. Using /fd SHA256 is recommended and more secure than SHA1. ..." Если же задать /fd, то идет другая ошибка "SignTool Error: The /di option is incompatible with the /fd option." Все логично :) Спасает новый ключ /fdws, т.е. команда
signtool sign /fdws /di . my.exe
- таймштамп приходится выполнять отдельной командой (шаг 6). не получается как раньше засунуть /tr сразу при подписании файла.
Вариант с копированием файла инстолера на машину с токеном и обратно, выглядит более сложным в практическом применении. Только если вариант где токен воткнут в сам сервер, гдеразвернута виртуака с CI/CD, но и там надо пробрасывать в виртуалку устройство. Но как запасной вариант хотелось бы иметь и этот путь.
Коллеги,
кто пробовал включить подписывание кода новым сертификатом (SignCode на рутокене) в pipeline на Jenkins?
У нас Jenkins, среди прочего, собирает VS Solution.
В моих экспериментах пока так: если открыть Visual Studio и сказать ему build solution. все пройдет хорошо, включая подписыванием всех EXE, DLL и MSI без ввода PIN.
Но когда тот же самый solution собирается из-под Jenkins, signtool сообщает, что сертификат для подписывания кода не найден.
Что не так, и есть ли решение?
Здравствуйте SimonDubitsky, у нас есть несколько обращений с подобной проблемой, но к сожалению решения у нас нет.
Здравствуйте, на вкладке Сертификаты указан Microsoft Base Smart Card Crypto Provider.
Подскажите, пожалуйста, как сменить на Aktiv ruToken CSP v1.0
Cпасибо.
Здравствуйте, admin, выполните следующее:
1. Уберите галочку "Зарегистрировано" на сертификате
2. Отключите токен от компьютера.
3. Перезагрузите компьютер.
4. Подключите токен и на вкладке Сертификаты проверить что галочка Зарегистрировано установлена.
Если нет, то установите и проверьте, что сертификат зарегистрирован через Aktiv Rutoken CSP.
Страницы Назад 1 2 3 4 … 13 Далее
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Техническая поддержка пользователей → Использование signtool c Рутокен ЭЦП 3.0 с не экспортируемым сертифика
