2014-12-12 3 views
0

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

Пример код, который приходит из файла 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

Я просто добавил ссылки на некоторые вопросы, у которых было такое же сообщение об ошибке или подобные симптомы. – Raolin

ответ

1

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

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

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

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

+0

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

0

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

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

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

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

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

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

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

Смежные вопросы