Ошибка обращения к контейнеру закрытого ключа 0x80090006 неправильная подпись

Форум КриптоПро
»
Устаревшие продукты
»
КриптоПро CSP 3.9
»
проверка контейнера ошибка 0x80090006 (-2146893818) Неправильная подпись

IgorDID	#1 Оставлено : 6 июля 2015 г. 9:06:27(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.04.2012(UTC) Сообщений: 17 Откуда: Россия Поблагодарили: 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 Ключ подписи отсутствует загрузка ключей успешно

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

IgorDID	#3 Оставлено : 6 июля 2015 г. 13:07:45(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.04.2012(UTC) Сообщений: 17 Откуда: Россия Поблагодарили: 1 раз в 1 постах	К сожалению подробностей получить не удалось. Наш клиент (мы УЦ) сообщил, что перекопировал папку с флешки на другую и у него все заработало. От дальнейшего диалога отказался. Подскажите, что в теории могло вызвать данные симптомы ? Было бы полезно для базы знаний.

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

Птаха	#5 Оставлено : 16 июля 2015 г. 17:38:15(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 28.06.2013(UTC) Сообщений: 140 Откуда: ООО Компания Тензор Сказал(а) «Спасибо»: 29 раз	Столкнулись с такой же проблемой: ключ работал. Сейчас при тестировании в 3.6.7777 выдает ошибку Ошибка 0x80090006. Проверка завершилась с ошибкой Контейнер закрытого ключа имя 3a62bc66-937b-460b-a7f2-88567816bc35 уникальное имя SCARDrutoken_2ca55536A00106D FQCN \.Aktiv Co. ruToken 03a62bc66-937b-460b-a7f2-88567816bc35 проверка целостности контейнера успешно Ключ обмена доступен экспорт открытого ключа успешно импорт открытого ключа успешно подпись успешно проверка Ошибка 0x80090006 (-2146893818) Неправильная подпись. создание ключа обмена успешно экспорт ключа разрешен алгоритм ГОСТ Р 34.10-2001 DH ГОСТ Р 34.10-2001, параметры обмена по умолчанию ГОСТ Р 34.11-94, параметры по умолчанию сертификат в контейнере соответствует закрытому ключу сертификат в хранилище My ОГРН=1135001006216, СНИЛС=13385632366, ИНН=005001096368, E=5041962@mail.ru, O=»ПРОМТЕХКОНВЕЙЕР, ООО», OU=0, T=Генеральный директор, CN=»ПРОМТЕХКОНВЕЙЕР, ООО», SN=Сальманов, G=Альберт Мунирович, C=RU, L=Балашиха, S=50 Московская область, STREET=»ул.Советская, владение 37″ SCARDrutoken_2ca55536A00106D; Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider; 75 имя сертификата ПРОМТЕХКОНВЕЙЕР, ООО субъект ОГРН=1135001006216, СНИЛС=13385632366, ИНН=005001096368, E=5041962@mail.ru, O=»ПРОМТЕХКОНВЕЙЕР, ООО», OU=0, T=Генеральный директор, CN=»ПРОМТЕХКОНВЕЙЕР, ООО», SN=Сальманов, G=Альберт Мунирович, C=RU, L=Балашиха, S=50 Московская область, STREET=»ул.Советская, владение 37″ поставщик ОГРН=1027600787994, ИНН=007605016030, STREET=Московский проспект д.12, E=root@nalog.tensor.ru, C=RU, S=76 Ярославская область, L=Ярославль, O=ООО Компания Тензор, OU=Удостоверяющий центр, CN=TENSORCA3 действителен с 24 февраля 2015 г. 17:28:46 действителен по 24 мая 2016 г. 17:28:46 ключ действителен с 24 февраля 2015 г. 17:38:00 ключ действителен по 24 мая 2016 г. 17:38:00 серийный номер 375F 2DBB 0001 001D EAE3 Ключ подписи отсутствует загрузка ключей успешно контейнер один на рутокене. в панели управления рутокена эп просматривается, цепь сертификатов строится. драйвера рутокена последние. были драйвера етокена, но их удалили, после этого переставляли драйвера рутокена и крипто про. итог тестирования не изменился. при попытке копирования ошибка Неверные данные. Скрины приложены Screenshot_9.png (25kb) загружен 38 раз(а). Screenshot_8.png (78kb) загружен 37 раз(а). Screenshot_6.png (107kb) загружен 34 раз(а). Screenshot_7.png (179kb) загружен 32 раз(а). Screenshot_5.png (340kb) загружен 24 раз(а). Помогите, пожалуйста, разобраться.

Птаха	#6 Оставлено : 16 июля 2015 г. 17:41:19(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 28.06.2013(UTC) Сообщений: 140 Откуда: ООО Компания Тензор Сказал(а) «Спасибо»: 29 раз	Также добавлю, что проверяли привязанность открытой части к контейнеру (в крипто про автоматически определился для этой открытой части именно этот контейнер). Также могу предоставить подписываемый файл и получившуюся подпись…

Максим Коллегин	#7 Оставлено : 16 июля 2015 г. 18:54:24(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,253 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере.
Знания в базе знаний, поддержка в техподдержке
	WWW

Птаха	#8 Оставлено : 23 июля 2015 г. 13:58:33(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 28.06.2013(UTC) Сообщений: 140 Откуда: ООО Компания Тензор Сказал(а) «Спасибо»: 29 раз	Автор: maxdm Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере. В 4.0 ошибка повторилась. Это говорит о том, что контейнер поврежден? Какие могут быть к этому причины повреждения тогда?

Птаха	#9 Оставлено : 14 октября 2015 г. 12:27:54(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 28.06.2013(UTC) Сообщений: 140 Откуда: ООО Компания Тензор Сказал(а) «Спасибо»: 29 раз	И снова столкнулись с такой проблемой у другого клиента. Т.е.. таких уже как минимум 3: пользовались-пользовались, вдруг такая ошибка. Тестирование в 4.0 выдает ту же ошибку. Есть ли какие-то предположения? Интересует, можно ли это исправить (судя по всему-нет?). И вследствие чего может возникать такая ситуация.

Русев Андрей	#10 Оставлено : 14 октября 2015 г. 13:57:41(UTC)
Статус: Сотрудник Группы: Администраторы, Участники Зарегистрирован: 16.04.2008(UTC) Сообщений: 1,060 Сказал(а) «Спасибо»: 10 раз Поблагодарили: 319 раз в 241 постах	Пришлите, пожалуйста, что выдаёт команда: Код: `csptest -keyset -check -container имя_вашего_контейнера`
Официальная техподдержка. Официальная база знаний.

Пользователи, просматривающие эту тему

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

Источник

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

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

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

Источник

31 окт 2019 00:43 #14180
от nick_e