Как проанализировать ошибку в установке ssl соединения?

Question

[Сергей Якушев]

Со вчерашнего дня наблюдаю следующую картину. Первое обращение в к ресурсу https://securepayments.sberbank.ru:443 заканчивается неудачно. Последующие проходят успешно.

Проблема воспроизводится с моих линукс-серверов, у моего хостинг провайдера, а так же при установке соединения с моего компьютера из программы 1С:Предприятие.

Как можно проанализировать проблему и что можно предпринять с моей стороны?

Из консоли "первая" попытка выглядит так:

sy@asterisk:~/wget$ curl -v https://securepayments.sberbank.ru:443
* Rebuilt URL to: https://securepayments.sberbank.ru:443/
*   Trying 62.76.205.134...
* TCP_NODELAY set
* Connected to securepayments.sberbank.ru (62.76.205.134) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to securepayments.sberbank.ru:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to securepayments.sberbank.ru:443

"Вторая" попытка уже лучше (заканчивается неудачно, потому что на данном сервере нет сертификатов УЦ минцифры)

sy@asterisk:~/wget$ curl -v https://securepayments.sberbank.ru:443
* Rebuilt URL to: https://securepayments.sberbank.ru:443/
*   Trying 62.76.205.134...
* TCP_NODELAY set
* Connected to securepayments.sberbank.ru (62.76.205.134) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: self signed certificate in certificate chain
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Comments

[res2001]

Можно поместить этот "self signed certificate" в доверенные сертификаты, возможно это можно сделать опциями curla или еще как-то.
Или вы можете использовать совет: "If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.". Тогда curl не будет проверять сертификаты. Но это, конечно, плохой вариант, годится только как какое-то временное решение.
Одновременно написать в поддержку сбера об имеющейся проблеме, пусть решают.

[Сергей Якушев]

res2001, "self signed certificate" - это как раз положительный результат) А вот первая попытка о чем говорит? Что серта нет совсем?

[res2001]

Сергей Якушев,

положительный результат

Я бы так не сказал. Это самоподписанный сертификат. Такой сертификат может выпустить кто угодно. Доверять такому сертификату нельзя.
В первом случае, судя по всему, вообще на той стороне нет SSL. Если бы использовался, например, какой-то другой алгоритм шифрования, то ошибка была бы другая. Кстати, это же подтверждает и @paran0id

Для такой конторы как сбер, использовать самоподписанные сертификаты - "это какой-то позор" :)

[Сергей Якушев]

res2001,

заканчивается неудачно, потому что на данном сервере нет сертификатов УЦ минцифры

Блин ну нет у меня под рукой сервера с установленными сертами УЦ минцифры. Сейчас все госорганы их требуют и сбер тоже, во всяком случае в не публичном пространстве.

[res2001]

Сергей Якушев, Это не ваш сертификат, а сертификат сбера, на сервере сбера.
Вы в команде никаких своих сертификатов не указываете, да это обычно и не нужно для HTTPS подключения, хотя возможно.

Answer 1

[paran0id]

openssl s_client -connect securepayments.sberbank.ru:443

в половине случаев получаем:

$ openssl s_client -connect securepayments.sberbank.ru:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 338 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

во второй половине - Verify return code: 19 (self-signed certificate in certificate chain), что означает отсутствие корневого сертификата

такое впечатление, что там балансировщик кидает то на хороший сервер, то на плохой

Comments

[Сергей Якушев]

А в первой половине случаев

no peer certificate available

означает, что их сервер не предоставил сертификат?

[paran0id]

Сергей Якушев, ага

Answer 2

[CityCat4]

Unknown SSL protocol error

У Вас строка шифронаборов составлена как будто специально по принципу "дыра на дыре сидит и дырой погоняет". Это так было сделано специально или просто недосмотр?
Вы не договорились по шифронаборам, хотя нужный шифронабор там есть...

Сайт явно использует российские сертификаты и есть предположение, что первый пакет улетает на аналитику - откуда он пришел - поэтому получаем устойчивое no peer certificate.

Попробуйте поставить корневые от Минцифры и посмотреть, что получилось.

Answer 3

[Александр Аксентьев]

Сбер вчера перестал работать просто.
С прокси еще более менее работал.
Из-за бугра не открывался вообще.

Вроде уже починили.
Или добавили наш сервер в вайтлист.

Короч у них есть саппорт если что)

Comments

[Сергей Якушев]

Ну и я на всякий случай уточняю. Вдруг дело "во мне".

Моя проблема воспроизводится на хостингах таймвеба и nic.ru и их саппорт пока не ответил мне ничего.

Так что ничего они не починили.

[Александр Аксентьев]

Сергей Якушев, сделайте циклом несколько запросов подряд, нам помогло)

[Сергей Якушев]

Александр Аксентьев, так?)

ПингТест = Ложь;
	Для ц=1 По 2 Цикл

		ПингТест = СберИнтернетЭквайринг.Пинг(Соединение, СтруктураДоступа);
		Если ПингТест Тогда
			Прервать;
		КонецЕсли;
				
	КонецЦикла;
			
	Если НЕ ПингТест Тогда
				
		ВызватьИсключение("Нет соединения с " + СтруктураДоступа.Шлюз);

	КонецЕсли;

[Сергей Якушев]

Александр Аксентьев, А вы возврат денежных средств тоже в цикле делаете?

[Александр Аксентьев]

Сергей Якушев, возвраты ручные, так что не скажу

> так?)

мб, я сам запрос шлю несколько раз.

$i = 0;
        while ($i <= 5) {
            try {
                $resp = $client->request($method, config('services.SBER_PROD_URL').$uri, [
                    'form_params' => $form_params,
                ]);

                return $resp;
            } catch (\Throwable $e) {
                Log::debug('sber request error: '.$e->getMessage(), [
                    'method' => $method,
                    'form_params' => $form_params,
                ]);
            }

            $i++;
        }