Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.01.2013(UTC) Сообщений: 32 Откуда: Москва Сказал «Спасибо»: 2 раз
|
Автор: alexl Из ваших комментариев непонятно - что и в какой конфигурации у вас работает, а что - нет? Работает ли ваша служба (именно служба) с использованием криптопровайдера "Crypto-Pro HSM Svc CSP" и обычных вызовов CryptoAPI (CryptAcquireCertificatePrivateKey() CryptCreateHash() CryptHashData() CryptSignHash())? Или для проверки вы написали обычное приложение (не службу)? Наша служба подписывает данные 2 способами: 1. с помощью вызова CryptSignHash 2. с помощью вызова CryptSignMessage. Очень удобно, что эта функция сама еще и заворачивает данные в PKCS#7-envelope. При этом используется сертификат, ключевой контейнер к которому установлен в провайдере "Crypto-Pro HSM Svc CSP". Явно этот провайдер я нигде не задаю (см. код выше в одном их моих постов), получаю его хэндл по сертификату с помощью вызова CryptAcquireCertificatePrivateKey. А в случае с CryptSignMessage даже этого делать не требуется. Так вот с CryptSignHash проблем нет, а ошибка при вызове CryptSignMesage послужила поводом для создания этой темы. Вчера вот этот комментарий Автор: maxdm А не в службе код работает? сподвиг меня на написание тестовой утилиты командной строки, которая подписывает данные с помощью CryptSignMesage. Как выяснилось, не из службы код работает. Что только порождает новый вопрос: почему не работает из службы? Автор: alexl Может Вам помогут выдержки из документации:
"Криптопровайдер “Crypto-Pro HSM Svc CSP” (тип 75) отличается от криптопровайдера «Crypto-Pro HSM CSP» только тем, что позволяет выводить запросы на ввод пин-кодов для ключей пользователей не на «рабочий стол» рабочей станции пользователя, а на LCD панель ПАКМ. Кроме этого он позволяет организовать обмен между сервером и ПАКМ по более производительному нешифрованному каналу, при условии осуществления однозначной двусторонней аутентификации «сервер<->ПАКМ», нахождении сервера и ПАКМ в одной контролируемой зоне и условии, что используется специальный сертификат ключа доступа, включающий расширение (extended key usage - EKU) «1.2.643.2.2.34.22». Данный криптопровайдер используется в основном в серверных конфигурациях серверами приложений, работающими в фоновом режиме и не имеющими консоли для вывода сообщений и/или запроса пин-кодов. Он реализован в виде отдельного сервиса ОС Windows, запускаемого при загрузке ОС. "
"Кроме этого, обращения к криптопровайдерам, работающим с ПАКМ через сервис, в данном случае - «Crypto-Pro HSM Svc CSP» и «Crypto-Pro HSM RSA Svc CSP», могут быть сделаны только пользователями с учетными именами SYSTEM (LocalSystem), NetworkService, пользователями, входящими в группу локальных администраторов компьютера или в группу «Привилегированные пользователи КриптоПро HSM». Группу «Привилегированных пользователей КриптоПро HSM» можно создать вручную и добавить туда, например, учетные имена, под которыми исполняются сервисные приложения (например, пул приложений .NET под управлением Microsoft IIS). Эти же правила действуют при обращении пользователей к любым криптопровайдерам ПАКМ через системный трей, при использовании специального флага в вызовах интерфейса CryptoAPI - CRYPT_MACHINE_KEYSET."
"Администраторам серверов, рекомендуется установить для провайдера 75 типа криптопровайдером по-умолчанию «Crypto-Pro HSM Svc CSP», т.к. некоторые вызовы сервисы Windows делают, используя провайдеры «по умолчанию»."
т.е. для работы с криптопровайдером "... Svc..." нужно в HSM зарегистрировать пользователя с признаком, не помню, точно как он значится, "пользователь-Компьютер" (в Web интерфейсе) или "Is Computer?" в интерфейсе LCD панели. И сформировать для него как обычно ключи и сертификат доступа. В сертификате будет расширение "Администратор сервера" (то, что упомянуто выше - «1.2.643.2.2.34.22»). Плюс ваша служба должна работать под учетной записью, удовлетворяющей вышеописанным условиям.
Наша служба работает под учетной записью LocalSystem. Мы не являемся владельцами HSM, поэтому регистрировать/создавать на нем ничего не можем. Насколько я понимаю, он настроен согласно документации, большая часть функционала нашего решения отрабатывает корректно. Проблема только с вызовом CryptSignMessage. Только мне до сих пор не ясно, чем так принципиально отличаются вызовы CryptSignHash и CryptoSignMessage? Буду очень признателен за разъяснения, или хотя бы какой-нибудь workaround
|