Ошибка импорта сессионного ключа 0 80090006 неправильная подпись

Форум КриптоПро
 » 
Устаревшие продукты
 » 
КриптоПро 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 имя_вашего_контейнера
Официальная техподдержка. Официальная база знаний.

Форум КриптоПро
 » 
Устаревшие продукты
 » 
КриптоПро 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).

Последние 2 недели я бился головой о стену, пытаясь создать и проверить подписи CMS в Swift 4 с помощью OpenSSL. Мой код в конечном итоге предназначен для запуска в Linux, поэтому я не могу использовать среду безопасности macOS. Я полагать Я наконец-то добился правильной работы создания подписи CMS. Мой код для этого выглядит так:

let testBundle = Bundle(for: type(of: self))

guard let textUrl = testBundle.url(forResource: "test_message", withExtension: "txt"),
    let signingKeyUrl = testBundle.url(forResource: "signing_key", withExtension: "pem"),
    let signingCertUrl = testBundle.url(forResource: "signing_cert", withExtension: "pem") else {
        exit(1)
}

let certFileObject = signingCertUrl.path.withCString { filePtr in
    return fopen(filePtr, "rb")
}
defer {
    fclose(certFileObject)
}

let keyFileObject = signingKeyUrl.path.withCString { filePtr in
    return fopen(filePtr, "rb")
}
defer {
    fclose(keyFileObject)
}

guard let key = PEM_read_PrivateKey(keyFileObject, nil, nil, nil),
    let cert = PEM_read_X509(certFileObject, nil, nil, nil) else {
        exit(1)
}

OpenSSL_add_all_ciphers()
OpenSSL_add_all_digests()
OPENSSL_add_all_algorithms_conf()

guard let textData = FileManager.default.contents(atPath: textUrl.path) else {
    exit(1)
}

guard let textBIO = BIO_new(BIO_s_mem()) else {
    print("Unable to create textBIO")
    exit(1)
}

_ = textData.withUnsafeBytes({dataBytes in
    BIO_write(textBIO, dataBytes, Int32(textData.count))
})

guard let cms = CMS_sign(cert, key, nil, textBIO, UInt32(CMS_BINARY)) else {
    exit(1)
}

Когда я отлаживаю этот код, я вижу, что объект cms устанавливается после вызова CMS_sign, поэтому я считаю, что подпись была сгенерирована правильно. Сразу после этого я пытаюсь проверить только что созданную подпись. Этот код выглядит так:

 let store = X509_STORE_new()
 X509_STORE_add_cert(store, cert)

 let outBIO = BIO_new(BIO_s_mem())
 let result = CMS_verify(cms, nil, store, nil, outBIO, 0)
 print("result : (result)")

 if result != 1 {
     let errorCode: UInt = ERR_get_error()
     print("ERROR : (String(format: "%2X", errorCode))")
 }

Однако, когда я запускаю этот код, result == 0, что указывает на ошибку. Код ошибки, возвращаемый OpenSSL, — 0x2E099064. Я выполнил эту команду:

openssl errstr 0x2E099064

Что дало мне эту информацию об ошибке:

error:2E099064:CMS routines:func(153):reason(100)

Еще немного покопавшись, я считать, что ошибка соответствует PKCS7_R_DECRYPTED_KEY_IS_WRONG_LENGTH. Я получил это от pkcs7.h здесь., однако я не на 100% уверен, что это правильное сообщение об ошибке.

У меня вопрос: почему не проходит проверка моей подписи? Я использую тот же сертификат для проверки подписи. Весь этот код является встроенным, поэтому ничего нигде не теряется. Может ли кто-нибудь из вас дать мне представление о том, где что-то идет не так?

Область применения электронной подписи (ЭП или ЭЦП) довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью: Госуслуги, онлайн-сервисы для управления средствами в банке, электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭЦП, могут вызвать различные серьёзные: от упущенной выгоды до материальных убытков.

Какие бывают ошибки

Проблемы при использовании ЭП, с которыми пользователи встречаются чаще всего, можно условно разделить на три группы:

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

Рассмотрим неполадки подробнее и разберёмся, как их решать.

Сертификат не найден

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

У подобных ошибок могут быть следующие причины:

1. На компьютере не установлены корневые сертификаты Удостоверяющего Центра (УЦ), в котором была получена ЭП. Необходимо установить либо обновить корневой сертификат. Установка корневых сертификатов удостоверяющего центра подробно описана в нашей инструкции.
2. На ПК не установлено ни одного личного сертификата ЭП. Для применения ЭП необходимы и личные сертификаты. Об их установке мы писали в другой статье.
3. Установленные на компьютере необходимые сертификаты не валидны. Сертификаты отозваны или просрочены. Уточните статус сертификата в УЦ. Ошибка с текстом «Ваш сертификат ключа подписи включён в список отозванных» возникает, если у сертификата закончился срок действия или на ПК нужно обновить список сертификатов. В последней ситуации следует вручную загрузить перечень отозванных сертификатов.

Для установки списка отозванных сертификатов:

• Откройте личный сертификат пользователя в окне Свойства браузера. Чтобы открыть его, наберите «Свойства браузера» в поисковой строке меню Пуск. Перейдите во вкладку Содержание и нажмите кнопку «Сертификаты».



• Во вкладке Состав выберите из списка пункт «Точки распространения списков отзыва».
• В блоке Имя точки распространения скопируйте ссылку на загрузку файла со списком отзыва.



• Скачайте по указанной ссылке файл. Нажмите по нему правой кнопкой мыши и выберите в контекстном меню «Установить список отзыва (CRL)».
• Следуйте указаниям «Мастера импорта сертификатов».

Не виден сертификат на носителе

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

К наиболее распространённым причинам такой проблемы относятся следующие случаи:

1. Драйвер носителя не установлен или установлен некорректно. Для решения проблемы необходимо извлечь носитель электронной подписи из ПК и скачать последнюю версию драйвера носителя с официальных ресурсов. Если переустановка драйвера не помогла, подключите носитель к другому ПК, чтобы убедиться в исправности токена. Если токен определится другой системой, попробуйте удалить на неисправном компьютере драйвер носителя и установить его заново.
2. Долгое опознание носителя. Для решения проблемы необходимо дождаться завершения процесса или обновить версию операционной системы.
3. Некорректная работа USB-порта. Подключите токен к другому USB-порту, чтобы убедиться, что проблема не в носителе ЭП. Если система определила токен, перезагрузите компьютер. Если это не поможет, следует обратиться службу технической поддержки.
4. Неисправность носителя. Если при подключении токена к другому компьютеру или USB-порту система не определяет его, значит, проблема в самом носителе. Устранение неисправности возможно в данном случае лишь одним путём — нужно обратиться в сервисный центр для выпуска нового носителя.

ЭП не подписывает документ

Причин у подобной проблемы множество. Каждый случай требует отдельной проверки. Среди самых распространённых можно выделить следующие неполадки:

1. Закрытый ключ на используемом контейнере не соответствует открытому ключу сертификата. Возможно, был выбран не тот контейнер, поэтому следует проверить все закрытые контейнеры на компьютере. Если необходимый контейнер по тем или иным причинам отсутствует, владельцу придётся обращаться в удостоверяющий центр для перевыпуска ЭП.
2. Ошибка «Сертификат недействителен» (certificate is not valid). Следует повторно установить сертификат ЭП по инструкциям УЦ в зависимости от используемого криптопровайдера — КриптоПро CSP, ViPNet CSP или другого.
3. Сертификат ЭП определяется как непроверенный. В этом случае необходимо переустановить корневой сертификат удостоверяющего центра.
4. Истёк срок действия криптопровайдера. Для решения этой проблемы необходим новый лицензионный ключ к программе-криптопровайдеру. Для его получения необходимо обращаться к специалистам УЦ или к ответственным сотрудникам своей организации.
5. Подключён носитель с другим сертификатом. Убедитесь, что подключён правильный токен. Проверьте также, не подключены ли носители других сертификатов. Отключите другие носители в случае их обнаружения.

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

В этой ситуации помогает установка и регистрация библиотеки Capicom:

1. Скачайте файл архива.
2. Распакуйте и переместите файлы capicom.dll и capicom.inf в каталог syswow64, находящийся в корневой папке ОС.
3. Откройте командную строку от имени администратора — для этого в меню Пуск наберите «Командная строка», нажмите по найденному приложению правой кнопкой мыши и выберите Запуск от имени администратора.



4. Введите «c:windowssyswow64regsvr32.exe capicom.dll» (без кавычек) и нажмите ENTER. Должно появиться уведомление о том, что команда выполнена успешно.

Выбранная подпись не авторизована

Подобная ошибка возникает при попытке авторизации в личном кабинете на электронных торговых площадках. Например, при входе на площадку ZakazRF отображается сообщение «Выбранная ЭЦП не авторизована».

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

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

Часто задаваемые вопросы

Почему компьютер не видит ЭЦП?

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

О том, что делать, если компьютер не видит ЭЦП и о способах проверки настроек, мы подробно писали в нашей статье.

Почему КриптоПро не отображает ЭЦП?

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

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

Где на компьютере искать сертификаты ЭЦП?

Сертификат ЭЦП позволяет проверить подлинность подписи, содержит в себе срок её действия и информацию о владельце. Он автоматически загружается в папку с системными файлами. В операционной системе Windows от 7 версии и выше ЭЦП хранится по адресу:

C:UsersПОЛЬЗОВАТЕЛЬAppDataRoamingMicrosoftSystemCertificates. Вместо ПОЛЬЗОВАТЕЛЬ требуется указать наименование используемого компьютера.

Что такое сертификат ЭЦП и зачем он нужен мы рассказали в нашей статье.