Ошибка инициализации провайдера скзи тэк торг

parihaaraka	#1 Оставлено : 2 августа 2018 г. 12:29:57(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз	Здравствуйте. Речь о проверке подписи с использованием сертификата без закрытого ключа и, соответственно, контейнера ключей (т.е. CryptAcquireCertificatePrivateKey, возвращающий дескриптор правильного провайдера, не работает). Нужно вызывать CryptImportPublicKeyInfo, где уже указывается провайдер + считать хеш с его использованием. Как в таком случае правильно выбрать тип провайдера и указать правильные ALG_ID, алгоритм хэширования и параметры? Сейчас существует некая непроверенная логика (поскольку новый гост пока не используется) вроде: Код: if (pubKeyAlgo == "1.2.643.2.2.19") setParams(CALG_GR3411, szOID_CP_GOST_R3411, szOID_GostR3411_94_CryptoProParamSet); else if (pubKeyAlgo == "1.2.643.7.1.1.1.1") setParams(CALG_GR3411_2012_256, szOID_CP_GOST_R3411_12_256, ""); else if (pubKeyAlgo == "1.2.643.7.1.1.1.2") setParams(CALG_GR3411_2012_512, szOID_CP_GOST_R3411_12_512, ""); (аналогично выбирается тип открываемого провайдера — 75, 80 и 81 соответственно), но что-то терзают сомнения, правильно ли так делать. С параметрами хеширования вообще непонятно. То их нужно указывать функцией CryptSetHashParam, то не нужно, то явное указание вообще всё ломает (для 80 и 81 провайдера). Пожалуйста, проясните взаимосвязи. Спасибо.

Максим Коллегин	#2 Оставлено : 2 августа 2018 г. 12:51:21(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,253 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	У Стрибога нет параметров — указывать их не нужно. Мы сознательно возвращаем ошибку при их установке, чтобы пользователи задумались над тем, что делают. Провайдер для проверки подписи можно указывать любой из 758081. Конкретный выбор криптопровайдера важен только для генерации ключа.
Знания в базе знаний, поддержка в техподдержке
	WWW

parihaaraka	#3 Оставлено : 2 августа 2018 г. 13:21:58(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз	Для кодированной подписи CryptVerifyDetachedMessageSignature не предполагает указание провайдера. А если подпись не кодированная, то любой провайдер не подойдет, поскольку нужно посчитать правильно хеш для CryptVerifySignature, а дефолтные алгоритмы у провайдеров разные. Опять же, в CryptCreateHash необходимо указывать (знать) ALG_ID (откуда?). А из знания ALG_ID следует знание о том, нужно ли уточнять параметры хеша. Причем непонятно, как это последнее знание обобщить (хотя бы в контексте гостовых алгоритмов). И то, если бы оно было.. или если бы можно было получить возможные параметры какими-то функциями апи, чтобы понять, существуют вариации настроек или нет. В минимуме хотелось бы узнать правильный способ определения ALG_ID при вызове CryptVerifySignature и oid алгоритма хеширования для инициализации CRYPT_SIGN_MESSAGE_PARA.

Максим Коллегин	#4 Оставлено : 3 августа 2018 г. 0:06:59(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,253 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	Так правильный способ и описан в первом сообщении. Любой провайдер из трёх перечисленных.
Знания в базе знаний, поддержка в техподдержке
	WWW

parihaaraka	#5 Оставлено : 3 августа 2018 г. 9:44:00(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз	То есть нет никаких более очевидных способов создать объект хеширования (для проверки подписи, т.е. в контексте сертификата), кроме как проанализировать алгоритм открытого ключа и выбрать подходящий ALG_ID самостоятельно вот такой условной логикой?! А если у алгоритма хеширования могут быть различные настройки, то как определять их, чтобы сгенерировать хеш так же, как подписант?

Максим Коллегин	#6 Оставлено : 3 августа 2018 г. 12:18:29(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,253 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	Если известен алгоритм подписи, то нужно использовать конечно же его. Если указаны алгоритм и параметры хэширования — то задавать. Вы же не пишете, про какой формат подписи идёт речь.
Знания в базе знаний, поддержка в техподдержке
	WWW

two_oceans	#7 Оставлено : 3 августа 2018 г. 13:27:15(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,598 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 388 раз в 363 постах	Автор: parihaaraka А если у алгоритма хеширования могут быть различные настройки, то как определять их, чтобы сгенерировать хеш так же, как подписант? В сертификате рядом с информацией об открытом ключе также указываются 3 ОИДа, ОИД параметров алгоритма хэширования среди них. По нему однозначно определяются и алгоритм и парамсет. Его нужно читать и если не совпадает с параметром по умолчанию (текущий параметр получается по hp_oid), то устанавливать явным образом. Кроме того, параметры хэширования могут быть переданы и без сертификата. Например, в подписи xml предусмотрен такой способ. В стандарте xmldsig под тегами Digest и SignatureMethod могут быть указаны дополнительные теги с оидами параметров, в том числе хэширования. Если дополнительные теги не указаны, то алгоритм определяется по атрибуту Algorithm и используются параметры по умолчанию, прописанные в стандарте. Правда, раскопать мне это удалось только в просроченном черновике RFC. Интересно, есть ли действующий стандарт, поправляющий xmldsig под ГОСТ? Возможность указания отдельно связана с тем, что в xmldsig возможно передавать ключи (ключи ГОСТ в том числе) вместо сертификата. Практически, пока мне ни разу не пришлось менять параметры хэширования — для гост-2001 (точнее 34.11-94) парараметры КриптоПро стали фактическим стандартом и менять просто нет необходимости (но на всякий случай проверяю). Хэш гост-2012 еще плотно не тестировал, но по вышесказанному — используется без параметров. К слову, если хотите сделать программу универсальной, не привязанной к КриптоПро CSP 4.0, то учтите, что для 34.11-94 alg_id у других криптопровайдеров более-менее совпадают (проверял на типе 90), но на гост-2012 alg_id совсем другие.
1 пользователь поблагодарил two_oceans за этот пост.	parihaaraka оставлено 03.08.2018(UTC)

parihaaraka	#8 Оставлено : 3 августа 2018 г. 13:54:34(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз	> Если указаны алгоритм и параметры хэширования Они не указаны. Всё, что есть — сертификат. Я ведь написал выше. Простой пример — СМЭВ. Получили soap-конверт, достали запчасти: сертификат, хеши, знания о том, что именно подписано, и сами подписи. Подписи там не кодированные (внутри не asn.1). Обычная реализация проверки подписей предполагает вписанные прямо в коде алгоритмы и настройки хеша. Но если бы это была часть разнообразного трафика, где заранее в документации не прописаны алгоритмы, то какая должна быть логика проверки? Если предполагать возможность существования любых подписей любыми ключами? Хочется написать обобщенное решение, которое смогло бы работать и при смене ГОСТа, и, как вариант, при использовании не ГОСТа (хотя вроде и не надо…). Т.е. есть сертификат подписанта с открытым ключом — и всё. Нужно сделать хеши и сверить с имеющимися (помимо проверки подписи). Смотрим на открытый ключ (без тела): OBJECT IDENTIFIER 1.2.643.2.2.19 gostPublicKey(GOST R 34.10-2001 (ECC) public key) SEQUENCE(2 elem) OBJECT IDENTIFIER 1.2.643.2.2.36.0 cryptoProSignXA(CryptoPro ell.curve XA for GOST R 34.11-2001) OBJECT IDENTIFIER 1.2.643.2.2.30.1 cryptoProDigestA(CryptoPro digest params for GOST R 34.11-94) или OBJECT IDENTIFIER 1.2.643.7.1.1.1.2 SEQUENCE(2 elem) OBJECT IDENTIFIER 1.2.643.7.1.2.1.2.1 OBJECT IDENTIFIER 1.2.643.7.1.1.2.3 Здесь мы имеем готовые параметры для функции CryptSetHashParam, НО, как выяснилось, иногда эти параметры запрещено использовать. Это раз. А еще нужен ALG_ID в CryptCreateHash. Как на него выйти? *И почему-то только для формирования кодированной подписи нужен алгоритм хеширования в CRYPT_SIGN_MESSAGE_PARA. Как выйти на него? Понятно, что можно собрать информацию и втупую прописать зависимости (как в первом посте), но неужели это и есть правильный путь? Вопрос именно в этом.

Максим Коллегин	#9 Оставлено : 3 августа 2018 г. 15:53:17(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,253 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	В СМЭВ (xmldsig) указаны все алгоритмы хэширования в uri. А использование нестандартных узлов замены для хэша — уникальная ситуация и не думаю, что Вы с ней столкнётесь.
Знания в базе знаний, поддержка в техподдержке
	WWW

parihaaraka	#10 Оставлено : 3 августа 2018 г. 16:40:16(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз	В uri алгоритмы указаны, но использовать их можно только таким же перебором, как в первом посте. Есть ли смысл указывать их, если можно определять эти настройки по алгоритму открытого ключа? Или, все же, это может не сработать (а значит, и вся первоначальная идея)? *Непонятно, почему есть отдельно ALG_ID и алгоритм в виде oid для CRYPT_SIGN_MESSAGE_PARA. Почему по-разному задается способ хеширования?

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Ошибка (sun.security.pkcs11.wrapper.PKCS11Exception CKR_FUNCTION_FAILED)Ошибка создания ключевой пары (0X3)

Если библиотеки установлены, но ошибка остается – необходимо произвести следующие настройки Internet Explorer:

     1. Добавить адреса ЭТП в Надежные узлы.

• в Internet Explorer «Сервис» — «Свойства обозревателя» — вкладка «Безопасность»;
• выделить «Надежные узлы» («Надежные сайты»); — кнопка «Узлы» («Сайты»);
• убрать внизу флаг «Для всех узлов этой зоны требуется проверка серверов (https:)» (не все ЭТП работают по защищенному соединению https://);
• в строку «Добавить в зону следующий узел» ввести адрес ЭТП (по http и https); кнопка «Добавить».

     2. Для зоны «Надежные узлы» («Надежные сайты») разрешить использование элементов Active-X.

• в Internet Explorer «Сервис» – «Свойства обозревателя» — вкладка «Безопасность»; выделить «Надежные узлы» («Надежные сайты»); нажать кнопку «Другой…»;
• в разделе «Элементы Active-X и модули подключения» у всех параметров отметить «Включить» (для IE 6 – «Разрешить»).

     3. Установить и зарегистрировать библиотеку capicom.dll.

• скачайте файл capicom.dll
• скопируйте файл capicom.dll в папку  C:WINDOWSsystem32 (для Windows XP, Vista, Win7 — C:WINDOWSsystem32regsvr32);
• нажмите кнопку «Пуск» и выберите «Выполнить»;
• в окне «Запуск программы» в поле «Открыть» наберите или скопируйте: для Windows XP, Vista, Win7 — C:WINDOWSsystem32regsvr32 capicom.dll нажмите кнопку «ОК».
• Регистрация библиотек может быть запрещена локальной политикой прав доступа. В таком случае, нужно обращаться к системному администратору.

     4. Проверить статус сертификата

• зайдите в «Панель управления Рутокен» — вкладка «Сертификаты»
• выделите сертификат — статус сертификата должен быть «Действителен»
• возможны ошибки: «Сертификат ненадежен»/»Не удалось проверить статус отзыва» или «Не установлен корневой сертификат. Просмотреть | Установить», выполните решение из инструкции.

     5. Проверить права на библиотеку capicom.dll

• откройте каталог C:WindowsSystem32,
• найдите capicom.dll,
• правой кнопкой мыши «Свойства» — вкладка «Безопасность» — «Дополнительно» — «Изменить разрешения».
• в списке найти текущего пользователя компьютера, проверить, какой статус стоит в колонке «Разрешения». Если отличный от «Полный доступ» — выделить строку, нажать «Изменить». Поставить галку «Полный доступ», сохранить.

Если при сохранении выйдет сообщение о нехватке прав — перейти на вкладку «Владелец», Изменить, выбрать текущего пользователя компьютера, попробовать заново назначить «Полный доступ».

     6. Как правило, для участия в торгах необходимо пользоваться браузером Internet Explorer версии 6.0 и выше. В IE 9 и выше могут возникать ошибки, которые можно решить, воспользовавшись режимом совместимости («Свойства браузера» — «Сервис» — «Параметры режима представления совместимости» — добавить адрес площадки.

Это общие настройки для всех ЭТП. На некоторых площадках необходимо установить дополнительные компоненты, необходимые для корректной работы.

Остались вопросы? 

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

Поставщик служб криптографии Windows сообщил об ошибке. Указан неверный тип провайдера, неверная подпись, нарушена защита, код 2148073504 или набор ключей не существует

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

Поставщик криптографических услуг сообщил об ошибке

Согласно Microsoft, поставщик криптографических услуг (CSP) содержит реализации криптографических стандартов и алгоритмов. Как минимум, CSP состоит из библиотеки динамической компоновки (DLL), которая реализует функции в CryptoSPI (интерфейс системной программы). Поставщики реализуют криптографические алгоритмы, генерируют ключи, обеспечивают хранение ключей и аутентифицируют пользователей.

Если вы столкнулись с ошибками, вот несколько вещей, которые вы можете попробовать:

1] Запустите services.msc и перезапустите службу шифрования Windows.

2] Откройте Internet Explorer> Сервис> Свойства обозревателя. Выберите вкладку «Содержимое» и нажмите «Сертификаты». Проверьте, есть ли сертификат для программы или провайдера, выдающего ошибки. Если он отсутствует, вам придется создать новый. Если срок его действия истек, удалите его и создайте новый. Если определенный сертификат не работает, выберите другой сертификат и удалите старые сертификаты.

5] Переустановите все хранилище сертификатов и пользовательские сертификаты.

6] Если в вашей системе установлено приложение SafeNet Authentication Client Tool , откройте его, перейдя в каталог установки или щелкнув правой кнопкой мыши значок SafeNet на панели задач и выбрав в меню «Инструменты».

Нажмите значок в виде шестеренки, чтобы открыть раздел «Расширенный вид». В разделе Advanced View разверните токены и перейдите к сертификату, который вы хотите использовать для подписи. Вы можете найти их в группе сертификатов пользователей.

Затем щелкните правой кнопкой мыши свой сертификат и выберите «Установить как CSP» из выпадающего меню. Повторите тот же шаг для всех сертификатов, которые вы используете.

Закройте клиентские инструменты аутентификации SafeNet и попробуйте снова подписать документы.

7] Создайте папку локального хранилища Microsoft Cryptography. Перейдите в папку C: ProgramData Microsoft Crypto RSA . Переименуйте папку с надписью S-1-5-18. Перезагрузите систему и посмотрите, поможет ли это.

8] Если у вас установлено программное обеспечение ePass2003 , причиной проблемы может быть электронный токен ePass2003. Желательно сначала удалить его и переустановить. Для этого перейдите в раздел «Настройки» инструмента, перейдите в «Приложения и функции» и удалите его, как и любое другое приложение.

Перезагрузите компьютер и установите ePass2003 снова. Во время переустановки убедитесь, что вы выбрали MicroSoft CSP при выборе опции CSP. Все должно вернуться к нормальной жизни, и ошибка поставщика служб криптографии Windows больше не должна появляться.

Всего наилучшего!

Связанное чтение . Службы Windows не запускаются.

При использовании КриптоПро ЭЦП Browser plug-in могут возникать ошибки, приводящие к тому, что плагин не работает или работает некорректно, из-за чего электронная подпись не создаётся. Рассмотрим наиболее распространённые варианты ошибок и разберёмся, как их устранить.

При проверке отображается статус «Плагин загружен», но нет информации о криптопровайдере

Это значит, что криптопровайдер КриптоПро CSP не установлен. Необходимо загрузить дистрибутив программы с сайта разработчика и установить её на компьютер. В настройках плагина в графу Список доверенных узлов также следует добавить адрес ресурса, с которым работаете (например, nalog.ru).

Не удаётся построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)

При этой ошибке плагин не может сформировать запрос на создание ЭЦП. Она возникает, если по каким-то причинам нет возможности проверить статус сертификата. Например, если нет привязки к ключу или доступа к спискам отзыва. Также проблема может воспроизводиться, если не установлены корневые сертификаты.

Для устранения этой ошибки нужно привязать сертификат к закрытому ключу.

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

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

Для установки корневого сертификата необходимо:

• Кликнуть правой кнопкой мыши по файлу.
• В контекстном меню выбрать пункт Установить сертификат.
• После запуска Мастера установки нажать Далее.
• Выбрать вариант Поместить все сертификаты в выбранной хранилище и нажать Обзор.
• Выбрать в списке хранилищ Доверенные корневые центры сертификации, нажать ОК, затем Далее.
• Нажать Готово.

Установка промежуточных сертификатов выполняется точно так же, как и установка корневых, за исключением того, что в процессе установки вместо пункта Доверенные корневые центры сертификации нужно выбрать пункт Промежуточные центры сертификации.

ЭЦП создаётся с ошибкой при проверке цепочки сертификатов

Данная проблема возникает из-за отсутствия доступа к спискам отозванных сертификатов. Списки должны быть доступны для загрузки на сайте удостоверяющего центра, который выпустил сертификат ЭЦП. Установка списков выполняется по той же схеме, что и установка промежуточного сертификата.

Ошибка несоответствия версии плагина

При проверке возникает сообщение «Установлен и настроен плагин для браузера КриптоПро ЭЦП Browser plug-in версии 2.0.12438 и выше. — undefined». В этом случае необходимо установить плагин версии 2.0.12438 и выше.

Появляется сообщение «Плагин недоступен»

Данная проблема может возникнуть, если ваш браузер не поддерживает установленную версию плагина. Попробуйте воспользоваться другим обозревателем.

Ошибки 0x8007064A и 0x8007065B

Ошибка возникает в связи с окончанием срока действия лицензий на КриптоПро CSP (КриптоПро TSP Client 2.0, Криптопро OCSP Client 2.0).

Чтобы создать электронную подпись с форматом CAdES-BES, необходима действующая лицензия на КриптоПро CSP. Создание ЭЦП с форматом CAdES-X Long Type 1 потребует наличия действующих лицензий:

• КриптоПро CSP;
• КриптоПро OCSP Client 2.0;
• КриптоПро TSP Client 2.0.

После приобретения лицензии потребуется её активация.

Набор ключей не существует (0x80090016)

Возникает из-за того, что у браузера нет прав для выполнения операции. Для решения проблемы в настройках плагина добавьте сайт в Список доверенных узлов.

Отказано в доступе (0x80090010)

Возникает в связи с истечением срока действия закрытого ключа. Чтобы проверить срок действия, запустите Крипто-Про CSP, затем откройте вкладку Сервис. Далее необходимо выбрать пункт Протестировать и указать контейнер с закрытым ключом. Если в результатах тестирования вы увидите, что срок действия закрытого ключа истёк, необходимо получить новый ключ.

Ошибка: Invalid algorithm specified. (0x80090008)

Появление такой ошибки означает, что криптопровайдер не поддерживает алгоритм используемого сертификата. Рекомендуется проверить актуальность версии КриптоПро CSP.

Если предлагаемые выше способы устранения ошибок не помогут, рекомендуем обратиться в службу поддержки КриптоПро.

У вас ещё нет электронной подписи? Её можно заказать у нас на сайте. Выберите подходящий вариант ЭЦП: для участия в электронных торгах, работы с порталами или отчётности. Процедура оформления не займёт больше одного дня.

Модераторы: Alekoion, santyago