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
диагностика с помощью 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
1. проверка провайдера
   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

Stunnel error 0x8009035d returned by initializesecuritycontext 2

1) Комментирую строки запуска клиента, в начале main() добавляю код:
System.setProperty(«javax.net.ssl.trustStore», «c:\. \newtrust»);
System.setProperty(«javax.net.ssl.trustStorePassword», «tomcat»);
System.setProperty(«javax.net.ssl.keyStoreType», «FloppyStore»);

Вставляю System.in.read() после старта сервера, просто чтобы он не выгружался.

Во FloppyStore лежит ключ, с ним цепочка длины 2, этот ключ успешно используется сервером IIS. Делаю csptest -tlsc, чтобы проверить работоспособность сервера. Получаю результат:
C:Program FilesCrypto ProCSP>csptest -tlsc -server 127.0.0.1 -port 1357 -proto 4 -v
CSP (Type:71) v3.0.3293 KC1 Release OS:Windows CPU:IA32 FastCode:READY,ENABLED.
CSP (Type:75) v3.0.3293 KC1 Release OS:Windows CPU:IA32 FastCode:READY,ENABLED.
csptest -tlsc -server 127.0.0.1 -port 1357 -proto 4 -v
76 bytes of handshake data sent
1699 bytes of handshake data received
**** Error 0x80090308 returned by InitializeSecurityContext (2)
An error occurred in running the program.
.WebClient.c:417:Error performing handshake.
Error number 57 (87).
Параметр задан неверно.

Total: SYS: 0.016 sec USR: 0.063 sec UTC: 0.250 sec
[ErrorCode: 0x00000001]

То есть сервер из примера не работает, причем симптомы такие же, как у Tomcat. Сам сервер выдает ошибку «Server error:javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake».

2) Наоборот, закомментировал код вызова сервера, остальное байт в байт как в примере. Пытаюсь подключиться к «www.dan.shved» (Это моя машина), на порт 443, который слушает IIS. Получаю ошибку:
. (SSLHandshakeException). PKIX path building failed
at ru.CryptoPro.ssl.G.a(Unknown source)
Caused by: java.security.cert.CertificateException
Caused by: sun.security.provider.certpath.SunCertPathBuilderException

Ну хорошо, мое предположение: сертификат от сервера получен, но проверить его подлинность не удается. Тогда я добавил в начало main() строки:
System.setProperty(«javax.net.ssl.trustStore», «c:\. \newtrust»);
System.setProperty(«javax.net.ssl.trustStorePassword», «tomcat»);

Получаю ошибку:
Exception in thread «main» javax.net.ssl.SSLException: java.lang.RuntimeException: Invalid key exchange
at ru.CryptoPro.ssl.G.a(Unknown Source)
.
Caused by: java.lang.RuntimeException: Invalid key exchange
at ru.CryptoPro.ssl.a.n(Unknown Source)
.
Caused by: java.security.InvalidKeyException: Illegal key size or default parameters
at javax.crypto.Cipher.a(DashoA13*..)
.

3) Пытаюсь запустить весь пример целиком. Ошибки — примерно как в случае 2 (только клиент).
Если не делать System.setProperty(. ), т.е. оставить код как в «руководстве программиста», то сервер говорит:
Server error:javax.net.ssl.SSLHandshakeException: no cipher suites in common,
а клиент:
Exception in thread «main» javax.net.ssl.SSLHandshakeException: Received fatal alert: HANDSHAKE_FAILURE
at ru.CryptoPro.ssl.G.a(Unknown Source)
.

Если же прописать keystore и truststore в System.setProperty(), то сервер говорит:
Server error:javax.net.ssl.SSLException: Received fatal alert: INTERNAL_ERROR
а клиент:
Exception in thread «main» javax.net.ssl.SSLException: java.lang.RuntimeException: Invalid key exchange
at ru.CryptoPro.ssl.G.a(Unknown Source)
.

PS: файл c:. newstore существует, его можно загрузить d MainControlPane, и там лежит один сертификат, импортированный из .cer-файла — самоподписанный сертификат Test Center CRYPTO-PRO.

Источник

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

Question

I have a SCCM R2 Windows 2008 System that has been functioning great! I have setup AMT in the past successfully however I am having difficulty getting our vPro systems Provisioned on SCCM. At this point, none are provisioned. I have all the required pre-req’s in place and i have installed our external GoDaddy cert successfully as well.

The server is attempting to provision the systems, but fais with the following error:

Failed to create SSPI credential with error=0x8009030E by AcquireCredentialsHandle.

Very little information can be found for this specific error code but from what i could find it points to the SSL cert.

I created my CSR to GoDaddy using OpenSSL (openssl.exe) and i I rcvd two files from GoDaddy. My Provisioning «.cer» and their Root Chain. I needed the «.cer» to be in «.pfx» (12) format so I used openssl and created a pfx using my private key that accompanied the initial request when i first generated and then sent the information to GoDaddy. and imported the pfx into SCCM successfully

I’m pretty sure my request was properly formatted (they require 2048 bit now) but i do have my private key so is there a way to attach/import that into the Local Computer Store (where the public key already is) and then export to .pfx to try that?

I have attached a screen shot of the «Start Task» to «End Task»

Has anybody expierenced this before? Any help is appreciated ! THanks!

Answers

Short Answer — The Root CA Chain needs to be included in the PFX file you use for SCCM / WS Man Trans

Answer — This was the first time I used OpenSSL binaries to create the cert request to the 3rd party cert provider. Not a problem. It worked and i rcvd two files back. The .CER file and the Certificate Root Chain. Since I used OpenSSL to create the request, i had to use OpenSSL to convert the CER into a PFX using the Private Key i initially created via OpenSLL. Once you convert the CER into a PFX, you need to import all 3 files (CER, Root Chain, and PFX) into the Local Computer Store. Once its imported, you need to Right Click on the Provisiong Cert (PFX) and select export. There will be an option for «Export all certificates in the chain if possible» or something along the lines of that. Once the export is complete, the PFX file you now exported is the PFX file you will use in SCCM and WSMan Trans.

The problem i had was that I didnt include the cert root chain when converting my CER into PFX using OpenSSL. Once i imported / exported from the Windows Local Computer Store, the gates opened and within 15 min i see them all coming into the AD OU i created and all is well.

For anyone interested, the commands i used to request and subsquently convert the cer into a PFX are as follows:

Источник

schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) — The revocation function was unable to check revocation for the certificate #2884

Description

This is in a corporate environment, specific security policies, proxies and firewalls are in place.

Using GitHub through Jenkins:
Command «. git.exe ls-remote -h https://github.com/. git HEAD» returned status code 128:
stdout:
stderr: fatal: unable to access
‘https://github.com/. git/’: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) — The revocation function was unable to check revocation for the certificate.

Using the same on a command line works seamlessly.

Any help solving or pinpointing this issue is greatly appreciated.

Version

GitHub Desktop version: git version 2.13.0.windows.1

OS version: Windows Server 2012 R2 Standard

Steps to Reproduce

1. Get behind specific security policies, proxies and firewalls
2. Try to access project configuration page in Jenkins; view Git Repository URL status info

Expected behavior: Repo cloning

Actual behavior: Accessing the repo fails

Reproduces how often: Every time, for every project

Sep 26, 2017 4:48:17 PM org.eclipse.jetty.server.session.Session beginInvalidate
INFO: Session node01p2vfd8qgjzcabocpvhaff1se0 already being invalidated
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins$25 run
SEVERE: Restarting VM as requested by admin
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins cleanUp
INFO: Stopping Jenkins
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins$21 onAttained
INFO: Started termination
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins$21 onAttained
INFO: Completed termination
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins _cleanUpDisconnectComputers
INFO: Starting node disconnection
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins _cleanUpShutdownPluginManager
INFO: Stopping plugin manager
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins _cleanUpPersistQueue
INFO: Persisting build queue
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins _cleanUpAwaitDisconnects
INFO: Waiting for node disconnection completion
Sep 26, 2017 4:54:51 PM jenkins.model.Jenkins cleanUp
INFO: Jenkins stopped
Sep 26, 2017 4:54:53 PM Main deleteWinstoneTempContents
WARNING: Failed to delete the temporary Winstone file C:WindowsTEMPwinstonejenkins.war
Sep 26, 2017 4:54:53 PM org.eclipse.jetty.util.log.Log initialized
INFO: Logging initialized @295ms to org.eclipse.jetty.util.log.JavaUtilLog
Sep 26, 2017 4:54:53 PM winstone.Logger logInternal
INFO: Beginning extraction from war file
Sep 26, 2017 4:54:53 PM org.eclipse.jetty.server.handler.ContextHandler setContextPath
WARNING: Empty contextPath
Sep 26, 2017 4:54:53 PM org.eclipse.jetty.server.Server doStart
INFO: jetty-9.4.z-SNAPSHOT
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.webapp.StandardDescriptorProcessor visitServlet
INFO: NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart
INFO: DefaultSessionIdManager workerName=node0
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart
INFO: No SessionScavenger set, using defaults
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging
INFO: Scavenging every 660000ms
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.handler.ContextHandler doStart
INFO: Started w.@1987993
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.AbstractConnector doStart
INFO: Started ServerConnector@1f8f5ae<0.0.0.0:8080>
Sep 26, 2017 4:54:54 PM org.eclipse.jetty.server.Server doStart
INFO: Started @1688ms
Sep 26, 2017 4:54:55 PM winstone.Logger logInternal
INFO: Winstone Servlet Engine v4.0 running: controlPort=disabled
Sep 26, 2017 4:54:56 PM jenkins.InitReactorRunner$1 onAttained
INFO: Started initialization
Sep 26, 2017 4:54:56 PM jenkins.InitReactorRunner$1 onAttained
INFO: Listed all plugins
Sep 26, 2017 4:55:01 PM jenkins.InitReactorRunner$1 onAttained
INFO: Prepared all plugins
Sep 26, 2017 4:55:01 PM jenkins.InitReactorRunner$1 onAttained
INFO: Started all plugins
Sep 26, 2017 4:55:01 PM hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error
INFO: Failed to instantiate optional component hudson.plugins.build_timeout.operations.AbortAndRestartOperation$DescriptorImpl; skipping
Sep 26, 2017 4:55:02 PM jenkins.InitReactorRunner$1 onAttained
INFO: Augmented all extensions
Sep 26, 2017 4:55:02 PM jenkins.InitReactorRunner$1 onAttained
INFO: Loaded all jobs
Sep 26, 2017 4:55:03 PM jenkins.slaves.DeprecatedAgentProtocolMonitor initializerCheck
WARNING: This Jenkins instance uses deprecated Remoting protocols: JNLP2-connect,JNLP3-connectIt may impact stability of the instance. If newer protocol versions are supported by all system components (agents, CLI and other clients), it is highly recommended to disable the deprecated protocols.
Sep 26, 2017 4:55:03 PM jenkins.InitReactorRunner$1 onAttained
INFO: Completed initialization
Sep 26, 2017 4:55:03 PM hudson.model.AsyncPeriodicWork$1 run
INFO: Started Download metadata
Sep 26, 2017 4:55:03 PM hudson.model.AsyncPeriodicWork$1 run
INFO: Finished Download metadata. 7 ms
Sep 26, 2017 4:55:03 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing org.springframework.web.context.support.StaticWebApplicationContext@18e5c76: display name [Root WebApplicationContext]; startup date [Tue Sep 26 16:55:03 BST 2017]; root of context hierarchy
Sep 26, 2017 4:55:03 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@18e5c76]: org.springframework.beans.factory.support.DefaultListableBeanFactory@69e46d
Sep 26, 2017 4:55:03 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@69e46d: defining beans [authenticationManager]; root of factory hierarchy
Sep 26, 2017 4:55:03 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing org.springframework.web.context.support.StaticWebApplicationContext@1d15a43: display name [Root WebApplicationContext]; startup date [Tue Sep 26 16:55:03 BST 2017]; root of context hierarchy
Sep 26, 2017 4:55:03 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@1d15a43]: org.springframework.beans.factory.support.DefaultListableBeanFactory@1fd0a7f
Sep 26, 2017 4:55:03 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1fd0a7f: defining beans [filter,legacy]; root of factory hierarchy
Sep 26, 2017 4:55:04 PM org.jenkinsci.plugins.skipcert.ItemListenerImpl onLoaded
INFO: Bypassing certificate check
Sep 26, 2017 4:55:04 PM hudson.WebAppMain$3 run
INFO: Jenkins is fully up and running
Sep 26, 2017 4:56:18 PM org.eclipse.jetty.server.session.Session beginInvalidate
INFO: Session node0qdcbe63zgppj1anmj9glsupq70 already being invalidated

Additional Information

The text was updated successfully, but these errors were encountered:

Источник

Dmitry-G	#11 Оставлено : 8 декабря 2022 г. 21:08:04(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 08.12.2022(UTC) Сообщений: 17 Откуда: Москва	Чтобы заработала служба 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 2022.12.08 19:00:12 LOG5[3672:17856]: Threading:WIN32 Sockets:SELECT,IPv6 2022.12.08 19:00:12 LOG5[3672:17856]: No limit detected for the number of clients 2022.12.08 19:00:12 LOG7[3672:17856]: FD 300 in non-blocking mode 2022.12.08 19:00:12 LOG7[3672:17856]: SO_REUSEADDR option set on accept socket 2022.12.08 19:00:12 LOG7[3672:17856]: tls1-client-https-1 bound to 127.0.0.1:10001 2022.12.08 19:00:12 LOG7[3672:17856]: FD 304 in non-blocking mode 2022.12.08 19:00:12 LOG7[3672:17856]: SO_REUSEADDR option set on accept socket 2022.12.08 19:00:12 LOG7[3672:17856]: tls1-client-https-2 bound to 127.0.0.1:10002 2022.12.08 19:10:16 LOG7[3672:17856]: tls1-client-https-1 accepted FD=308 from 127.0.0.1:60985 2022.12.08 19:10:16 LOG7[3672:17856]: Creating a new thread 2022.12.08 19:10:16 LOG7[3672:17856]: New thread created 2022.12.08 19:10:16 LOG7[3672:18488]: client start 2022.12.08 19:10:16 LOG7[3672:18488]: tls1-client-https-1 started 2022.12.08 19:10:16 LOG7[3672:18488]: FD 308 in non-blocking mode 2022.12.08 19:10:16 LOG7[3672:18488]: TCP_NODELAY option set on local socket 2022.12.08 19:10:16 LOG5[3672:18488]: tls1-client-https-1 connected from 127.0.0.1:60985 2022.12.08 19:10:16 LOG7[3672:18488]: FD 384 in non-blocking mode 2022.12.08 19:10:16 LOG7[3672:18488]: tls1-client-https-1 connecting 2022.12.08 19:10:16 LOG7[3672:18488]: connect_wait: waiting 10 seconds 2022.12.08 19:10:16 LOG7[3672:18488]: connect_wait: connected 2022.12.08 19:10:16 LOG7[3672:18488]: Remote FD=384 initialized 2022.12.08 19:10:16 LOG7[3672:18488]: TCP_NODELAY option set on remote socket 2022.12.08 19:10:16 LOG7[3672:18488]: start SSPI connect 2022.12.08 19:10:16 LOG3[3672:18488]: Credentials complete 2022.12.08 19:10:16 LOG7[3672:18488]: 166 bytes of handshake data sent 2022.12.08 19:10:16 LOG5[3672:18488]: 1318 bytes of handshake(in handshake loop) data received. 2022.12.08 19:10:16 LOG5[3672:18488]: 1627 bytes of handshake(in handshake loop) data received. 2022.12.08 19:10:16 LOG5[3672:18488]: certificate chain found 2022.12.08 19:10:16 LOG5[3672:18488]: new schannel credential created 2022.12.08 19:10:16 LOG3[3672:18488]: **** Error 0x8009030d returned by InitializeSecurityContext (2) 2022.12.08 19:10:16 LOG3[3672:18488]: Error performing handshake 2022.12.08 19:10:16 LOG5[3672:18488]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2022.12.08 19:10:16 LOG7[3672:18488]: free Buffers 2022.12.08 19:10:16 LOG7[3672:18488]: delete c->hContext 2022.12.08 19:10:16 LOG7[3672:18488]: delete c->hClientCreds 2022.12.08 19:10:16 LOG5[3672:18488]: incomp_mess = 0, extra_data = 1 2022.12.08 19:10:16 LOG7[3672:18488]: tls1-client-https-1 finished (0 left) А при запуске Stunnel Service от имени локальной системы — следующий: 2022.12.08 20:43:02 LOG5[16664:1744]: stunnel 4.18 on x86-pc-unknown 2022.12.08 20:43:02 LOG5[16664:1744]: Threading:WIN32 Sockets:SELECT,IPv6 2022.12.08 20:43:02 LOG5[16664:1744]: No limit detected for the number of clients 2022.12.08 20:43:02 LOG7[16664:1744]: FD 296 in non-blocking mode 2022.12.08 20:43:02 LOG7[16664:1744]: SO_REUSEADDR option set on accept socket 2022.12.08 20:43:02 LOG7[16664:1744]: tls1-client-https-1 bound to 127.0.0.1:10001 2022.12.08 20:43:02 LOG7[16664:1744]: FD 300 in non-blocking mode 2022.12.08 20:43:02 LOG7[16664:1744]: SO_REUSEADDR option set on accept socket 2022.12.08 20:43:02 LOG7[16664:1744]: tls1-client-https-2 bound to 127.0.0.1:10002 2022.12.08 20:44:38 LOG7[16664:1744]: tls1-client-https-1 accepted FD=304 from 127.0.0.1:61710 2022.12.08 20:44:38 LOG7[16664:1744]: Creating a new thread 2022.12.08 20:44:38 LOG7[16664:1744]: New thread created 2022.12.08 20:44:38 LOG7[16664:22504]: client start 2022.12.08 20:44:38 LOG7[16664:22504]: tls1-client-https-1 started 2022.12.08 20:44:38 LOG7[16664:22504]: FD 304 in non-blocking mode 2022.12.08 20:44:38 LOG7[16664:22504]: TCP_NODELAY option set on local socket 2022.12.08 20:44:38 LOG5[16664:22504]: tls1-client-https-1 connected from 127.0.0.1:61710 2022.12.08 20:44:38 LOG7[16664:22504]: FD 380 in non-blocking mode 2022.12.08 20:44:38 LOG7[16664:22504]: tls1-client-https-1 connecting 2022.12.08 20:44:38 LOG7[16664:22504]: connect_wait: waiting 10 seconds 2022.12.08 20:44:38 LOG7[16664:22504]: connect_wait: connected 2022.12.08 20:44:38 LOG7[16664:22504]: Remote FD=380 initialized 2022.12.08 20:44:38 LOG7[16664:22504]: TCP_NODELAY option set on remote socket 2022.12.08 20:44:38 LOG7[16664:22504]: start SSPI connect 2022.12.08 20:44:38 LOG3[16664:22504]: Credentials complete 2022.12.08 20:44:38 LOG7[16664:22504]: 166 bytes of handshake data sent 2022.12.08 20:44:38 LOG5[16664:22504]: 1318 bytes of handshake(in handshake loop) data received. 2022.12.08 20:44:38 LOG5[16664:22504]: 1627 bytes of handshake(in handshake loop) data received. 2022.12.08 20:44:38 LOG5[16664:22504]: CertFindChainInStore not find certificate in store. Looking at LOCAL_MACHINE 2022.12.08 20:44:38 LOG5[16664:22504]: certificate chain found 2022.12.08 20:44:38 LOG5[16664:22504]: new schannel credential created 2022.12.08 20:44:38 LOG3[16664:22504]: **** Error 0x8009035d returned by InitializeSecurityContext (2) 2022.12.08 20:44:38 LOG3[16664:22504]: Error performing handshake 2022.12.08 20:44:38 LOG5[16664:22504]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2022.12.08 20:44:38 LOG7[16664:22504]: free Buffers 2022.12.08 20:44:38 LOG7[16664:22504]: delete c->hContext 2022.12.08 20:44:38 LOG7[16664:22504]: delete c->hClientCreds 2022.12.08 20:44:38 LOG5[16664:22504]: incomp_mess = 0, extra_data = 1 2022.12.08 20:44:38 LOG7[16664:22504]: tls1-client-https-1 finished (0 left) Как я уже говорил, все сертификаты (включая личный) установлены средствами CSP, должным образом и корректно.

dysha	#12 Оставлено : 9 декабря 2022 г. 12:12:32(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 22.03.2011(UTC) Сообщений: 2 Откуда: Kirov	В инструкции УЦ Банка России по настройке stunnel есть требование: Цитата: В свойствах сертификата перейдите на вкладку «Протокол OCSP» и добавьте следующие URL как показано на картинке ниже: http://127.0.0.1:10001/ocsp http://127.0.0.1:10002/ocsp Каким образом можно эту настройку сделать на Linux?
	WWW

ew-mc	#13 Оставлено : 12 декабря 2022 г. 18:31:23(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 12.12.2022(UTC) Сообщений: 10 Откуда: Москва	Автор: 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, должным образом и корректно. Добрый день, коллеги! Dmitry-G, у нас ошибка практически один-в-один как у Вас. Все сертификаты — корневой, промежуточный, личный также установлены должным образом и корректно. Но, в файле лога Stunnel говорит, что не видит сертификат локального пользователя: ……… 2022.12.12 15:25:12 LOG3[6960:9356]: Credentials complete 2022.12.12 15:25:12 LOG7[6960:9356]: 166 bytes of handshake data sent 2022.12.12 15:25:13 LOG5[6960:9356]: 2760 bytes of handshake(in handshake loop) data received. 2022.12.12 15:25:13 LOG5[6960:9356]: 641 bytes of handshake(in handshake loop) data received. 2022.12.12 15:25:13 LOG5[6960:9356]: CertFindChainInStore not find certificate in store. Looking at LOCAL_MACHINE 2022.12.12 15:25:13 LOG5[6960:9356]: certificate chain found 2022.12.12 15:25:13 LOG5[6960:9356]: new schannel credential created 2022.12.12 15:25:13 LOG3[6960:9356]: **** Error 0x8009030d returned by InitializeSecurityContext (2) 2022.12.12 15:25:13 LOG3[6960:9356]: Error performing handshake ……… Вам удалось найти причину проблемы?

ew-mc	#14 Оставлено : 12 декабря 2022 г. 19:33:28(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 12.12.2022(UTC) Сообщений: 10 Откуда: Москва	Автор: Orgia коллеги, а если туннель вообще не запускается служба? c:Stunnel>sc config stunnel start= auto & net start stunnel [SC] ChangeServiceConfig SUCCESS The Stunnel Service service is starting. The Stunnel Service service could not be started. A system error has occurred. System error 1067 has occurred. The process terminated unexpectedly. сталкивался кто? Версия криптопровайдера: 5.0.12000 OS WIN Server 2008 R2 сталкивался кто? Мы сталкивались с такой же ошибкой 1067 при попытке запустить службу Stunnel Service. Метод лечения: 1. Удалить службу Stunnel Service. Для этого в командной строке под админом написать C:Stunnelstunnel -remove 2. Скачать stunnel.conf из http://www.cbr.ru/Conten…tions_accessing_ttss.pdf в C:Stunnel 3. Только после шага №2 из командной строки установить Stunnel согласно инструкции ЦБ. 4. Скачать stunnel.conf от ЦБ в еще две папки: C:WindowsSystem32 и в C:WindowsSysWOW64 5. Пытаемся запустить службу из командной строки или через «Службы»

Dmitry-G	#15 Оставлено : 13 декабря 2022 г. 14:42:21(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 08.12.2022(UTC) Сообщений: 17 Откуда: Москва	Добрый день, коллеги! Если ничего не путаю, ошибка «CertFindChainInStore not find certificate in store. Looking at LOCAL_MACHINE» для цепочки сертификатов, установленной в хранилище локального компьютера, исчезла у нас после замены (по рекомендации сотрудников техподдержки КриптоПро) в конфиге Stunnel (повторюсь — который в 64-битных ОС должен лежать в папке System32, иначе сервис не запустится и будет ошибка 1067) строк: connect = 212.40.208.62:443 connect = 212.40.193.62:443 на соответствующие строки: connect = tsp1.ca.cbr.ru:443 connect = tsp2.ca.cbr.ru:443 Однако, как выяснилось, основная причина происходящего была скрыта в настройках нашего firewall. Пару часов назад нам удалось получить корректный ответ с метками времени от сервера АУЦ БР на компе, который смотрел в инет напрямую, причем, без особых заморочек с настройками и с применением стандартного stunnel.conf в варианте от АУЦ БР. Отредактировано пользователем 13 декабря 2022 г. 14:48:11(UTC)  | Причина: Не указана

ИгорьК	#16 Оставлено : 13 декабря 2022 г. 17:13:06(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	у нас все запускается но не работает… странная ошибка в логе SSPI_read return SEC_I_CONTEXT_EXPIRED Есть мысли (с ЦБ уже несколько дней переписываемся — ничего не помогает, и антивирус отключали и 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 2022.12.13 16:39:27 LOG7[5204:1296]: data send to socket = 3869 2022.12.13 16:39:27 LOG7[5204:1296]: SSPI_read start 2022.12.13 16:39:27 LOG7[5204:1296]: add data from last call = 31 2022.12.13 16:39:27 LOG5[5204:1296]: SEC_I_CONTEXT_EXPIRED, 2022.12.13 16:39:27 LOG5[5204:1296]: SSPI_read return SEC_I_CONTEXT_EXPIRED 2022.12.13 16:39:27 LOG7[5204:1296]: Socket write shutdown 2022.12.13 16:39:27 LOG7[5204:1296]: c->ssl_ptr = 0 2022.12.13 16:39:27 LOG7[5204:1296]: Enter pool section on transfer 2022.12.13 16:39:27 LOG7[5204:1296]: !!!!!Call s_poll_wait with timeout = 60 ((sock_rd && ssl_rd)=0) c->ssl_ptr = 0 c->sock_ptr=0 2022.12.13 16:39:27 LOG5[5204:1296]: 31 bytes of close_notify data sent 2022.12.13 16:39:27 LOG6[5204:1296]: SSL_shutdown successfully sent close_notify 2022.12.13 16:39:27 LOG5[5204:1296]: Connection closed: 306 bytes sent to SSL, 8057 bytes sent to socket 2022.12.13 16:39:27 LOG7[5204:1296]: free Buffers 2022.12.13 16:39:27 LOG7[5204:1296]: delete c->hContext 2022.12.13 16:39:27 LOG7[5204:1296]: delete c->hClientCreds 2022.12.13 16:39:27 LOG5[5204:1296]: incomp_mess = 1, extra_data = 2 2022.12.13 16:39:27 LOG7[5204:1296]: tls1-client-https-2 finished (0 left)

Dmitry-G	#17 Оставлено : 14 декабря 2022 г. 10:51:03(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 08.12.2022(UTC) Сообщений: 17 Откуда: Москва	Да, признаю, как выяснилось, на машине с прямым инетом у нас все заработало лишь потому, что машина была новая и в личных у нее был всего лишь один сертификат — как раз тот сертификат, который требовался Stunnel для установки соединения. Когда же в справочнике имеются прочие личные сертификаты, в конфигурации Stunnel обязательно нужно указывать конкретно к какому сертификату из установленных обращаться. Как это сделать, подробно с примерами написано в мануале на Stunnel, входящем в состав КриптоПро CSP. Так что ИгорьК прав — антивирус и firewall тут оказались ни при чём. К сказанному также добавлю следующее: A. Где-то в ветках данного форума кем-то было озвучено, что указанный сертификат следует выгружать в файловую систему из справочника КриптоПро CSP, а не класть его туда методом копирования. В этом случае якобы в него (или в Stunnel) каким то образом добавляется ссылка на закрытый ключ, которую понимает Stunnel. В общем, сложно сказать, что это за ссылка, куда и как она добавляется, но в нашем случае оказалось, что это работает. Так что автору идеи, большое спасибо. Эксперименты с подключением рекомендуем вначале проводить без пароля на контейнер с ключом. B. Также выяснилось, что в процессе своей работы, служба Stunnel Service (при запуске от имени локальной системы) обращается к обозначенному личному сертификату в хранилище локального компьютера, а КриптоПро ЭЦП Browser plug-in — к такому же сертификату, лежащему в хранилище текущего пользователя. Так что по крайней мере на этапе тестирования, лучше добавлять соответствующую цепочку (с требуемыми настройками адресов OCSP в свойствах сертификатов БР) в оба эти хранилища. C. Ну и еще, пожалуй, добавлю официальный ответ техподдержки БР по данному вопросу. Нам он, правда, в итоге не помог, но может кому будет полезно: Просим проверить выполнение следующих шагов: 1. Установка цепочек сертификатов (сертификат владельца в хранилище личное текущего пользователя с привязкой к закрытому ключу, промежуточный сертификат УЦ Банка России в хранилище промежуточные центры сертификации локального компьютера, сертификат Минкомсвязи России в хранилище доверенные корневые центры сертификации локального компьютера); 2. Изменение файла C:WindowsSystem32driversetchosts — добавление строки 127.0.0.1 localhost tsp1.ca.cbr.ru tsp2.ca.cbr.ru (задвоение строк не допускается) 3. Указание в свойствах промежуточного сертификата УЦ Банка России ссылок http://127.0.0.1:10001/ocsp и http://127.0.0.1:10002/ocsp 4. Создание каталога C:Stunnel, скачать и поместить в него stunnel.conf, также скопировать stunnel.conf в каталог C:WindowsSystem32 — проверьте — данный файл не должен содержать задвоения информации 5. Скачать и поместить stunnel в каталог C:Stunnel. Программу stunnel (х64 или х32 в зависимости от разрядности ОС) предлагается скачать с официального сайтоа ООО «КРИПТО-ПРО». Инсталляция stunnel от имени администратора. Запуск службы Stunnel Service (от имени системной учетной записи) и проверка успешности его запуска (Пуск — Службы — Stunnel Service — запустить). 6. В каталоге C:Stunnel Вы должны иметь три файла: stunnel, stunnel.conf, stunnel_cli (файл лога — формируется после первого успешного запроса к службе штампов времени) 7. Проверка подписания тестовых электронных документов электронной подписью в КриптоАРМ ГОСТ без установки штампов времени и с установкой штампов времени по адресам http://tsp1.ca.cbr.ru:10001/tsp или http://tsp2.ca.cbr.ru:10002/tsp 8. Установка плагина «КриптоПро ЭЦП Browser Plug-in» 9. Тестирование ЭП в браузере на сервисе 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 При тестировании у Вас должно быть обращение к ключу с запросом пин-кода. 10. По итогам вышеуказанного можно сделать вывод об успешной работе с сервисами службы штампов времени. Отредактировано пользователем 14 декабря 2022 г. 13:23:48(UTC)  | Причина: Не указана

ИгорьК	#18 Оставлено : 14 декабря 2022 г. 13:06:57(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Попробовал через браузер набрал http://tsp1.ca.cbr.ru:10001/tsp в логе те же самые 2022.12.14 12:57:34 LOG5[892:16136]: SEC_I_CONTEXT_EXPIRED, 2022.12.14 12:57:34 LOG5[892:16136]: SSPI_read return SEC_I_CONTEXT_EXPIRED 2022.12.14 12:57:34 LOG7[892:16136]: Socket write shutdown Вот браузер выдал: Запрошенный URL не может быть получен При получении URL https://212.40.208.62/* произошла следующая ошибка: Не удалось установить безопасное соединение с [unknown] The system returned: [No Error] (TLS code: SQUID_TLS_ERR_CONNECT+TLS_LIB_ERR=1421C0F8+TLS_IO_ERR=1) Failed to establish a secure connection: error:1421C0F8:SSL routines:set_client_ciphersuite:unknown cipher returned Для выполнения Вашего запроса этот кэш и удаленный узел не смогли согласовать взаимоприемлемые параметры безопасности. Возможно, удаленный узел не поддерживает безопасные соединения или кэш не удовлетворён удостоверением безопасности узла.

ew-mc	#19 Оставлено : 14 декабря 2022 г. 15:59:28(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 12.12.2022(UTC) Сообщений: 10 Откуда: Москва	Добрый вечер, коллеги! Идея Dmitry-G о том, что Stunnel не переваривает наличие более одного личного сертификата в папке «Личное» раздела Текущего пользователя и в папке «Личное» раздела Сертификаты (локальный компьютер) подтвердилась!!! Мне удалось подписать данные с помощью КриптоПро ЭЦП Browser plug-in и документы с помощью КриптоАРМ только когда в папках «Личное» этих разделов было по одному личному сертификату. Параметры при которых было успешное подписание Запуск Stunnel: С системной учетной записью; Конфиг-файл Stunnel: стоковый от Банка России лежит в c:Stunnel а также в C:WindowsSystem32 Подписание происходило в сеансе Текущего пользователя без админских прав. Dmitry-G, я не нашел в мануале по Stunnel от КриптоПРО подробное описание с примерами указания пути к конкретному сертификату… http://www.cryptopro.ru/…guidestunnel_windows.pdf P.S. Да, антивирус и firewall не при чем. И права админа не влияют на успех подписания. Отредактировано пользователем 14 декабря 2022 г. 16:19:59(UTC)  | Причина: Не указана

ИгорьК	#20 Оставлено : 14 декабря 2022 г. 17:10:42(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Да, у нас на новой чистой машине тоже заработало, когда в Личном только один сертификат Но как с этим работать? пробовал явно указать в конфиге сертификат (cert = c:stunnelmyCert.cer) так ругается, что не находит его…

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

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

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

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

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

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

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

Shchof

 

#31
Оставлено
:
22 октября 2021 г. 13:50:00(UTC)

Алексей Яковлев

 

#32
Оставлено
:
2 ноября 2021 г. 19:29:10(UTC)

Angel_19

 

#33
Оставлено
:
2 декабря 2021 г. 16:07:21(UTC)

Angel_19

 

#34
Оставлено
:
3 декабря 2021 г. 10:22:16(UTC)

ivan.ses

 

#35
Оставлено
:
5 декабря 2021 г. 15:25:34(UTC)

Angel_19

 

#36
Оставлено
:
23 декабря 2021 г. 9:10:25(UTC)

Angel_19

 

#37
Оставлено
:
23 декабря 2021 г. 9:12:57(UTC)

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

 

#38
Оставлено
:
23 декабря 2021 г. 9:43:40(UTC)

Guest

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

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

• Enable Supported Protocol Versions

  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

  icharge1.Config("SSLEnabledProtocols=4032");

  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

• Translate the PEM file into a PFX file.

  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

• When using a certificate for client authentication, ensure the certificate’s private keys are accessible.
  The certificate in the Windows certificate store must contain the corresponding private keys, and be marked as exportable.
• Ensure that the current user and administrators have full access to «C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSAMachineKeys».
• Import the certificates directly into both LOCAL_MACHINEPersonal and ADAMPersonal if ADAM is installed.

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.

  HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman

  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

• The server is using a certificate with an outdated signature algorithm. See this MSDN Article
• The server doesn’t expect SSL over this port.
  Set the SSLStartMode property to sslExplicit.
• FileZilla and other FTP servers require a PROT P command to be sent for the data connection when using implicit SSL.
  Set the UseProtWhenImplicit configuration setting to True.
• The server returns a large number of CA’s in the handshake.

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

• This error may also happen if the server and client don’t posses a common supported cipher suite. This can be the case if you’re connecting from Windows XP to a site that has recent/strict security requirements. Here is a list of ciphers supported in XP. Setting UseInternalSecurityAPI to true may help with this error as it supports many newer protocols not supported on older systems.
• Client authentication is required. Ensure that you are loading the certificate correctly.
• The server does not support the SSL Client Hello version being used. Set the SSLEnabledProtocols configuration setting to an appropriate value.
• The server does not support SSL session re-use. You can disable this by setting the ReuseSSLSession and/or ReuseSSLSessionInDI configuration setting to false.
• The server returns SSL handshake packets larger than 16K. This is a CryptoAPI limitation.

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

• Similar to 80090304, 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.

  HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman

  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:

• 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