Невозможно установить соединение SSL только с первой попытки

0

У меня есть сайт электронной коммерции, который работает в течение нескольких месяцев без изменений кода (и в течение нескольких лет с минимальными изменениями на пути обработки карты). У меня теперь есть проблема, когда при первом открытии соединения с защищенным сервером процессора кредитных карт соединение терпит неудачу. На втором (или третьем, или четвертом и т.д.) Попытке подключения удастся. Через некоторое время - возможно, 5 минут - первоначальное соединение снова завершится, и последующие соединения будут успешными.

Пример кода, который поступает из файла PHP API для кредитных карт:

$url = 'https://esplus.moneris.com:443/gateway_us/servlet/MpgRequestArray';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt ($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$dataToSend);
curl_setopt($ch,CURLOPT_TIMEOUT,$gArray[CLIENT_TIMEOUT]);
curl_setopt($ch,CURLOPT_USERAGENT,$gArray[API_VERSION]);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE);

$response=curl_exec ($ch);

if(!$response) {
    print curl_error($ch);
    print "\n";
    print curl_errno($ch);
    print "\n";
} else {
    print "Success\n";
}

Вывод:

% php tester_curl.php
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
35
% php tester_curl.php
Success
% php tester_curl.php
Success
% php tester_curl.php
Success

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

  • 0
    Можете ли вы поставить ссылки на подобные вопросы?
  • 0
    Я просто добавил ссылки на некоторые вопросы, у которых было то же сообщение об ошибке или похожие симптомы.
Теги:
curl
ssl
openssl
certificate

2 ответа

1
Лучший ответ

Сервер вроде бы сломан. Он поддерживает TLS1.2 и TLS1.0, но не TLS1.1 (отвечает с TLS1.0, который в порядке). Обычно это не проблема, если у вас нет клиентского кода, который пытается обеспечить соблюдение определенных протоколов, исключив других.

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

  • проверьте, есть ли проблема с другими серверами
  • проверьте, есть ли у других клиентов проблема с тем же сервером
  • проверьте базовую реализацию. Curl может использовать GnuTLS, NSS, OpenSSL и, возможно, больше. Из сообщения об ошибке это выглядит как OpenSSL, но какая версия?
  • проверьте на наличие какого-либо промежуточного окна (брандмауэр, балансировщик нагрузки...) на пути к серверу, который может вызвать проблемы
  • сделать захват пакетов и опубликовать его здесь в форме, которую можно использовать с wirehark (например, облачный)

Для получения дополнительной информации о том, как отлаживать такие проблемы и какая дополнительная информация будет полезной, можно проверить http://noxxi.de/howto/ssl-debugging.html#aid_external_debugging

  • 0
    Я считаю, что вы правильно диагностировали проблему (сбой на стороне сервера), но она сочетается с ошибкой клиента. После тестирования на других компьютерах только этот клиент (с более старой версией curl) демонстрировал это поведение. Так как версия curl на клиенте и серверное программное обеспечение на удаленном сервере находятся вне моего контроля, я просто изменил свои клиентские библиотеки, чтобы принудительно CURLOPT_SSLVERSION конкретную версию TLS с CURLOPT_SSLVERSION опции CURLOPT_SSLVERSION . У меня больше нет этой проблемы.
0

У меня была точная вещь с клиентом, использующим старый шлюз VirtualMerchant. Он начался неудачей в 5:00 вечера в понедельник и волшебно начал работать снова в 10 часов утра на следующий день.

Будь то в командной строке через openssl, или curl, или через curl в PHP, соединение завершится с ошибкой в первый раз, а затем, если вы запустили ту же команду, второй второй будет работать.

Я пытался заставить IPv4 (вместо IPv6), устанавливать таймауты, форсировать разные протоколы, понижать рейтинг openssl и т.д., И ни одна из них не работает.

Предполагается, что это было связано с DNS и/или сервером на стороне шлюза, потому что мы ничего не исправили, и он исправил себя.

Мы запускали более старый opensl, который поддерживался только до TLS 1.1, но он работал, а затем снова начал работать, поэтому это был не только наш клиент. Хотя, возраст нашего клиента, должно быть, был частью проблемы, потому что другие более новые клиенты не испытывали "неудачу первой попытки" в течение того же самого окна.

Короче говоря, если это произойдет, возможно, вы НЕ (кроме того, у вас есть более старый OpenSSL), а другой шлюз/сервер, которому вы звоните, вероятно, потребуется исправить/настроить что-то, чтобы он снова начал работать.

Имейте в виду, что openssl является частью основных пакетов Linux, поэтому вы не можете просто обновить openssl без серьезного риска испортить сервер. Вам нужно будет перейти на более новую версию операционной системы, чтобы получить более современный opensl.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню