I have a .NET client app in C# that uses HttpWebRequest to access resources via https:// on a remote server (this is all running at a customer site). The server is Oracle Weblogic and associated components. The client box runs Windows 7 with .NET 4.0 or
better.
When I compare client logs captured during a successful test run in my dev environment to those obtained during a failed run from the customer site, the key differences during the handshake sequences are:
1) after the initial Send() from the client [lines 4-7], the Receive() gets 5 bytes in both cases [lines 10-11]; in the Success case, I can see a length value of 0x33DB (13275) returned. In the failure case, the length value is 0x0002 (2).
2) Then in the Success case I can see another Receive() entry for those 13275 bytes [lines 13-…] (content appears to be some info about the server cert); but in the failure case only 2 bytes are received in the Receive() and this is where the IllegalMessage
is returned [lines 16-17].
Success:
1 InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = (null), targetName = localhost, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation) 2 InitializeSecurityContext(In-Buffer length=0, Out-Buffer length=115, returned code=ContinueNeeded). 3 Socket#62468121::Send() 4 Data from Socket#62468121::Send 5 00000000 : 16 03 01 00 6E 01 00 00-6A 03 01 55 71 A1 95 EB : ....n...j..Uq... 6 <snip> rest of 115 bytes of client info sent 7 Exiting Socket#62468121::Send() -> Int32#115 8 Socket#62468121::Receive() 9 Data from Socket#62468121::Receive 10 00000000 : 16 03 01 33 DB : ...3. 11 Exiting Socket#62468121::Receive() -> Int32#5 12 Socket#62468121::Receive() 13 Data from Socket#62468121::Receive 14 (printing 1024 out of 13275) 15 00000005 : 02 00 00 4D 03 01 55 71-A1 95 5C EC 58 F2 E1 36 : ...M..Uq...X..6 16 <snip> see rest of the 1024 bytes of the server certificate info
Failure:
1 InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = (null), targetName = ux314d123, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation) 2 InitializeSecurityContext(In-Buffer length=0, Out-Buffer length=161, returned code=ContinueNeeded). 3 Socket#49652976::Send() 4 Data from Socket#49652976::Send 5 00000000 : 16 03 03 00 9C 01 00 00-98 03 03 55 76 D2 E3 C9 : ...........Uv... 6 <snip> rest of 161 bytes of client info sent 7 Exiting Socket#49652976::Send() -> Int32#161 8 Socket#49652976::Receive() 9 Data from Socket#49652976::Receive 10 00000000 : 15 03 01 00 02 : ..... 11 Exiting Socket#49652976::Receive() -> Int32#5 12 Socket#49652976::Receive() 13 Data from Socket#49652976::Receive 14 00000005 : 02 00 : .. 15 Exiting Socket#49652976::Receive() -> Int32#2 16 InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 1bb8dbc0:1b46920, targetName = ux314d123, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation) 17 InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=IllegalMessage).
Finally, the question(s):
Is the 2 byte response from the server the cause of the IllegalMessage return code (guessing this maps to SEC_E_ILLEGAL_MESSAGE)?
What would cause this?
Any diagnostic tips would be greatly appreciated.
Thank you-
Shaun (Oracle)
Shaun Logan — Oracle
Dmitry-G |
|
|
Статус: Участник Группы: Участники
|
Чтобы заработала служба Stunnel Service, конфигурационный файл stunnel.conf следует положить в System32 (использую Win10 64bit), после этого указанная служба этот файл увидит. О чем, правда, ни слова не сказано в инструкции от УЦ ЦБ РФ от 08.11.2022, но зато говорится в мануале на Stunnel, входящем в состав КриптоПро CSP. Однако, ни успешный запуск данной службы, ни рекомендации выше в данной ветке, не избавляют нас от проблемы подключения к обозначенному серверу штампов времени. Все сертификаты должным образом установлены — как в хранилище текущего пользователя (права — админ), так и в хранилище локального компьютера. Установленный в эти хранилища средствами CSP личный сертификат, выданный аккредитованным УЦ БР, расширение «Проверка подлинности клиента (1.3.6.1.5.5.7.3.2)» имеет. Все тесты контейнеров средствами CSP (по каждому из хранилищ) проходят успешно, в свойства промежуточных сертификатов ЦБ РФ соответствующие адреса OCSP добавлены, строка «127.0.0.1 localhost tsp1.ca.cbr.ru» в файл без расширения «C:WindowsSystem32driversetchosts» записана, лицензии на CSP, TSP и OCSP активны… Пробовали и в связке с Крипто АРМ ГОСТ, и в связке с КриптоПро ЭЦП Browser plug-in со страницы https://www.cryptopro.ru…/cades_xlong_sample.html — результат один и тот же. А в результате возникает окно выбора сертификата, а затем окно ввода пароля, но после соответствующих выбора и ввода, подключения все равно не происходит. Предлагаемая выше замена адресов службы времени УЦ ЦБ с «http://tsp1.ca.cbr.ru:10001/tsp/tsp.srf» и «http://tsp2.ca.cbr.ru:10002/tsp/tsp.srf» на «https://tsp1.ca.cbr.ru/tsp/tsp.srf» и «https://tsp2.ca.cbr.ru/tsp/tsp.srf», а также точек распространения списков отзыва на «https://tsp1.ca.cbr.ru/ocsp» и «https://tsp1.ca.cbr.ru/ocsp» ни к чему хорошему не приводит, кроме того, что по понятной причине, вместо того, чтобы использовать канал Stunnel, указанные приложения пытаются подключиться к серверу установки меток времени напрямую. А конкретика следующая: При запуске Stunnel Service от имени текущего пользователя видим следующий лог Stunnel: 2022.12.08 19:00:12 LOG5[3672:17856]: stunnel 4.18 on x86-pc-unknown А при запуске Stunnel Service от имени локальной системы — следующий: 2022.12.08 20:43:02 LOG5[16664:1744]: stunnel 4.18 on x86-pc-unknown Как я уже говорил, все сертификаты (включая личный) установлены средствами CSP, должным образом и корректно. |
 |
|
|
dysha |
|
|
Статус: Новичок Группы: Участники
|
В инструкции УЦ Банка России по настройке stunnel есть требование: Цитата: В свойствах сертификата перейдите на вкладку «Протокол OCSP» и добавьте следующие URL как показано на картинке ниже: Каким образом можно эту настройку сделать на Linux? |
|
|
WWW |
|
ew-mc |
|
|
Статус: Участник Группы: Участники
|
Автор: Dmitry-G Чтобы заработала служба Stunnel Service, конфигурационный файл stunnel.conf следует положить в System32 (использую Win10 64bit), после этого указанная служба этот файл увидит. О чем, правда, ни слова не сказано в инструкции от УЦ ЦБ РФ от 08.11.2022, но зато говорится в мануале на Stunnel, входящем в состав КриптоПро CSP. Однако, ни успешный запуск данной службы, ни рекомендации выше в данной ветке, не избавляют нас от проблемы подключения к обозначенному серверу штампов времени. Все сертификаты должным образом установлены — как в хранилище текущего пользователя (права — админ), так и в хранилище локального компьютера. Установленный в эти хранилища средствами CSP личный сертификат, выданный аккредитованным УЦ БР, расширение «Проверка подлинности клиента (1.3.6.1.5.5.7.3.2)» имеет. Все тесты контейнеров средствами CSP (по каждому из хранилищ) проходят успешно, в свойства промежуточных сертификатов ЦБ РФ соответствующие адреса OCSP добавлены, строка «127.0.0.1 localhost tsp1.ca.cbr.ru» в файл без расширения «C:WindowsSystem32driversetchosts» записана, лицензии на CSP, TSP и OCSP активны… Пробовали и в связке с Крипто АРМ ГОСТ, и в связке с КриптоПро ЭЦП Browser plug-in со страницы https://www.cryptopro.ru…/cades_xlong_sample.html — результат один и тот же. А в результате возникает окно выбора сертификата, а затем окно ввода пароля, но после соответствующих выбора и ввода, подключения все равно не происходит. Предлагаемая выше замена адресов службы времени УЦ ЦБ с «http://tsp1.ca.cbr.ru:10001/tsp/tsp.srf» и «http://tsp2.ca.cbr.ru:10002/tsp/tsp.srf» на «https://tsp1.ca.cbr.ru/tsp/tsp.srf» и «https://tsp2.ca.cbr.ru/tsp/tsp.srf», а также точек распространения списков отзыва на «https://tsp1.ca.cbr.ru/ocsp» и «https://tsp1.ca.cbr.ru/ocsp» ни к чему хорошему не приводит, кроме того, что по понятной причине, вместо того, чтобы использовать канал Stunnel, указанные приложения пытаются подключиться к серверу установки меток времени напрямую. А конкретика следующая: Как я уже говорил, все сертификаты (включая личный) установлены средствами CSP, должным образом и корректно. Добрый день, коллеги! Но, в файле лога Stunnel говорит, что не видит сертификат локального пользователя: ……… 2022.12.12 15:25:12 LOG3[6960:9356]: Credentials complete Вам удалось найти причину проблемы? |
|
|
|
|
ew-mc |
|
|
Статус: Участник Группы: Участники
|
Автор: Orgia коллеги, а если туннель вообще не запускается служба? c:Stunnel>sc config stunnel start= auto & net start stunnel A system error has occurred. System error 1067 has occurred. The process terminated unexpectedly. сталкивался кто? Версия криптопровайдера: 5.0.12000 сталкивался кто? Мы сталкивались с такой же ошибкой 1067 при попытке запустить службу Stunnel Service. Метод лечения: |
|
|
|
|
Dmitry-G |
|
|
Статус: Участник Группы: Участники
|
Добрый день, коллеги! Однако, как выяснилось, основная причина происходящего была скрыта в настройках нашего firewall. Пару часов назад нам удалось получить корректный ответ с метками времени от сервера АУЦ БР на компе, который смотрел в инет напрямую, причем, без особых заморочек с настройками и с применением стандартного stunnel.conf в варианте от АУЦ БР. Отредактировано пользователем 13 декабря 2022 г. 14:48:11(UTC) |
|
|
|
|
ИгорьК |
|
|
Статус: Участник Группы: Участники
|
у нас все запускается странная ошибка в логе Есть мысли (с ЦБ уже несколько дней переписываемся — ничего не помогает, и антивирус отключали и firewall тоже…)? 2022.12.13 16:39:27 LOG7[5204:1296]: !!!!!Call s_poll_wait with timeout = -1 ((sock_rd && ssl_rd)=1) c->ssl_ptr = f1d c->sock_ptr=0 |
|
|
|
|
Dmitry-G |
|
|
Статус: Участник Группы: Участники
|
Да, признаю, как выяснилось, на машине с прямым инетом у нас все заработало лишь потому, что машина была новая и в личных у нее был всего лишь один сертификат — как раз тот сертификат, который требовался Stunnel для установки соединения. Когда же в справочнике имеются прочие личные сертификаты, в конфигурации Stunnel обязательно нужно указывать конкретно к какому сертификату из установленных обращаться. Как это сделать, подробно с примерами написано в мануале на Stunnel, входящем в состав КриптоПро CSP. Так что ИгорьК прав — антивирус и firewall тут оказались ни при чём. К сказанному также добавлю следующее: A. Где-то в ветках данного форума кем-то было озвучено, что указанный сертификат следует выгружать в файловую систему из справочника КриптоПро CSP, а не класть его туда методом копирования. В этом случае якобы в него (или в Stunnel) каким то образом добавляется ссылка на закрытый ключ, которую понимает Stunnel. В общем, сложно сказать, что это за ссылка, куда и как она добавляется, но в нашем случае оказалось, что это работает. Так что автору идеи, большое спасибо. Эксперименты с подключением рекомендуем вначале проводить без пароля на контейнер с ключом. B. Также выяснилось, что в процессе своей работы, служба Stunnel Service (при запуске от имени локальной системы) обращается к обозначенному личному сертификату в хранилище локального компьютера, а КриптоПро ЭЦП Browser plug-in — к такому же сертификату, лежащему в хранилище текущего пользователя. Так что по крайней мере на этапе тестирования, лучше добавлять соответствующую цепочку (с требуемыми настройками адресов OCSP в свойствах сертификатов БР) в оба эти хранилища. C. Ну и еще, пожалуй, добавлю официальный ответ техподдержки БР по данному вопросу. Нам он, правда, в итоге не помог, но может кому будет полезно: Просим проверить выполнение следующих шагов: Отредактировано пользователем 14 декабря 2022 г. 13:23:48(UTC) |
|
|
|
|
ИгорьК |
|
|
Статус: Участник Группы: Участники
|
Попробовал через браузер в логе те же самые Вот браузер выдал: Запрошенный URL не может быть получен The system returned: [No Error] (TLS code: SQUID_TLS_ERR_CONNECT+TLS_LIB_ERR=1421C0F8+TLS_IO_ERR=1) Для выполнения Вашего запроса этот кэш и удаленный узел не смогли согласовать взаимоприемлемые параметры безопасности. |
|
|
|
|
ew-mc |
|
|
Статус: Участник Группы: Участники
|
Добрый вечер, коллеги! Параметры при которых было успешное подписание Dmitry-G, я не нашел в мануале по Stunnel от КриптоПРО подробное описание с примерами указания пути к конкретному сертификату… P.S. Да, антивирус и firewall не при чем. И права админа не влияют на успех подписания. Отредактировано пользователем 14 декабря 2022 г. 16:19:59(UTC) |
|
|
|
|
ИгорьК |
|
|
Статус: Участник Группы: Участники
|
Да, у нас на новой чистой машине тоже заработало, когда в Личном только один сертификат пробовал явно указать в конфиге сертификат (cert = c:stunnelmyCert.cer) |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Содержание
- Common Windows Security Errors
- Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
- Errors
- 0x80090302
- Possible Solutions
- 0x8009030D
- Possible Solutions
- 0x8009030E
- Possible Solutions
- 0x80090304
- 0x80090308
- Possible Causes
- 0x80090325
- 0x80090326
- Possible Solutions
- 0x80090327
- 0x80090331
- 0x8009035D
- Possible Solutions
- 0x8009030F or 0x80090321
- Веб — сервис интеграции
- Stunnel error 0x8009035d returned by initializesecuritycontext 2
- Описание ошибки 0x8009030D
- Устранение ошибки ID 36870
- Как предоставить права на сертификат
- Сброс разрешения для папки MachineKeys
- Где хранится самоподписный сертификат в реестре
- Stunnel error 0x8009035d returned by initializesecuritycontext 2
Common Windows Security Errors
Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
Date Entered: 06/10/2015 Last Updated: 04/09/2018
Errors
0x80090302
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.
0x8009030D
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.
0x8009030E
Possible Solutions
0x80090304
- 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.
0x80090308
Possible Causes
0x80090325
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.
0x80090326
Possible Solutions
0x80090327
This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.
0x80090331
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.
0x8009035D
Possible Solutions
0x8009030F or 0x80090321
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:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
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
Источник
Веб — сервис интеграции
Уважаемый участник рынка ДМДК!
Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».
Доброго времени суток!
Установил обезличенный сертификат.
в 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
кто-то сталкивался с таким?
буду благодарен за помощь!
Источник
Stunnel error 0x8009035d returned by initializesecuritycontext 2
Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами устраняли ошибку подключения «Код ошибки 0x907. Расширенный код ошибки 0x0». В сегодняшней статье мы рассмотрим еще одну ошибку RDP, которая не дает людям любые подключения «Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки«. Данную проблему я стал получать массово в декабре 2022. Давайте покажу куда нужно смотреть.
Описание ошибки 0x8009030D
У меня есть RDS ферма состоящая из 50 RDSH хостов, в какой-то момент люди начали массово на двух хостах получать ошибку «An internal error has occurred». Я долго искал проблему, и таки отыскал ее.
Ей оказалась ошибка появляющаяся каждый раз при попытке подключения ID Schannel 36870:
Вот так это массово выглядит.
В 99% случаев у вас просто не хватает прав на доступ к нужному SSL сертификату, который используется при RDP сессии.
Устранение ошибки ID 36870
Как я и писал ранее, чтобы убрать ошибку 0x907, я на всех участниках RDS ферму, установил нормальный Wildcard сертификат. Все стало нормально. Но, то что теперь я стал получать ошибку с кодом 0x8009030D, стало означать, с проблемой прав доступа к файлу. То есть у учетной записи NETWORK SERVICE отсутствуют разрешения на файл в C:ProgramDataMicrosoftCryptoRSAMachineKey.
Каталог MachineKeys хранит пары ключей сертификатов для пользователей и компьютеров. Эта папка используется службами сертификации и Internet Explorer, другими браузерами. В этой директории и в ее поддиректориях размещаются файлы, связанные с сертификатами и ключами контейнерами.
Для того чтобы понять, что происходит я вам советую скачать утилиту из пакета Sysinernals под названием Process Monitor.
- ✅Далее делаем себе фильтр по событию 36870, чтобы мониторить его появление
- ✅И запускаем Procmon.exe или Procmon64.exe, чтобы спарсить текущие события. Как только событие появилось, вам нужно остановить захват (CTRL+E) и сохранить этот лог в CSV файл.
Далее вам нужно поискать события подобные этому:
Как видно, учетная запись NETWORK SERVICE не смогла прочитать ключ eed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564.
Как предоставить права на сертификат
- ✅Нажмите сочетание клавиш Win+R и вызовите оснастку mmc.
Далее Вам нужно нажать CTR:+M. Найдите оснастку «Сертификаты» и переместите ее вправо. Там выберите пункт «Учетной записи компьютера«.
Кажем, что это будет локальный компьютер, но можно сделать и удаленного, если нет доступа по RDP.
Найдите в личном контейнере компьютера, нужный сертификат, который используется при подключении. В контекстном меню выберите пункт «Управление закрытыми ключами«.
Далее в открывшемся ACL вам нужно дать права чтения для NETWORK SERVICE.
- ✅Второй метод, это использовать утилиту командной строки:
Примечание: вам может потребоваться стать владельцем файла, если вы не можете изменить его разрешения.
На этом у меня все. Ошибку я устранил, уровень защищенности сохранил. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.
Сброс разрешения для папки MachineKeys
Для сброса разрешений на данную папку, выполните в консоли в режиме администратора.
icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempBeforeScript_permissions.txt
takeown /f «C:ProgramDataMicrosoftCryptoRSAMachineKeys» /a /r
icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYSystem:(F)»
icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYNETWORK SERVICE:(R)»
icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «BUILTINAdministrators:(F)»
icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempAfterScript_permissions.txt
Где хранится самоподписный сертификат в реестре
Это больше для себя, где лежит отпечаток сертификата:
Источник
Stunnel error 0x8009035d returned by initializesecuritycontext 2
Важное замечание: Если ОС Windows используется в качестве клиента КриптоПро HSM 2.0 и ключ доступа к HSM записан на смарткарте или токене, то не рекомендуется подключение к этой ОС Windows по RDP, поскольку локально подключенные к компьютеру с ОС Windows считыватели смарткарт/токенов не будут доступны в RDP-сессии.
- Диагностика соединения с HSM 2.0
- проверка провайдера
windows : start /b csptest -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info для треевого провайдера, для сервисного необходимо в -provider указывать «Crypto-Pro GOST R 34.10-2012 HSM Svc CSP»
*nix : /opt/cprocsp/bin/АРХИТЕКТУРА/csptestf -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info
должно вернуться [ErrorCode: 0x00000000], иначе см п.2-3
- диагностика с помощью telnet или netcat
доступ к web-странице Администратора:
telnet 443
доступ к каналу К2:
telnet 1501
где это IP адрес HSM 2.0
Причина возможного сбоя: HSM в состоянии Inactive, сетевая проблема или не настроены правила FireWall на HSM 2.0
примечание: на ОС Astra Linux Smolensk 1.5 — 1.6 по умолчанию не установлены пакеты telnet и netcat (можно установить с диска разработчика Astra Linux)
Пример использования:
telnet 192.168.26.2 1501
nc -v 192.168.26.2 1501
- Сервер RPC не доступен
[ErrorCode: 0x000006ba]
Причина: не запущена служба Крипто Про HSM 2.0Указанный тип ресурса в файле образа отсутствует
[ErrorCode: 0x00000715]
Причина: нет доступа к закрытому ключу в реестре локального компьютера
для х64: HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCrypto ProSettingsKeys
для х32: HKEY_LOCAL_MACHINESOFTWARECrypto ProSettingsKeys[ErrorCode: 0x8010002e]
Причина: считыватель отключен или используется RDPТребуемый адрес для своего контекста неверен
[ErrorCode: 0x00002741]
Причина: не указан IP адрес HSM 2.0 в HSM Client[ErrorCode: 0x80090304]
Причина: на контейнер ключевой пары доступа установлен пин-код отличный от 11111111[ErrorCode: 0x800b0109]
Причина: корневой сертификат HSM 2.0 не установлен в хранилище «Доверенные корневые центры сертификации» локального компьютерапри попытке установить соединение из HSM клиента (в трее), после предложения ввести ПИН-код появляется сообщение
«CN-имя сертификата не совпадает с полученным значением»
Причина: не заменен TLS — сертификат Веб-сервера HSM после смены IP адреса HSM
Решение:
1)Необходимо перевыпустить веб-сертификат в режиме Active – update keys – tls server key – change TLS key
2)HSM необходимо переактивировать: Change HSM state – inactive – Full activeна *nix клиенте в логе stunnel имеется строка:
Error 0x80090304 returned by InitializeSecurityContext
Возможные причины: закончилась лицензия на Крипто Про CSP или недоступен закрытый ключ ключевой пары доступа - на *nix клиенте при тестировании ГОСТ TLS имеется строка:
Downgrade container security level?
Решение: необходимо понизить класс защиты контейнера ключевой пары доступа через тестирование контейнера
Пример: /opt/cprocsp/bin/amd64/csptest -keys -check -cont ‘\.Gemalto PC Twin Readercontname’
- на страничке не работают пункты меню и отображается строка вида:
-1 -1 0 0 0 0 0 0 false false false
Причина:
Используется браузер отличный от Internet Explorer или в IP адрес HSM 2.0 не добавлен в «Доверенные узлы» и в «Просмотр в режиме совместимости» браузера Internet ExplorerИсточник
Евгений Пономаренко |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 46 раз |
Добрый день. приложение выполнено как сервис. При запуске сервиса от системного аккаунта или пользователя домена, последний InitializeSecurityContext возвращает SEC_E_DECRYPT_FAILURE (0x80090330). Если запустить как обычное консольное приложение, все работает нормально. |
 |
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Problem
When trying to authenticate / test against an Active Directory Server the following errors will show:
Symptom
Active Directory
1. [ ERROR ] CAM-AAA-0146 The namespace ‘XXX’ is not available.
CAM-AAA-0064 The function ‘CAM_AAA_Configure2’ failed.
CAM-AAA-0089 The provider is not initialized.
CAM-AAA-0036 Unable to authenticate because the credentials are invalid.
ADSI Error:
8009030C:
LdapErr: DSID-0C09043E,
comment: AcceptSecurityContext error,
data 0,
vece
System Error:
Logon failure: unknown user name or bad password.
Cause
There are several potential causes for the same/similar errors.
- TIP: See separate Technote #1588179 for more examples.
This Technote specifically relates to the scenario where Cognos Configuration is configured to use anonymous credentials (i.e. the «Bind Credentials» had been left blank in Cognos Configuration for this namespace) but the Active Directory (AD) domain controller server is configured to not allow anonymous binding.
Environment
The administrator has already checked other typical possible causes, for example:
- The host and port of the ADS are correct.
- It is not a cross forest scenario (Cognos Server and Domain Controller are in the SAME forest)
- The defined ADS is the Domain Controller
Resolving The Problem
Add a valid domain account for the «Bind Credentials» of the namespace definition in Cognos Configuration.
Related Information
[{«Product»:{«code»:»SSEP7J»,»label»:»Cognos Business Intelligence»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»Install and Config»,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»10.2;10.2.1;10.2.1.1;10.2.2″,»Edition»:»All Editions»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]