Форум КриптоПро
»
Устаревшие продукты
»
КриптоПро 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. Проверка завершилась с ошибкой контейнер один на рутокене. в панели управления рутокена эп просматривается, цепь сертификатов строится. драйвера рутокена последние. Помогите, пожалуйста, разобраться. |
![]() |
|
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
Также добавлю, что проверяли привязанность открытой части к контейнеру (в крипто про автоматически определился для этой открытой части именно этот контейнер). |
![]() |
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере. |
|
Знания в базе знаний, поддержка в техподдержке |
|
![]() |
WWW |
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
Автор: maxdm Сделайте тестирование в последней версии 4.0. Скорее всего сертификат поврежден в контейнере. В 4.0 ошибка повторилась. Это говорит о том, что контейнер поврежден? |
![]() |
|
|
Птаха |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 29 раз |
И снова столкнулись с такой проблемой у другого клиента. Т.е.. таких уже как минимум 3: пользовались-пользовались, вдруг такая ошибка. |
![]() |
|
|
Русев Андрей |
|
|
Статус: Сотрудник Группы: Администраторы, Участники Сказал(а) «Спасибо»: 10 раз |
Пришлите, пожалуйста, что выдаёт команда: Код:
|
|
Официальная техподдержка. Официальная база знаний. |
|
![]() |
|
| Пользователи, просматривающие эту тему |
|
Guest |
Форум КриптоПро
»
Устаревшие продукты
»
КриптоПро CSP 3.9
»
проверка контейнера ошибка 0x80090006 (-2146893818) Неправильная подпись
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
#1 2015-02-09 18:45:31
- TWIN
- Посетитель
- Неактивен
Ошибка:Неправильная подпись (0x80090006)
Похожая ошибка уже была в теме: https://forum.rutoken.ru/topic/1739/
Сейчас аналогичная.
Драйвера 2.100 последние
Операционка WIN PROF SP3
Ключ рабочий точно. На другом компе с такой же операционкой — все работает. На токене 2 ключа — один выдан для отчетности, второй для VPN для УРМ.
Ключ отчетности в крипте видно. Для VPN и не должен видится.
При запуске подключения VPN ошибка аналогичная.
Драйвера переставлял, Крипто переставлял. Систему обновлял. Как ни крути не видит ключ.
Возможно что то в системе порушено. Очень не хочется систему переставлять. Много очень бухгалтерских программ.
#2 Ответ от Ксения Шаврова 2015-02-10 17:04:12 (2015-02-10 17:05:07 отредактировано Ксения Шаврова)
- Ксения Шаврова
- Администратор
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Отвечено на почту, указанную при регистрации на форуме.
#3 Ответ от guryev 2015-03-21 11:43:34
- guryev
- Посетитель
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Та же история — Панель управления Рутокен, при открывании вкладки «Сертификаты», ошибка Invalid Signature 0x80090006. Тип и свободная память отображаются в «Информации о Рутокене» как:
тип: Rutoken S 64K
Свободная память (байт): 57792
ОС Windows XP, установлены драйверы с установщика rtDrivers.x86.v.2.100.00.0542.exe
#4 Ответ от Ксения Шаврова 2015-03-23 11:14:19
- Ксения Шаврова
- Администратор
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
guryev пишет:
Та же история — Панель управления Рутокен, при открывании вкладки «Сертификаты», ошибка Invalid Signature 0x80090006.
Здравствуйте, guryev
Указанного вами при регистрации e-mail не существует. Напишите запрос на почту службы технической поддержки hotline@rutoken.ru
#5 Ответ от guryev 2015-03-23 13:06:22
- guryev
- Посетитель
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Спасибо за быстрый ответ:
1. e-mail существует (иначе бы я не смог зарегистрироваться);
2. Послал (с него) сообщение на hotline@rutoken.ru.
#6 Ответ от Ксения Шаврова 2015-03-23 13:49:55
- Ксения Шаврова
- Администратор
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Отвечено по почте
#7 Ответ от microfarmica 2015-05-22 22:51:25
- microfarmica
- Посетитель
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Сегодня выдали новый токен, в панели управления, пр переходе на вкладку «сертификаты», вылазит ошибка. ОС Win7, драйвера v.2.100.00.0542 от 20.11.2014, WHQL-certified
![]()
#8 Ответ от Эдуард 2022-04-11 05:57:55
- Эдуард
- Посетитель
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
ФГИС «Аршин», при подписании заявки на публикацию выбирается действующий ключ, а затем вылетает «Ошибка:Неправильная подпись (0x80090006)». Что делать?
#9 Ответ от Фатеева Светлана 2022-04-11 15:01:27
- Фатеева Светлана
- Техническая поддержка
- На форуме
Re: Ошибка:Неправильная подпись (0x80090006)
Здравствуйте, Эдуард,
Пришлите пожалуйста скриншот «Панели управления Рутокен» на вкладке Сертификаты и скриншот ошибки.
#10 Ответ от fgfg 2022-10-06 14:14:53
- fgfg
- Посетитель
- Неактивен
Re: Ошибка:Неправильная подпись (0x80090006)
Добрый день!
Используем pkcs11 драйвер через библиотеку
c:windowssystem32rtPKCS11ECP.dll
Создаем подпись в соответствии с файлом примеро из SDK
rv = functionList->C_SignInit(session, &gostR3410_2001SigVerMech_WithHash, objects1[0]);
Если использовать этот механизм (изначально он закоментирован в Common.h)
static CK_MECHANISM gostR3410_2001SigVerMech_WithHash = {CKM_GOSTR3410_WITH_GOSTR3411, parametersGostR3411_1994, sizeof(parametersGostR3411_1994)};
Тогда всё работает отлично и на старой и на новой версии драйвера pkcs11.
Если использовать рекомендованный механизм, а именно —
static CK_MECHANISM gostR3410_2001SigVerMech_WithHash = {CKM_GOSTR3410_WITH_GOSTR3411, NULL_PTR, 0};
Тогда идет ошибка номер 6 — но только если использовать последнюю версию rtPKCS11ECP.dll 2.3.3.0
Если использовать старую (не помню точно номер, но вроде бы 2.2.5.0) — тогда всё ОК.
Отсюда вывод — поправьте последнюю 2.3.3.0 версию, там наблюдаются глюки в механизме
static CK_MECHANISM gostR3410_2001SigVerMech_WithHash = {CKM_GOSTR3410_WITH_GOSTR3411, NULL_PTR, 0};
С уважением!
PS. Извините, пишу в эту тему так как здесь наблюдается такая точно ошибка, но в прикладных программах!
Которые по всей видимости, тоже используют этот новый проблемный драйвер.
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
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).
31 окт 2019 00:43 #14180
от nick_e
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
31 окт 2019 01:38 #14181
от Petrovich
Спасибо сказали: nick_e, vizartron
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
13 нояб 2019 23:06 #14313
от proJIog
с Континентом АП устанавливается Код безопасности CSP (пуск-Все программы-Код безопасности) так вот, запускаешь, 2 вкладка «Ключевые контейнеры» водишь пин код Токена, после в АП закрытый контейнер появляется, только в моем случае потом выдает ошибку что НЕ НАЙДЕН КОРНЕВОЙ СЕРТИФИКАТ!
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
18 нояб 2019 12:34 #14360
от Mr.ZEV
Здравствуйте! Столкнулся с проблемой при создании запроса на сертификат по гост — 2012. Появляется ошибка создания запроса 0x80090006 неправильная подпись. Стоит Континент версии 3.7.7.651. Подскажите пожалуйста, что делать?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
18 нояб 2019 12:49 #14361
от gurazor
Mr.ZEV пишет: Здравствуйте! Столкнулся с проблемой при создании запроса на сертификат по гост — 2012. Появляется ошибка создания запроса 0x80090006 неправильная подпись. Стоит Континент версии 3.7.7.651. Подскажите пожалуйста, что делать?
Добрый день!
Пуск/все программы/код безопасности/Континент-АП/Код безопасности CSP работает?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
19 нояб 2019 04:16 #14366
от Mr.ZEV
Что-то нет его. Переустановить континент?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
19 нояб 2019 05:57 #14369
от Mr.ZEV
Переустановка Континента ничего не дала. Код безопасности так и не появился. Помогите плиз!
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
19 нояб 2019 07:29 #14371
от Mr.ZEV
Удаление из реестра папки HKEY_LOCAL_MACHINESOFTWARESecurityCodeCSP решило проблему.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
19 нояб 2019 07:38 #14372
от Alex67
Mr.ZEV пишет: Удаление из реестра папки HKEY_LOCAL_MACHINESOFTWARESecurityCodeCSP решило проблему.
Континент TLS от ЭБ на машине был? Он видимо свой CSP от КБ поставил.
«Кто людям помогает — лишь тратит время зря. Хорошими делами прославиться нельзя» (с) Шапокляк
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 02:59 #14413
от Sherkhan
Ещё вчера всё работало, а сегодня с утра: ошибка подписи ключа 0x00000578 недопустимый дескриптор окна. В списке ошибок Континента такую не нашёл. Что это может быть?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 05:37 — 28 нояб 2019 05:48 #14415
от Alex67
Sherkhan пишет: Ещё вчера всё работало,
А ключ то у вас какой был ещё вчера? ГОСТ 2001 или ГОСТ 2012? Версия КАП? А ОС какая? Не обновлялась ли?
Что вы как партизан на допросе………..
«Кто людям помогает — лишь тратит время зря. Хорошими делами прославиться нельзя» (с) Шапокляк
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 05:49 #14416
от Sherkhan
На новом ГОСТЕ 2 недели работал нормально. Ничего не менялось. Обновления Windows отключены.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 05:50 — 28 нояб 2019 05:56 #14417
от Sherkhan
Windows 7 х64, АП 3.7.7.625, на вирусы проверил — чисто. В журнале:
— Provider
[ Name] eap
— EventID 51
[ Qualifiers] 49154
Level 2
Task 0
Keywords 0x80000000000000
Контроль целостности прошёл, ошибок нет.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 06:51 #14419
от Alex67
Sherkhan пишет: [ Name] eap
В процессах EAPSigner161.exe (c:Program FilesSecurity CodeTerminal StationvpnEAPSigner161.exe) есть? (должен быть)
«Кто людям помогает — лишь тратит время зря. Хорошими делами прославиться нельзя» (с) Шапокляк
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
28 нояб 2019 07:30 #14422
от Sherkhan
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Сообщение об ошибке 0x80090006 может появляться на ПК с Windows. Это случается непредсказуемо, но иногда проблема возникает лишь при копировании файлов с сервера под Windows Server 2012 на пользовательские компьютеры. В зависимости от условий, при которых проявилась неполадка, отличаются и пути решения.
Решения для ошибки 0x80090006

№1: если сбой во время копирования файлов
В этом случае действовать нужно следующим образом:
- «Играться» с сервисом Symantec Endpoint Protection. Имеет смысл отключить эту защиту или удалить ее вообще, после чего пытаться копировать файлы еще раз.
- Изменить адрес Network interface controller. Это поможет если сервер запущен на виртуальной машине. Необходимо модифицировать значение с E1000E (и других подобных) на E1000.
- Обновить драйвера на сетевые устройства.
№2: если сбой возник непредсказуемо
- Проверьте систему на вирусы. Если они были обнаружены и полностью удалены, то далее запустите в Командной строке с администраторскими правами запрос sfc /scannow.
- Правим системный файлы. Заходим в безопасный режим с поддержкой Командной строки. Запускаем следующие команды:
- c:windowssystem32dllcachersaenh.dll c:windowssystem32
- c:windowssystem32dllcachedssenh.dll c:windowssystem32
- c:windowssystem32dllcachesccbase.dll c:windowssystem32
Перегружаемся, после ошибка 0x80090006 должна исчезнуть.
В Windows 10, 2012R2, 2016 не работают примеры для шифрования/расшифрования данных с передачей сессионного ключа. Например, EncryptDecryptSessionKeyTest.
При попытке расшифровать сессионный ключ функция CryptoApi.CryptImportKey выдает ошибку «Плохой ключ» (для VipNet) или «Плохие данные» (для КриптоПро).
Stacktrace:
в GostCryptography.Native.CryptoApiHelper.ImportCspBlob(Byte[] importedKeyBytes, SafeProvHandleImpl providerHandle, SafeKeyHandleImpl publicKeyHandle, SafeKeyHandleImpl& keyExchangeHandle) в SourceGostCryptographyNativeCryptoApiHelper.cs:строка 905
в GostCryptography.Native.CryptoApiHelper.ImportKeyExchange(SafeProvHandleImpl providerHandle, GostKeyExchangeInfo keyExchangeInfo, SafeKeyHandleImpl keyExchangeHandle) в SourceGostCryptographyNativeCryptoApiHelper.cs:строка 958
в GostCryptography.Cryptography.GostKeyExchangeAlgorithm.DecodeKeyExchangeInternal(Byte[] encodedKeyExchangeData, Int32 keyExchangeExportAlgId) в SourceGostCryptographyCryptographyGostKeyExchangeAlgorithm.cs:строка 150
Сессионный ключ как-то некорректно передается…
Т.е. не удается расшифровать зашифрованные данные на той же самой машине тем же самым процессом. Не удается также расшифровать эти данные и на других машинах, например, под Windows 7.
При этом в Windows 7 шифрование работает корректно на тех же самых сертификатах, данные шифруются корректно. Примеры успешно работают.
В чем может быть проблема?
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).





