Finding certificate by issuer chain returned error 80092004

Fixes a problem in which a Configuration Manager client can't communicate with its management point. Occurs when a third-party trusted root certification authority is defined in System Center 2012 R2.

Microsoft System Center 2012 R2 Configuration Manager More…Less

Symptoms

A Configuration Manager client cannot communicate with its assigned management point when it is configured for HTTPS communications. This problem occurs when a third-party trusted root certification authority is defined in the properties of the site server. In this situation, entries that resemble the following are logged in the ClientIDManagerStartup.log file:

Finding certificate by issuer chain returned error 80092004
Unable to find any Certificate based on Certificate Issuers

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, go to the following Microsoft website:

Prerequisites

To apply this hotfix, you must have Cumulative Update 3 for System Center 2012 R2 Configuration Manager installed.

Restart information

You must restart the computer after you apply this hotfix.

Note We recommend that you close Configuration Manager Administration Console before you apply this hotfix package.

Hotfix replacement information

This hotfix does not replace any previously released hotfix.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

File name

File version

File size

Date

Time

Platform

Ccmsetup.exe

5.0.7958.1407

1,619,120

25-Aug-2014

01:35

x86

Ccmutillib.dll

5.0.7958.1407

515,760

25-Aug-2014

01:35

x64

Configmgr2012ac-r2-kb3007773-x64.msp

Not applicable

7,405,568

25-Aug-2014

01:35

Not applicable

Mp.msi

Not applicable

9,388,032

25-Aug-2014

01:35

Not applicable

Ccmsetup.exe

5.0.7958.1407

1,619,120

25-Aug-2014

01:35

x86

Ccmutillib.dll

5.0.7958.1407

401,072

25-Aug-2014

01:35

x86

Configmgr2012ac-r2-kb3007773-i386.msp

Not applicable

5,976,064

25-Aug-2014

01:35

Not applicable

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.

References

Learn about the terminology that Microsoft uses to describe software updates.

Need more help?

Источник

Содержание

  1. Веб — сервис интеграции
  2. Ошибка CertFindCertificateInStore в stunnel
  3. Веб — сервис интеграции
  4. Stunnel error 0x80092004 returned by certfindcertificateinstore
  5. 0x80090304 Интеграция DMDK с КриптоПро и Stunnel
  6. Errors
  7. Possible Solutions
  8. Possible Solutions
  9. Possible Solutions
  10. Possible Causes
  11. Possible Solutions
  12. Possible Solutions

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

Доброго времени суток!
Установил обезличенный сертификат.
в SOAP пытаюсь установить соединение, но выдаёт ошибку сертификата:
2021.11.26 11:32:48 LOG5[5972:1472]: stunnel 4.18 on x86-pc-unknown
2021.11.26 11:32:48 LOG5[5972:1472]: Threading:WIN32 Sockets:SELECT,IPv6
2021.11.26 11:32:48 LOG5[5972:1472]: No limit detected for the number of clients
2021.11.26 11:32:48 LOG7[5972:1472]: FD 356 in non-blocking mode
2021.11.26 11:32:48 LOG7[5972:1472]: SO_REUSEADDR option set on accept socket
2021.11.26 11:32:48 LOG7[5972:1472]: https bound to 127.0.0.1:1500
2021.11.26 11:33:21 LOG7[5972:1472]: https accepted FD=360 from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:1472]: Creating a new thread
2021.11.26 11:33:21 LOG7[5972:1472]: New thread created
2021.11.26 11:33:21 LOG7[5972:8548]: client start
2021.11.26 11:33:21 LOG7[5972:8548]: https started
2021.11.26 11:33:21 LOG7[5972:8548]: FD 360 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on local socket
2021.11.26 11:33:21 LOG5[5972:8548]: https connected from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:8548]: FD 428 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: https connecting
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: waiting 10 seconds
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: connected
2021.11.26 11:33:21 LOG7[5972:8548]: Remote FD=428 initialized
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on remote socket
2021.11.26 11:33:21 LOG7[5972:8548]: start SSPI connect
2021.11.26 11:33:21 LOG5[5972:8548]: try to read the client certificate
2021.11.26 11:33:21 LOG7[5972:8548]: open file c:stunnelclicer.cer with certificate
2021.11.26 11:33:21 LOG5[5972:8548]: CertFindCertificateInStore not find client certificate in store CURRENT_USER. Looking at LOCAL_MACHINE
2021.11.26 11:33:21 LOG3[5972:8548]: Error 0x80092004 returned by CertFindCertificateInStore

кто-то сталкивался с таким?
буду благодарен за помощь!

Источник

Ошибка CertFindCertificateInStore в stunnel

При настройке интеграции stunnel с ГИИС ДМДК у некоторых пользователей не проходит связь с сайтом и в логе stunnel выдается ошибка:

CertFindCertificateInStore not find client certificate in store CURRENT_USER. Looking at LOCAL_MACHINE
Error 0x80092004 returned by CertFindCertificateInStore

Решается такая ошибка достаточно просто. А возникает из за того, что при настройке интеграции, вы забыли поместить сертификат усиленной квалифицированной электронной подписи в хранилище «Личное». Что бы устранить эту ошибку, откройте КриптоПро, на вкладке «Сервис» выберите пункт меню «Просмотреть сертификаты в контейнере»

Затем нажмите кнопку «Обзор» и из списка сертификатов выберите нужный и нажмите кнопку «ок»

В открывшемся окне просмотра сертификата, нажмите «Установить»

Перезапустите службу stunnel и проверьте связь, если все сделали правильно, все должно заработать!

Источник

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

Здравствуйте.
Я с вопросом по stunnel.
Имеем в анамнезе: Win10Pro x64, stunnel.x64, clicer.cer, выпущенный тестовым УЦ криптопро и установленный в личные нового пользователя винды с парольным входом.
Служба стартует автоматически. stunnel.conf лежит в c:WindowsSystem32 и выглядит так:
output=c:stunnelstunnel.log
socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1
debug=7
[https]
client=yes
accept=127.0.0.1:1500
connect=195.209.130.19:443
cert=C:stunnelclicer.cer
verify=0

Кусок лога выглядит так:
2021.10.27 10:40:39 LOG3[11048:11432]: Error creating credentials
2021.10.27 10:40:39 LOG5[11048:11432]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2021.10.27 10:40:39 LOG7[11048:11432]: free Buffers
2021.10.27 10:40:39 LOG5[11048:11432]: incomp_mess = 0, extra_data = 0
2021.10.27 10:40:39 LOG7[11048:11432]: https finished (0 left)
2021.10.27 10:40:39 LOG7[11048:7752]: https accepted FD=428 fr om 127.0.0.1:50323
2021.10.27 10:40:39 LOG7[11048:7752]: Creating a new thread
2021.10.27 10:40:39 LOG7[11048:7752]: New thread created
2021.10.27 10:40:39 LOG7[11048:13304]: client start
2021.10.27 10:40:39 LOG7[11048:13304]: https started
2021.10.27 10:40:39 LOG7[11048:13304]: FD 428 in non-blocking mode
2021.10.27 10:40:39 LOG7[11048:13304]: TCP_NODELAY option set on local socket
2021.10.27 10:40:39 LOG5[11048:13304]: https connected from 127.0.0.1:50323
2021.10.27 10:40:39 LOG7[11048:13304]: FD 476 in non-blocking mode
2021.10.27 10:40:39 LOG7[11048:13304]: https connecting
2021.10.27 10:40:39 LOG7[11048:13304]: connect_wait: waiting 10 seconds
2021.10.27 10:40:39 LOG7[11048:13304]: connect_wait: connected
2021.10.27 10:40:39 LOG7[11048:13304]: Remote FD=476 initialized
2021.10.27 10:40:39 LOG7[11048:13304]: TCP_NODELAY option set on remote socket
2021.10.27 10:40:39 LOG7[11048:13304]: start SSPI connect
2021.10.27 10:40:39 LOG5[11048:13304]: try to read the client certificate
2021.10.27 10:40:39 LOG7[11048:13304]: open file C:stunnelclicer.cer with certificate
2021.10.27 10:40:39 LOG5[11048:13304]: CertFindCertificateInStore not find client certificate in store CURRENT_USER. Looking at LOCAL_MACHINE
2021.10.27 10:40:39 LOG3[11048:13304]: Error 0x80070057 returned by CertFindCertificateInStore

2021.10.27 10:40:39 LOG3[11048:13304]: Error creating credentials
2021.10.27 10:40:39 LOG5[11048:13304]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2021.10.27 10:40:39 LOG7[11048:13304]: free Buffers
2021.10.27 10:40:39 LOG5[11048:13304]: incomp_mess = 0, extra_data = 0
2021.10.27 10:40:39 LOG7[11048:13304]: https finished (0 left)

Источник

Stunnel error 0x80092004 returned by certfindcertificateinstore

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • Gvinpin
  • —>
  • Не в сети
  • Сообщений: 2008
  • Спасибо получено: 264

YFNS5611 пишет: или что-то не туда установил?!

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • YFNS5611
  • Автор темы —>
  • Не в сети
  • Сообщений: 3
  • Спасибо получено: 0
Вложения:

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • Alex67
  • —>
  • Не в сети
  • Сообщений: 1876
  • Спасибо получено: 505

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • Gvinpin
  • —>
  • Не в сети
  • Сообщений: 2008
  • Спасибо получено: 264

YFNS5611 пишет: Вообще нет проблем. Может быть сам сертификат корявый? ведь другой — то подписывает без проблем на этой же машине

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • YFNS5611
  • Автор темы —>
  • Не в сети
  • Сообщений: 3
  • Спасибо получено: 0

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • manager15
  • —>
  • Не в сети
  • Ватокат
  • Сообщений: 1
  • Спасибо получено: 0

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • ranger
  • —>
  • Не в сети
  • Сообщений: 461
  • Спасибо получено: 54

manager15 пишет: Извините что влезаю, но какая разница по какому ГОСТу выпущен сертификат?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • Alex_04
  • —>
  • Не в сети
  • ТОФК
  • Сообщений: 2291
  • Спасибо получено: 381

manager15 пишет: Извините что влезаю.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Источник

0x80090304 Интеграция DMDK с КриптоПро и Stunnel

There are many posts online listing many different possible causes for these errors, so it’s not possible for this article to encompass all the solutions. These are just solutions to common causes for these errors. If the suggestions listed here don’t work for you, please email support at support@nsoftware.com

Ошибка 87 – говорит о том, что у нас на Windows 7 не выполняется команды

Для этого требуется установить исправление KB2966583 в моем случае это помогло.

Вторая ошибка связана с работой RDP на Windows 7 при которой нельзя подключится к Windows 10.

Уровень безопасности сервера обнаружил ошибку (0x80090304) в потоке протокола

Для этого потребуется установить 2 исправления KB2592687 и KB2574819-v2-x86 мне опять же помогло, все обновления скачанные с Microsoft прилагаются во вложении. Возможно данный алгоритм можно применить и к Windows 7 x64

Последнее редактирование: 28 Июль 2021

Есть крипто про 4. Необходимо установить stunnel. Интернет пишет, что он входит в комплект установки. Но там ничего подобного не видно.
Или он всё-таки устанавливается отдельно? Тогда, где его взять?

1 – 24.11.21 – 11:28

2 – 24.11.21 – 11:37

3 – 24.11.21 – 11:40

(2) И?
На скриншоте как раз ссылки под винду и написано что в линуксе это встроено

4 – 24.11.21 – 12:04

(3)Ну да. А оно с 4-й версие крипто про работать будет? И файлик подозрительно мелкий всего 89кб.

5 – 24.11.21 – 12:05

(4) ты лучше скажи для чего собрался туннель делать

6 – 24.11.21 – 12:06

7 – 24.11.21 – 12:28

8 – 24.11.21 – 12:29

9 – 24.11.21 – 16:17

(7)(8)Не читал. Пока тестовый контур пробую запустить. Благодарю за помощь.

10 – 09.02.22 – 23:13

Здравствуйте. Всё сделал по инструкции. Выдаёт ошибку:

Не удалось запустить службу Stunnel Service на Локальный компьютер
Ошибка 1069: Служба не запущена из-за ошибки входа в систему.

11 – 09.02.22 – 23:34

(10) Служба от кого запускается?

12 – 09.02.22 – 23:39

13 – 09.02.22 – 23:52

Эта ошибка была без пароля. Поставил пароль, Ошибка 1067: Процесс был неожиданно завершён

14 – 10.02.22 – 00:03

(13)Попробуйте переустановить службу.

15 – 10.02.22 – 00:26

Уже выкладывал тут кусок из инструкции от ювелирсофта

Это обязательное условие!

У меня все заработало 🙂

16 – 10.02.22 – 01:35

(15)Есть нормальный хостинг картинок?)

17 – 10.02.22 – 06:25

(13) У вас журналирование настроено? В настройках stunnel.conf проверьте опцию “output” — это путь к лог-файлу. Посмотрите, что там в журнале, выложите сюда вывод.

18 – 10.02.22 – 07:08

Вопрос как решился с сертификатом? У нас 3 раз бубен и третий раз разный.

19 – 10.02.22 – 08:13

Если туннель запускаете под системной учетной записью, то сертификат должен быть установлен в “Сертификаты локальный компьютер”. Если под другой учетной записью, то в хранилище этой учетной записи. Пароль доступа к контейнеру должен быть сохранен. Сертификат с открытым ключем сохранить на диске и прописать к нему путь в конфиге stunnel. В инструкции всё написано.
Смысл этой байды в том, что stunnel должен иметь доступ к закрытому ключу, который у вас в хранилище. Чтобы иметь доступ к хранилищу пользователя, stunnel должен запускаться от этого пользователя. Пароль от контейнера он спрашивать не умеет, потому пароль должен быть вбит заранее и сохранен (галку там поставить).

20 – 10.02.22 – 08:58

(19)Да конечно всё по инструкции. Всё от одного пользователя. Сертификат сохранен без ключа. Прописан в конфиге. При старте ругается на сертификат. Где то только в консольной версии работает. Где то как служба. ДМДК пишут об обезличенном сертификате, народ утверждает что такие не выдают для ип (проверить не могу). Чем он лучше не говорят. ЮвелирСофт всё молиться на прямые руки сисадмина и просит 14000 за настройку stunnel.

wraithik

Установлен stunnel
Содержимое конф-файла

Сертификат получен в налоговой, он обезличенный.
В логах stunnel

2022.02.25 17:00:31 LOG5[4288:5908]: try to read the client certificate
2022.02.25 17:00:31 LOG7[4288:5908]: open file c:stunnelcert.cer with certificate
2022.02.25 17:00:31 LOG3[4288:5908]: **** Error 0x80090304 returned by AcquireCredentialsHandle
2022.02.25 17:00:31 LOG3[4288:5908]: Credentials complete
2022.02.25 17:00:31 LOG3[4288:5908]: Error creating credentials

Сертификат установлен в личное хранилище. КриптоПро 5.0.120.
Подскажите что с этим делать.

Александр Лавник

Автор: wraithik

Установлен stunnel
Содержимое конф-файла

Сертификат получен в налоговой, он обезличенный.
В логах stunnel

2022.02.25 17:00:31 LOG5[4288:5908]: try to read the client certificate
2022.02.25 17:00:31 LOG7[4288:5908]: open file c:stunnelcert.cer with certificate
2022.02.25 17:00:31 LOG3[4288:5908]: **** Error 0x80090304 returned by AcquireCredentialsHandle
2022.02.25 17:00:31 LOG3[4288:5908]: Credentials complete
2022.02.25 17:00:31 LOG3[4288:5908]: Error creating credentials

Сертификат установлен в личное хранилище. КриптоПро 5.0.120.
Подскажите что с этим делать.

Сертификат установлен в хранилище “Личное” компьютера (не текущего пользователя) с привязкой к ключевому контейнеру?

На ключе не установлен пин-код?

wraithik

Нет. В носитель заходит без пин-кода через протестировать.

Как точно проверить что пароля нет или удалить?

Александр Лавник

Автор: wraithik

Нет. В носитель заходит без пин-кода через протестировать.

Как точно проверить что пароля нет или удалить?

Какой ключевой носитель?

wraithik

Проверка завершена успешно ошибок не обнаружено
Контейнер закрытого ключа пользователя
Имя b051432a-d2df-4eed-8cd7-123feaa3a393
Уникальное имя SCARDrutoken_lt_3f5461a4A00AF21
FQCN \.Aktiv Rutoken lite 0b051432a-d2df-4eed-8cd7-123feaa3a393
Проверка целостности контейнера успешно
Ключ обмена доступен
длина ключа 512 бит
экспорт открытого ключа успешно
вычисление открытого ключа успешно
импорт открытого ключа успешно
подпись успешно
проверка успешно
создание ключа обмена успешно
экспорт ключа запрещен
алгоритм ГОСТ Р 34.10-2012 DH 256 бит
ГОСТ Р 34.10 256 бит, параметры обмена по умолчанию
ГОСТ Р 34.11-2012 256 бит
ГОСТ 28147-89, параметры шифрования ТК26 Z
сертификат в контейнере соответствует закрытому ключу
имя сертификата ООО “ГРИФОН”
субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=”ул. Поляковское шоссе, д. 17″, O=”ООО “”ГРИФОН”””, OU=615401001, CN=”ООО “”ГРИФОН”””
поставщик E=uc@nalog.ru, ОГРН=1047707030513, ИНН=007707329152, C=RU, S=77 Москва, L=г. Москва, STREET=”ул. Неглинная, д. 23″, OU=УЦ ЮЛ, O=Федеральная налоговая служба, CN=Федеральная налоговая служба
действителен с 25 февраля 2022 г. 12:32:50
действителен по 25 мая 2023 г. 12:42:50
ключ действителен с 25 февраля 2022 г. 12:32:50
ключ действителен по 25 мая 2023 г. 12:32:50
серийный номер 7714 A000 47AE 739B 4C8E 244E 3E2D 4903
сертификат в хранилище My
субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=”ул. Поляковское шоссе, д. 17″, O=”ООО “”ГРИФОН”””, OU=615401001, CN=”ООО “”ГРИФОН”””
cсылка на закрытый ключ SCARDrutoken_lt_3f5461a4A00AF21; Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider#80; dwFlags: 0x00000000; dwKeySpec: AT_KEYEXCHANGE#1
AddressBook
субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=”ул. Поляковское шоссе, д. 17″, O=”ООО “”ГРИФОН”””, OU=615401001, CN=”ООО “”ГРИФОН”””
cсылка на закрытый ключ отсутствует
cрок действия закрытого ключа 25 мая 2023 г. 12:32:50
использование ключа обмена разрешено до окончания срока действия закрытого ключа.
Ключ подписи отсутствует
Симметричный ключ отсутствует
Загрузка ключей успешно
Версия контейнера 2
Значение ControlKeyTimeValidity 1
Режим работы CSP библиотека
Расширения контейнера
некритическое Расширение контейнера КриптоПро CSP. Срок действия ключа обмена
действителен по 25 мая 2023 г. 12:55:03

Александр Лавник

В Рутокен Lite по умолчанию пин-код “12345678”.

Попробуйте добавить строку:

в секцию [https] конфигурационного файла stunnel, после этого перезапустите службу stunnel и проверьте.

wraithik

2022.02.25 19:02:36 LOG5[5492:4976]: try to read the client certificate
2022.02.25 19:02:36 LOG7[5492:4976]: open file c:stunnelcert.cer with certificate
2022.02.25 19:02:36 LOG5[5492:4976]: pincode option is present. Call CryptSetProvParam
2022.02.25 19:02:36 LOG3[5492:4976]: CryptAcquireCertificatePrivateKey failed. Error = 0x8009001a
2022.02.25 19:02:36 LOG3[5492:4976]: Error creating credentials
2022.02.25 19:02:36 LOG5[5492:4976]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2022.02.25 19:02:36 LOG7[5492:4976]: free Buffers
2022.02.25 19:02:36 LOG5[5492:4976]: incomp_mess = 0, extra_data = 0
2022.02.25 19:02:36 LOG7[5492:4976]: https finished (0 left)

wraithik

Добрый день.
Ваш специалист может подключится по удаленке и помочь решить вопрос?

Александр Лавник

Автор: wraithik

Добрый день.
Ваш специалист может подключится по удаленке и помочь решить вопрос?

Если вопрос еще актуален, то напишите в ЛС – согласуем время подключения.

Дмитрий Масленников

Добрый день. аналогичную ошибку выводит. вам удалось решить вопрос??

Александр Лавник

Автор: Дмитрий Масленников

Добрый день. аналогичную ошибку выводит. вам удалось решить вопрос??

По данному вопросу с вами общается по e-mail наш специалист (обращение № 47954).

Aleksander_P

Добрый день!
Аналогичная проблема возникла, при это 1,5-2 месяца работало, теперь выходит
2022.05.19 12:16:58 LOG5[4664:12776]: try to read the client certificate
2022.05.19 12:16:58 LOG7[4664:12776]: open file C:stunnelclicer.cer with certificate
2022.05.19 12:16:58 LOG3[4664:12776]: **** Error 0x80090304 returned by AcquireCredentialsHandle
2022.05.19 12:16:58 LOG3[4664:12776]: Credentials complete
2022.05.19 12:16:58 LOG3[4664:12776]: Error creating credentials
как решили данную проблему?

eugenimur

Добрый день! Все работало, поменяли сертификат в налоговой. выводило такую же ошибку. Прописал пин в конфигурационный файл. Теперь выдает 2022.08.22 16:03:50 LOG7[76200:71916]: open file C:stunnelclicer.cer with certificate
2022.08.22 16:03:50 LOG5[76200:71916]: pincode option is present. Call CryptSetProvParam
2022.08.22 16:03:50 LOG3[76200:71916]: CryptAcquireCertificatePrivateKey failed. Error = 0x80090016
2022.08.22 16:03:50 LOG3[76200:71916]: Error creating credentials
2022.08.22 16:03:50 LOG5[76200:71916]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2022.08.22 16:03:50 LOG7[76200:71916]: free Buffers
2022.08.22 16:03:50 LOG5[76200:71916]: incomp_mess = 0, extra_data = 0
2022.08.22 16:03:50 LOG7[76200:71916]: https finished (0 left)

Андрей *

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

Где контейнер,
результаты тестирования через панель управления…?

eugenimur

Контейнер на рутокене
Проверка завершена успешно ошибок не обнаружено
Контейнер закрытого ключа пользователя
имя 39c2cdf1-1d5e-4259-bff9-135a83e95ade
уникальное имя SCARDrutoken_lt_3f1b7625B00F3FE
FQCN \.Aktiv Rutoken lite 039c2cdf1-1d5e-4259-bff9-135a83e95ade
проверка целостности контейнера успешно
Ключ обмена доступен
длина ключа 512 бит
экспорт открытого ключа успешно
вычисление открытого ключа успешно
импорт открытого ключа успешно
подпись успешно
проверка успешно
создание ключа обмена успешно
экспорт ключа запрещен
алгоритм ГОСТ Р 34.10-2012 DH 256 бит
ГОСТ Р 34.10 256 бит, параметры обмена по умолчанию
ГОСТ Р 34.11-2012 256 бит
ГОСТ 28147-89, параметры шифрования ТК26 Z
сертификат в контейнере соответствует закрытому ключу
сертификат в хранилище My
ИНН ЮЛ=3306004329, СНИЛС=01933032319, ОГРН=1023300712621, ИНН=330600658180, C=RU, S=33 Владимирская область, L=КОЛЬЧУГИНО Г, STREET=”ЛЕНИНА ПЛ, 6″, O=”ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “”ШАНС”””, CN=”ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “”ШАНС”””, T=ГЕНЕРАЛЬНЫЙ ДИРЕКТОР, G=ТАМАРА АРКАДЬЕВНА, SN=МОЧАЛОВА
SCARDrutoken_lt_3f1b7625B00F3FE; Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider#80; dwFlags: 0x00000000; dwKeySpec: AT_KEYEXCHANGE#1
имя сертификата ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “ШАНС”
субъект ИНН ЮЛ=3306004329, СНИЛС=01933032319, ОГРН=1023300712621, ИНН=330600658180, C=RU, S=33 Владимирская область, L=КОЛЬЧУГИНО Г, STREET=”ЛЕНИНА ПЛ, 6″, O=”ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “”ШАНС”””, CN=”ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “”ШАНС”””, T=ГЕНЕРАЛЬНЫЙ ДИРЕКТОР, G=ТАМАРА АРКАДЬЕВНА, SN=МОЧАЛОВА
поставщик ИНН ЮЛ=7707329152, E=uc@tax.gov.ru, ОГРН=1047707030513, C=RU, S=77 Москва, L=г. Москва, STREET=”ул. Неглинная, д. 23″, O=Федеральная налоговая служба, CN=Федеральная налоговая служба
действителен с 15 августа 2022 г. 11:33:12
действителен по 15 ноября 2023 г. 11:43:12
ключ действителен с 15 августа 2022 г. 11:33:12
ключ действителен по 15 ноября 2023 г. 11:33:12
серийный номер 01E7 B38F 00F2 AE17 8448 5840 AA40 CF38 99
лицензия 449 дней
Срок действия закрытого ключа 15 ноября 2023 г. 11:33:12
Использование ключа обмена разрешено до окончания срока действия закрытого ключа.
Ключ подписи отсутствует
загрузка ключей успешно
Версия контейнера 2
Расширения контейнера
некритическое Расширение контейнера КриптоПро CSP. Срок действия ключа обмена
действителен по 15 ноября 2023 г. 11:44:08

Errors

  • 80090302
  • 8009030D
  • 8009030E
  • 80090304
  • 80090308
  • 80090325
  • 80090326
  • 80090327
  • 80090331
  • 8009035D
  • 8009030F and 80090321

This error can occur when the component is using an older version of TLS, but the server requires a newer version. For instance if the component is using TLS 1.0, but the server requires TLS 1.2, you can see this error. Older versions of the components may not have the newer protocols enabled by default. In the current versions TLS 1.2 is enabled by default.

Possible Solutions

This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this

Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.

This error is often seen when using PEM keys, and translates to “The credentials supplied to the package were not recognized”.

Possible Solutions

Using OpenSSL, the certificate can be converted with the command:

openssl pkcs12 -export -passout pass:”” -in cert_key_pem.txt -out cert_key_out.pfx -name “My Certificate”

Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.

  • Ensure the Network Service account has access to “C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSA.”
  • If using a certificate from a Windows certificate store verify the certificate was imported wit the “Mark this key as exportable” option checked.
  • If you are running the components from IIS, ensure that the Application Pool has Load User Profile set to true.

    • This error translates to “No credentials are available in the security package”.

    Possible Solutions

    This error translates to “The Local Security Authority cannot be contacted “.

      This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200 .

    After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.

  • Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

    • This error translates to “The token supplied to the function is invalid “.

    Possible Causes

    Also see this Knowledge Base article about this error: SSL: Error During Handshake: 80090308

    This error translatest to “The certificate chain was issued by an authority that is not trusted.”

    The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.

    This error translates to “The message received was unexpected or badly formatted.”

    Possible Solutions

    In ThreeDSecure, this error is typically related to a problem with client authentication.

    This error translates to “An unknown error occurred while processing the certificate.”

    This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.

    This error translates to “The client and server cannot communicate, because they do not possess a common algorithm”.

    Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn’t support the newer ciphers required by the server. Here is a list of ciphers supported in XP.

    This error translates to “One or more of the parameters passed to the function was invalid.”

    Possible Solutions

    After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.
    The below Windows updates have been known to cause the issue:

    • KB3172605
    • KB3175024
    • KB3177186
    • KB3184122
    • KB3185911
  • Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

    • These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:

    The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.

    Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:

    • Use our internal security API by passing the string “UseInternalSecurityAPI=True” to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
    • Disable the two cipher suites mentioned above
    • Disable support for TLS 1.2
    • Upgrade your machine to a newer version of Windows

    Источник

    Источник


    17 мая 2019 08:48 #12252
    от YFNS5611

    Ошибка получения сертификата из хранилища: Объект или свойство не найдено (0х80092004)
    Хотим подписать заявку на кассовый расход. Сертификат лежит на USB носителе, установлен , скрины прилагаю (на последнем попробовал в IE). По мимо этого у нас еще один есть и он все подписывает без проблем. Я так понимаю проблема с самим сертификатом ? или что-то не туда установил?!

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    17 мая 2019 09:05 — 17 мая 2019 09:08 #12254
    от Gvinpin

    YFNS5611 пишет: или что-то не туда установил?!

    Или не установил.
    Такая ошибка бывает, когда некорректно установлен(ы) сертификат пользователя и/или корневые сертификаты.
    Сертификат новый? Установлены ли корневые сертификаты для ГОСТ-2012? При просмотре сертификата пользователя корневые без крестов?

    ______________________________
    Лучше уже было (c)

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    17 мая 2019 09:30 #12255
    от YFNS5611

    Вообще нет проблем. Может быть сам сертификат корявый? ведь другой — то подписывает без проблем на этой же машине

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    17 мая 2019 09:45 — 17 мая 2019 09:49 #12256
    от Alex67

    Ещё раз обращаем внимание: если у вас установлен Континент АП 3.7 с криптопровайдером от Кода Безопасности следует удалить в реестре следующие строки:

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 1CryptDllImportPublicKeyInfoEx1.2.643.7.1.1.1.1
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftCryptographyOIDEncodingType 1CryptDllImportPublicKeyInfoEx1.2.643.7.1.1.1.1

    «Кто людям помогает — лишь тратит время зря. Хорошими делами прославиться нельзя» (с) Шапокляк

    Спасибо сказали: ranger

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    17 мая 2019 09:49 #12257
    от Gvinpin

    YFNS5611 пишет: Вообще нет проблем. Может быть сам сертификат корявый? ведь другой — то подписывает без проблем на этой же машине

    Попробуйте удалить сертификат из хранилища и потом установить его заново.
    Судя по скрину, сертификат прошлогодний. Раз есть подозрения на его счет, то раньше им не подписывали? Проверьте, все ли полномочия АСФК в нем есть (хотя бы сравните с другим).

    ______________________________
    Лучше уже было (c)

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    17 мая 2019 10:11 #12258
    от YFNS5611

    Все спасибо. Пока бунт не поднял никто мне не сказал, что им дали новый сертификат по 2012 ГОСТУ. Все работает.

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    08 нояб 2021 11:27 #19455
    от manager15

    Извините что влезаю, но какая разница по какому ГОСТу выпущен сертификат? Я имею в виду что данная ошибка никак не связана с ГОСТом, ведь эцп по 2001 ГОСТу уже никто не выпускает…Все что требуется для решения данной проблемы — это переустановить КриптоПро CSP, предварительно удалив программу через панель управления, затем запустить утилиту удаления cspclean, которую вы можете скачать с официального сайта КриптоПро. После удаления нужно заново установить программу и попробовать снова

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    08 нояб 2021 12:18 #19459
    от ranger

    manager15 пишет: Извините что влезаю, но какая разница по какому ГОСТу выпущен сертификат?

    Так вы этот вопрос задайте Коду Безопасности и КриптоПро

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


    09 нояб 2021 09:54 — 09 нояб 2021 09:58 #19462
    от Alex_04

    manager15 пишет: Извините что влезаю…

    Да не, всё путём. :) Ну если не считать один пустяк — Вы слегка запоздали (на 2,5 годика буквально) с размышлениями о ГОСТах… ;)

    «Мы будем жить плохо, но недолго.» (© Черномырдин В.С.)

    Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

    Источник

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

    Ошибка установки свойства в контекст сертификата. Ошибка получения свойства сертификата. Объект или свойство не найдено. (0х80092004) В связи с этим использование выбранного сертификата невозможно.

    Причины возникновения

    Ошибка 0x80092004 была вызвана неправильной установкой одного из обновлений (KB4340558), касающегося программы .NET Framework, специальной платформы для создания и совместимости различных приложений.

    Обновление затрагивало версии .NET Framework от 3.5 и до 4.7.1. Ошибка замечена на Windows Server 2012, а также в другой версии 8.1.

    Это обновление затрагивало важные аспекты безопасности платформы. Обновление KB4340558 было призвано решить три критических проблемы:

    1. CVE-2018-8284 — остановить возможность запуска вредоносного кода на машине пользователя;
    2. CVE-2018-8202 — устранить возможность получения более высоких привилегий;
    3. CVE-2018-8356 — исключить ошибку, связанную с некорректной проверкой действующих сертификатов.

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

    Компания постоянно работает над устранением самых критических уязвимостей. Например, летом 2018 года (в июле) компании пришлось исправить более 53 ошибок и найденных уязвимостей в более, чем 15-ти различных продуктах ОС Windows.

    Методы решения

    Способ устранения 1

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

    • удалить следующие обновления: KB4229727 и KB4096417 (Win + X → Панель управления → Центр обновления Windows → Установленные обновления (см внизу в левом углу) → выбрать из списка нужные обновления и удалить их;
    • затем необходимо открыть командную строку с правами администратора (Win + X), выбрать пункт «Командная строка (администратор)»;
    • запустить команду — Dism /Online /NoRestart /Cleanup-Image /StartComponentCleanup;
    • перезагрузить ОС.

    Этот способ может ликвидировать проблему. Если все же не получилось, тогда необходимо попробовать второй способ.

    Способ устранения 2

    Компания Microsoft предлагает следующее решение проблемы:

    • убрать накопительные обновления под номерами KB4291497 или KB4291495;
    • запустить очистку системы из командной строки: Dism /Online /NoRestart /Cleanup-Image /StartComponentCleanup;
    • перезагрузить систему и повторить процесс установки обновлений.

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

    Способ устранения 3

    При использовании этой утилиты важно помнить, что запускать ее необходимо под правами администратора:

    1. Зайти по ссылке.
    2. Скачать утилиту TechUtilities_Setup_2.1.9-01-CR.exe (цифры вашей версии могут отличаться).
    3. Запустить приложение.
    4. Нажать кнопку Scan.
    5. Если ошибки найдены, нажать кнопку «Fix All».

    Как можно заметить, способов устранения «error code: 0x80092004» достаточно. В настоящее время компания Microsoft выпустила обновление, исправляющее эту ошибку, а также закрывающую выявленные проблемы в безопасности.

    Установка обновлений вручную

    Для того, чтобы установить обновления вручную, необходимо:

    • выйти на официальный сайт загрузки обновлений по ссылке
    • в строке поиска найти необходимое обновление;
    • выбрать необходимое обновление, а затем нажать кнопку «Загрузить и установить».

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

    Источник

    Источник

    On an RDSH server running Windows Server 2016, the following certificate is installed:

    • Issued by: COMODO RSA Domain Validation Secure Server CA
    • Issued to: *.internal.<Internet domain name>
    • Valid from: 2017/07/18
    • Valid to: 2018/07/19
    • SHA-1 thumbprint: ‎02 e5 52 95 aa 2d 9f a5 fb ad 82 97 0e 66 5d a9 73 db 00 ca
    • Private key: Yes

    We need to sign an RDP file using the above certificate and research strongly suggests using rdpsign.

    I executed command rdpsign -? which ouputted the following:

    NAME

rdpsign [options] [items to sign]

OPTIONS

  /sha256 HASH
       Specified the SHA256 hash of the signing certificate.
  /q
       Quiet mode:  No output when success, minimal output when failed.
  /v
       Verbose mode:  Display all warnings, messages, and status.
  /l
       Test signing and output results without actually replacing any of the inputs.  Ignores when input files are on stdin.


All rdp file(s) have been succesfully signed.

    So, contrary to the official, now-outdated documentation, rdpsign requires the certificate’s SHA-256 hash.

    However, IIS Manager and Certificate Manager only offer certificates’ SHA-1 thumbprints.

    https://knowledge.symantec.com/support/identity-protection-support/index?page=content&id=SO28771&actp=RSS&viewlocale=en_US advises that OpenSSL can be used to obtain a certificate’s various hashes, including SHA-256.

    I exported the certificate without its private key to a base-64 encoded X.509 CER file.

    I executed command openssl x509 -noout -fingerprint -sha1 -inform pem -in <file name>.cer which ouputted the following: 

    SHA1 Fingerprint=02:E5:52:95:AA:2D:9F:A5:FB:AD:82:97:0E:66:5D:A9:73:DB:00:CA

    So, we can be confident that OpenSSL is outputting accurate information because the SHA-1 thumbprints match.

    I executed command openssl x509 -noout -fingerprint -sha256 -inform pem -in <file name>.cer which ouputted the following: 

    SHA256 Fingerprint=D7:44:A5:BA:94:56:B0:9F:26:D2:2B:88:92:84:11:74:35:23:71:87:30:FD:CE:D0:B1:35:6B:D8:DA:A6:A1:7B

    I executed elevated (run as administrator) commands rdpsign /sha256 D744A5BA9456B09F26D22B88928411743523718730FDCED0B1356BD8DAA6A17B <file name>.rdp /v, rdpsign /sha256 "D744A5BA9456B09F26D22B88928411743523718730FDCED0B1356BD8DAA6A17B" <file name>.rdp /v, and rdpsign /sha256 d744a5ba9456b09f26d22b88928411743523718730fdced0b1356bd8daa6a17b <file name>.rdp /v all of which outputted the following: 

    Unable locate the certificate specified.  Error Code: 0x80092004
The rdp file could not be signed.  Error Code: 0x80092004

    I’ve found that there’s hardly anything relevant online for this problem. Can anyone advise?

    Источник
    • Remove From My Forums

    • Question

    • I have been trying to Install the Client via the Push method.  On the machine that is targeted, I see ConfigMgr Task Sequence Agent and Configuration Manager Remote Control in Services but are disabled, and under services in Task Manager there is a
      ccmsetup that is listed at Stopped.

      Here is what I see from the ccm.log when I try the push:

      ======>Begin Processing request: «2097152024», machine name: «DOMAIN-LT25» SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      Execute query exec [sp_IsMPAvailable] N’PHL’ SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Trying the ‘best-shot’ account which worked for previous CCRs (index = 0x0) SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Attempting to connect to administrative share ‘\DOMAIN-LT25admin$’ using account ‘DOMAINClientInstall’ SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> The ‘best-shot’ account has now succeeded 1 times and failed 0 times. SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Connected to administrative share on machine DOMAIN-LT25 using account ‘DOMAINClientInstall’ SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Attempting to make IPC connection to share <\DOMAIN-LT25IPC$> SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Searching for SMSClientInstall.* under ‘\DOMAIN-LT25admin$’ SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> System OS version string «6.1.7601» converted to 6.10 SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Mobile client on the target machine has the same version, and ‘forced’ flag is turned on. SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Creating VerifyingCopying exsistance of destination directory
      \DOMAIN-LT25admin$ccmsetup. SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Copying client files to \DOMAIN-LT25admin$ccmsetup. SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Copying file «D:Program FilesMicrosoft Configuration ManagerbinI386MobileClient.tcf» to «MobileClient.tcf» SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:05 AM 5428 (0x1534)
      —> Copying file «D:Program FilesMicrosoft Configuration ManagerbinI386ccmsetup.exe» to «ccmsetup.exe» SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      —> Updated service «ccmsetup» on machine «DOMAIN-LT25». SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      —> Started service «ccmsetup» on machine «DOMAIN-LT25». SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      —> Deleting SMS Client Install Lock File ‘\DOMAIN-LT25admin$SMSClientInstall.PHL’ SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      Execute query exec [sp_CP_SetLastErrorCode] 2097152024, 0 SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      —> Completed request «2097152024», machine name «DOMAIN-LT25». SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      Deleted request «2097152024», machine name «DOMAIN-LT25» SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152024, 4 SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      Execute query exec [sp_CP_SetLatest] 2097152024, N’07/05/2012 14:41:06′, 7 SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)
      <======End request: «2097152024», machine name: «DOMAIN-LT25». SMS_CLIENT_CONFIG_MANAGER 7/5/2012 10:41:06 AM 5428 (0x1534)

      The line that I used BOLD and ITALIC on is highlighted RED.

    Answers

      • Proposed as answer by

        Tuesday, May 7, 2013 10:28 PM

      • Edited by
        Cristiano Fernandes
        Tuesday, May 7, 2013 10:28 PM
      • Marked as answer by
        Robert Marshall — MVPMVP
        Saturday, June 1, 2013 6:13 PM
    Источник

    Offline

    smd44

     


    #1
    Оставлено
    :
    20 октября 2022 г. 18:18:46(UTC)

    smd44

    Статус: Участник

    Группы: Участники

    Зарегистрирован: 10.10.2022(UTC)
    Сообщений: 20

    Сказал(а) «Спасибо»: 4 раз

    Я подписываю документ усиленной подписью CADES_X_LONG_TYPE_1, сертификат установлен на моей машине. Проверка подписи в КриптоПро происходит успешно.
    При попытке проверить эту подпись на другом компьютере также через через КриптоПро, подпись видна, но вываливается ошибка 0x80092004: Объект или свойство не найдено.
    Если я удаляю сертификат у себя, ошибка воспроизводится.
    Возможно сделать, чтобы проверка происходила успешно без установки сертификата субъекта?

    Пример подписи:
    test_signed_extended.txt (23kb) загружен 4 раз(а).

    Вверх

    Offline

    Андрей *

     


    #2
    Оставлено
    :
    20 октября 2022 г. 20:04:10(UTC)

    Андрей *

    Статус: Сотрудник

    Группы: Участники

    Зарегистрирован: 26.07.2011(UTC)
    Сообщений: 11,756
    Мужчина
    Российская Федерация

    Сказал «Спасибо»: 451 раз
    Поблагодарили: 1840 раз в 1423 постах

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

    Техническую поддержку оказываем тут
    Наша база знаний


    Вверх

    WWW

    Offline

    smd44

     


    #3
    Оставлено
    :
    21 октября 2022 г. 10:12:14(UTC)

    smd44

    Статус: Участник

    Группы: Участники

    Зарегистрирован: 10.10.2022(UTC)
    Сообщений: 20

    Сказал(а) «Спасибо»: 4 раз

    .

    Отредактировано пользователем 21 октября 2022 г. 10:19:48(UTC)
     | Причина: Не указана

    Вверх

    Offline

    smd44

     


    #4
    Оставлено
    :
    21 октября 2022 г. 10:45:05(UTC)

    smd44

    Статус: Участник

    Группы: Участники

    Зарегистрирован: 10.10.2022(UTC)
    Сообщений: 20

    Сказал(а) «Спасибо»: 4 раз

    Насколько я понял, сертификат подписчика передается в функцию открытия дескриптора сообщения CadesMsgOpenToEncode в CMSG_SIGNER_ENCODE_INFO как часть CADES_ENCODE_INFO, в результирующий фал он попадает, данные о подписанте читаемы, но при проверке не находятся КриптоПРо. Пробовал добавить сертификат в CADES_SIGN_PARA при вызове CadesMsgEnhanceSignature, но положительного эффекта это не дало. Я не туда пихаю сертификат или искать проблему в настройках передаваемых структур?

    Вверх

    Offline

    smd44

     


    #5
    Оставлено
    :
    24 октября 2022 г. 16:44:23(UTC)

    smd44

    Статус: Участник

    Группы: Участники

    Зарегистрирован: 10.10.2022(UTC)
    Сообщений: 20

    Сказал(а) «Спасибо»: 4 раз

    Как подписать документ несколькими подписями с добавлением информации о сертификате, чтобы проверка проходила на любой машине с криптопро?
    Если использовать низкоуровневый подход, то непонятно, где добавить информацию о сертификате, если упрощенные функции, то как добавить несколько подписей (и в самом криптопро)?


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

    Guest

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

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

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

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

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

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

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

    Источник

    Понравилась статья? Поделить с друзьями:
  • Findclone не работает general error
  • Find sql syntax error
  • Find set root ignore floppies ignore cd bootmgr error 15
  • Find name driver error c windows system32 drivers delete or move desktop
  • Find error in json at position