Форум КриптоПро
»
Устаревшие продукты
»
КриптоПро CSP 3.9
»
проверка контейнера ошибка 0x80090006 (-2146893818) Неправильная подпись
IgorDID |
|
|
Статус: Участник Группы: Участники Поблагодарили: 1 раз в 1 постах |
Подскажите, в чем проблема с контейнером? выдает крипто-про 3.9 при тестировании контейнера: Проверка завершилась с ошибкой Контейнер закрытого ключа имя 4IPF5KOX5KO3JIK4 уникальное имя FAT12318D2DE8_VTB4IPF5KOX.000175F FQCN \.FAT12_F4IPF5KOX5KO3JIK4 проверка целостности контейнера успешно Ключ обмена доступен экспорт открытого ключа успешно импорт открытого ключа успешно подпись успешно проверка Ошибка 0x80090006 (-2146893818) Неправильная подпись. создание ключа обмена успешно экспорт ключа разрешен алгоритм ГОСТ Р 34.10-2001 DH ГОСТ Р 34.10-2001, параметры обмена по умолчанию ГОСТ Р 34.11-94, параметры по умолчанию сертификат в контейнере соответствует закрытому ключу сертификат в хранилище My ИНН=00хххххххххх, C=RU, L=хххххххххх, S=42 ххххххххххххх, E=хххх@хххх.ru, O=»ххххххххх», T=ххххххххх, CN=ххххххххх, SN=хххххх, G=хххххххх, STREET=»ххххххххх», ОГРН=хххххххххх, СНИЛС=ххххххххх FAT12318D2DE8_VTB4IPF5KOX.000175F; Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider#75; dwFlags: 0x00000000; dwKeySpec: 1 имя сертификата Тимошенко Михаил Анатольевич субъект ИНН=00хххххххххх, C=RU, L=хххххххххх, S=42 ххххххххххххх, E=хххх@хххх.ru, O=»ххххххххх», T=ххххххххх, CN=ххххххххх, SN=хххххх, G=хххххххх, STREET=»ххххххххх», ОГРН=хххххххххх, СНИЛС=ххххххххх поставщик ИНН=000000000000, C=RU, L=xxxxxxxxxx, S=42 xxxxxxxx, E=xx@xxxxx.ru, O=»xxxxxx», OU=Удостоверяющий центр, CN=xxxxxxxxx, STREET=»xxxxxxxxx», ОГРН=xxxxxx действителен с 16 июня 2015 г. 15:50:42 действителен по 25 мая 2016 г. 15:50:42 серийный номер 0201 0B02 1B74 0101 0221 AD Ключ подписи отсутствует загрузка ключей успешно |
 |
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Очень интересно. Похоже на то, что сертификат от другого контейнера. А другие контейнеры пробовали? |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
IgorDID |
|
|
Статус: Участник Группы: Участники Поблагодарили: 1 раз в 1 постах |
К сожалению подробностей получить не удалось. Подскажите, что в теории могло вызвать данные симптомы ? |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Пока только предположения, точных диагнозов нет. |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
Столкнулись с такой же проблемой: ключ работал. Сейчас при тестировании в 3.6.7777 выдает ошибку Ошибка 0x80090006. Проверка завершилась с ошибкой контейнер один на рутокене. в панели управления рутокена эп просматривается, цепь сертификатов строится. драйвера рутокена последние. Помогите, пожалуйста, разобраться. |
|
|
|
Screenshot_9.png |
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
Также добавлю, что проверяли привязанность открытой части к контейнеру (в крипто про автоматически определился для этой открытой части именно этот контейнер). |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере. |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
Автор: maxdm Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере. В 4.0 ошибка повторилась. Это говорит о том, что контейнер поврежден? |
|
|
|
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
И снова столкнулись с такой проблемой у другого клиента. Т.е.. таких уже как минимум 3: пользовались-пользовались, вдруг такая ошибка. |
|
|
|
|
Русев Андрей |
|
|
Статус: Сотрудник Группы: Администраторы, Участники Сказал(а) «Спасибо»: 10 раз |
Пришлите, пожалуйста, что выдаёт команда: Код: |
|
Официальная техподдержка. Официальная база знаний. |
|
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Форум КриптоПро
»
Устаревшие продукты
»
КриптоПро CSP 3.9
»
проверка контейнера ошибка 0x80090006 (-2146893818) Неправильная подпись
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
When copying files from Windows Server 2019 to a Windows 10 client, I get the following error:
error 0x80090006 «Invalid signature»
The data set I have been working with is about 50 GB of data, many of these files are ~500 MB each in size.
This likely happens with other data sets, but this was the first large transfer that I can reliably recreate the issue with on every attempt.
I have done many tests copying this same data set:
- From the server in question to my Windows 10 workstation
- To the server in question from my Windows 10 workstation
- From the server in question to another Windows 2016 server
- From the Windows 2016 server to my Windows 10 workstation
The only time I see this error is the first scenario (Windows 2019 > Windows 10).
Sometimes this error occurs within the first few seconds of my data copy, other times it doesn’t occur until 85%-90% of the data has transferred. Often it occurs multiple times (as much as 10-15) during the whole transfer. In testing this close
to 20 times it has produced this error at least once on transfer of this data set *every single time*.
The error seems recoverable. If I click «Try Again» the data appears to copy correctly, although I may receive the error again on the same file later in the copy or on another file later in the transfer. It seems completely random when
it occurs, but does appear to be happening more on the larger files.
I have researched this error and have found several references to it being possibly caused by Symantec products or VMWare/ESX network adapters. Neither of those is relevant in my case. I also saw some reference so UNC path issues, which let me
to research UNC path hardening. This led me down the path of investigating the SMB connection. What I have determined is this issue
does not occur when using SMB3 encryption.
I believe this is because when using SMB3 encryption, signing is disabled as per
this article:
When requiring SMB Encryption, SMB Signing is not used, regardless of settings. SMB Encryption implicitly provides the same integrity
guarantees as SMB Signing
Using UNC Path Hardening and setting RequirePrivacy=1, I am able to turn on SMB3 encryption on the share from the client and the issue goes away. However I do not wish to be required to use SMB encryption and should not have to in order to deal with
what is clearly a signing error. I have also attempted to turn of SMB 3.1.1 signing, but I have been unsuccessful in doing that (I detail that issue
here).
I should not however even have to disable SMB signing as this error should simply not be happening for a core function like file copy between two windows systems.
This appears to be the same issued outlined here:
https://support.microsoft.com/en-in/help/2686098/system-error-2148073478-extended-error-or-invalid-signature-error-mess
That still exists years later. That MS article however discusses issues between 3rd party products, not 2 modern Microsoft OSes.
Additionally, the workaround of disabling Secure Negotiate does not seem to work for Server 2019 and/or Windows 10 (again I detail that issue
here).
When copying files from Windows Server 2019 to a Windows 10 client, I get the following error:
error 0x80090006 «Invalid signature»
The data set I have been working with is about 50 GB of data, many of these files are ~500 MB each in size.
This likely happens with other data sets, but this was the first large transfer that I can reliably recreate the issue with on every attempt.
I have done many tests copying this same data set:
- From the server in question to my Windows 10 workstation
- To the server in question from my Windows 10 workstation
- From the server in question to another Windows 2016 server
- From the Windows 2016 server to my Windows 10 workstation
The only time I see this error is the first scenario (Windows 2019 > Windows 10).
Sometimes this error occurs within the first few seconds of my data copy, other times it doesn’t occur until 85%-90% of the data has transferred. Often it occurs multiple times (as much as 10-15) during the whole transfer. In testing this close
to 20 times it has produced this error at least once on transfer of this data set *every single time*.
The error seems recoverable. If I click «Try Again» the data appears to copy correctly, although I may receive the error again on the same file later in the copy or on another file later in the transfer. It seems completely random when
it occurs, but does appear to be happening more on the larger files.
I have researched this error and have found several references to it being possibly caused by Symantec products or VMWare/ESX network adapters. Neither of those is relevant in my case. I also saw some reference so UNC path issues, which let me
to research UNC path hardening. This led me down the path of investigating the SMB connection. What I have determined is this issue
does not occur when using SMB3 encryption.
I believe this is because when using SMB3 encryption, signing is disabled as per
this article:
When requiring SMB Encryption, SMB Signing is not used, regardless of settings. SMB Encryption implicitly provides the same integrity
guarantees as SMB Signing
Using UNC Path Hardening and setting RequirePrivacy=1, I am able to turn on SMB3 encryption on the share from the client and the issue goes away. However I do not wish to be required to use SMB encryption and should not have to in order to deal with
what is clearly a signing error. I have also attempted to turn of SMB 3.1.1 signing, but I have been unsuccessful in doing that (I detail that issue
here).
I should not however even have to disable SMB signing as this error should simply not be happening for a core function like file copy between two windows systems.
This appears to be the same issued outlined here:
https://support.microsoft.com/en-in/help/2686098/system-error-2148073478-extended-error-or-invalid-signature-error-mess
That still exists years later. That MS article however discusses issues between 3rd party products, not 2 modern Microsoft OSes.
Additionally, the workaround of disabling Secure Negotiate does not seem to work for Server 2019 and/or Windows 10 (again I detail that issue
here).
mevarg10rg1 |
|
|
Статус: Новичок Группы: Участники
|
Всем ку. Нужна подсказка. Цитата: import sys sign=open(«/home/mevarg10rg1/Desktop/derzTest/file_signed.sig»,»r»).read() signedData=pycades.SignedData() print(len(sign)) _signedData=pycades.SignedData() В итоге все вылилось в ошибку Invalid Signature Error (0x80090006) |
 |
|
|
mevarg10rg1 |
|
|
Статус: Новичок Группы: Участники
|
. |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
When copying files from Windows Server 2019 to a Windows 10 client, I get the following error:
error 0x80090006 «Invalid signature»
The data set I have been working with is about 50 GB of data, many of these files are ~500 MB each in size.
This likely happens with other data sets, but this was the first large transfer that I can reliably recreate the issue with on every attempt.
I have done many tests copying this same data set:
- From the server in question to my Windows 10 workstation
- To the server in question from my Windows 10 workstation
- From the server in question to another Windows 2016 server
- From the Windows 2016 server to my Windows 10 workstation
The only time I see this error is the first scenario (Windows 2019 > Windows 10).
Sometimes this error occurs within the first few seconds of my data copy, other times it doesn’t occur until 85%-90% of the data has transferred. Often it occurs multiple times (as much as 10-15) during the whole transfer. In testing this close
to 20 times it has produced this error at least once on transfer of this data set *every single time*.
The error seems recoverable. If I click «Try Again» the data appears to copy correctly, although I may receive the error again on the same file later in the copy or on another file later in the transfer. It seems completely random when
it occurs, but does appear to be happening more on the larger files.
I have researched this error and have found several references to it being possibly caused by Symantec products or VMWare/ESX network adapters. Neither of those is relevant in my case. I also saw some reference so UNC path issues, which let me
to research UNC path hardening. This led me down the path of investigating the SMB connection. What I have determined is this issue
does not occur when using SMB3 encryption.
I believe this is because when using SMB3 encryption, signing is disabled as per
this article:
When requiring SMB Encryption, SMB Signing is not used, regardless of settings. SMB Encryption implicitly provides the same integrity
guarantees as SMB Signing
Using UNC Path Hardening and setting RequirePrivacy=1, I am able to turn on SMB3 encryption on the share from the client and the issue goes away. However I do not wish to be required to use SMB encryption and should not have to in order to deal with
what is clearly a signing error. I have also attempted to turn of SMB 3.1.1 signing, but I have been unsuccessful in doing that (I detail that issue
here).
I should not however even have to disable SMB signing as this error should simply not be happening for a core function like file copy between two windows systems.
This appears to be the same issued outlined here:
https://support.microsoft.com/en-in/help/2686098/system-error-2148073478-extended-error-or-invalid-signature-error-mess
That still exists years later. That MS article however discusses issues between 3rd party products, not 2 modern Microsoft OSes.
Additionally, the workaround of disabling Secure Negotiate does not seem to work for Server 2019 and/or Windows 10 (again I detail that issue
here).
Область применения электронной подписи (ЭП или ЭЦП) довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью: Госуслуги, онлайн-сервисы для управления средствами в банке, электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭЦП, могут вызвать различные серьёзные: от упущенной выгоды до материальных убытков.
Какие бывают ошибки
Проблемы при использовании ЭП, с которыми пользователи встречаются чаще всего, можно условно разделить на три группы:
- Проблемы с сертификатом. Они появляются, когда сертификат не выбран, не найден или не верен.
- Проблемы с подписанием документа. Ошибки возникают при попытке подписать документ.
- Проблема при авторизации на торговых площадках.
Рассмотрим неполадки подробнее и разберёмся, как их решать.
Сертификат не найден
Иногда при попытке подписать электронный документ с помощью ЭП пользователь может столкнуться с ошибкой «Не удалось найти ни одного сертификата, пригодного для создания подписи».
У подобных ошибок могут быть следующие причины:
- На компьютере не установлены корневые сертификаты Удостоверяющего Центра (УЦ), в котором была получена ЭП. Необходимо установить либо обновить корневой сертификат. Установка корневых сертификатов удостоверяющего центра подробно описана в нашей инструкции.
- На ПК не установлено ни одного личного сертификата ЭП. Для применения ЭП необходимы и личные сертификаты. Об их установке мы писали в другой статье.
- Установленные на компьютере необходимые сертификаты не валидны. Сертификаты отозваны или просрочены. Уточните статус сертификата в УЦ. Ошибка с текстом «Ваш сертификат ключа подписи включён в список отозванных» возникает, если у сертификата закончился срок действия или на ПК нужно обновить список сертификатов. В последней ситуации следует вручную загрузить перечень отозванных сертификатов.
Для установки списка отозванных сертификатов:
- Откройте личный сертификат пользователя в окне Свойства браузера. Чтобы открыть его, наберите «Свойства браузера» в поисковой строке меню Пуск. Перейдите во вкладку Содержание и нажмите кнопку «Сертификаты».
- Во вкладке Состав выберите из списка пункт «Точки распространения списков отзыва».
- В блоке Имя точки распространения скопируйте ссылку на загрузку файла со списком отзыва.
- Скачайте по указанной ссылке файл. Нажмите по нему правой кнопкой мыши и выберите в контекстном меню «Установить список отзыва (CRL)».
- Следуйте указаниям «Мастера импорта сертификатов».
Не виден сертификат на носителе
Как правило, причина такой проблемы — сбой в работе программных компонентов. Для её решения достаточно перезагрузить компьютер. Однако иногда этого бывает недостаточно, поэтому требуется переустановка драйверов или обращение в службу техподдержки.
К наиболее распространённым причинам такой проблемы относятся следующие случаи:
- Драйвер носителя не установлен или установлен некорректно. Для решения проблемы необходимо извлечь носитель электронной подписи из ПК и скачать последнюю версию драйвера носителя с официальных ресурсов. Если переустановка драйвера не помогла, подключите носитель к другому ПК, чтобы убедиться в исправности токена. Если токен определится другой системой, попробуйте удалить на неисправном компьютере драйвер носителя и установить его заново.
- Долгое опознание носителя. Для решения проблемы необходимо дождаться завершения процесса или обновить версию операционной системы.
- Некорректная работа USB-порта. Подключите токен к другому USB-порту, чтобы убедиться, что проблема не в носителе ЭП. Если система определила токен, перезагрузите компьютер. Если это не поможет, следует обратиться службу технической поддержки.
- Неисправность носителя. Если при подключении токена к другому компьютеру или USB-порту система не определяет его, значит, проблема в самом носителе. Устранение неисправности возможно в данном случае лишь одним путём — нужно обратиться в сервисный центр для выпуска нового носителя.
ЭП не подписывает документ
Причин у подобной проблемы множество. Каждый случай требует отдельной проверки. Среди самых распространённых можно выделить следующие неполадки:
- Закрытый ключ на используемом контейнере не соответствует открытому ключу сертификата. Возможно, был выбран не тот контейнер, поэтому следует проверить все закрытые контейнеры на компьютере. Если необходимый контейнер по тем или иным причинам отсутствует, владельцу придётся обращаться в удостоверяющий центр для перевыпуска ЭП.
- Ошибка «Сертификат недействителен» (certificate is not valid). Следует повторно установить сертификат ЭП по инструкциям УЦ в зависимости от используемого криптопровайдера — КриптоПро CSP, ViPNet CSP или другого.
- Сертификат ЭП определяется как непроверенный. В этом случае необходимо переустановить корневой сертификат удостоверяющего центра.
- Истёк срок действия криптопровайдера. Для решения этой проблемы необходим новый лицензионный ключ к программе-криптопровайдеру. Для его получения необходимо обращаться к специалистам УЦ или к ответственным сотрудникам своей организации.
- Подключён носитель с другим сертификатом. Убедитесь, что подключён правильный токен. Проверьте также, не подключены ли носители других сертификатов. Отключите другие носители в случае их обнаружения.
В момент подписания электронных документов или формирования запроса в различных может возникнуть ошибка «Невозможно создание объекта сервером программирования объектов».
В этой ситуации помогает установка и регистрация библиотеки Capicom:
- Скачайте файл архива.
- Распакуйте и переместите файлы capicom.dll и capicom.inf в каталог syswow64, находящийся в корневой папке ОС.
- Откройте командную строку от имени администратора — для этого в меню Пуск наберите «Командная строка», нажмите по найденному приложению правой кнопкой мыши и выберите Запуск от имени администратора.
- Введите «c:windowssyswow64regsvr32.exe capicom.dll» (без кавычек) и нажмите ENTER. Должно появиться уведомление о том, что команда выполнена успешно.
Выбранная подпись не авторизована
Подобная ошибка возникает при попытке авторизации в личном кабинете на электронных торговых площадках. Например, при входе на площадку ZakazRF отображается сообщение «Выбранная ЭЦП не авторизована».
Эта ошибка возникает из-за того, что пользователь не зарегистрирован на площадке, либо не зарегистрирован новый сертификат ключа ЭП. Решением проблемы будет регистрация нового сертификата.
Процесс запроса на авторизацию ЭП на разных торговых площадках может отличаться: часто нужно отправлять запрос оператору системы на авторизацию, иногда рабочее место настраивается автоматически.
Если ошибка сохраняется, возможно, следует отключить защитное ПО или добавить сайт электронной площадки в исключения.
Часто задаваемые вопросы
Почему компьютер не видит ЭЦП?
Причина кроется в несовместимости программного обеспечения и физического носителя ЭЦП. Необходимо проверить версию операционной системы и переустановить её до нужной версии. Если токен повреждён, возможно, понадобится обратиться в удостоверяющий центр для перевыпуска электронной подписи.
О том, что делать, если компьютер не видит ЭЦП и о способах проверки настроек, мы подробно писали в нашей статье.
Почему КриптоПро не отображает ЭЦП?
Если КриптоПро не отображает ЭЦП, следует проверить настройки браузера. Также исправляет ошибку добавление программы в веб-обозреватель и загрузка недостающих сертификатов электронной подписи.
Подробнее ознакомиться, как устранить данную неисправность можно в нашей статье.
Где на компьютере искать сертификаты ЭЦП?
Сертификат ЭЦП позволяет проверить подлинность подписи, содержит в себе срок её действия и информацию о владельце. Он автоматически загружается в папку с системными файлами. В операционной системе Windows от 7 версии и выше ЭЦП хранится по адресу:
C:UsersПОЛЬЗОВАТЕЛЬAppDataRoamingMicrosoftSystemCertificates. Вместо ПОЛЬЗОВАТЕЛЬ требуется указать наименование используемого компьютера.
Что такое сертификат ЭЦП и зачем он нужен мы рассказали в нашей статье.