У меня есть сайт электронной коммерции, который работает в течение нескольких месяцев без изменений кода (и в течение нескольких лет с минимальными изменениями на пути обработки карты). У меня теперь есть проблема, когда при первом открытии соединения с защищенным сервером процессора кредитных карт соединение терпит неудачу. На втором (или третьем, или четвертом и т.д.) Попытке подключения удастся. Через некоторое время - возможно, 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
Есть несколько аналогичных вопросов, но я не смог решить проблему, и я не вижу никаких сообщений с таким же сообщением об ошибке и симптомом последующих попыток подключения после первоначального сбоя, например:
Сервер вроде бы сломан. Он поддерживает TLS1.2 и TLS1.0, но не TLS1.1 (отвечает с TLS1.0, который в порядке). Обычно это не проблема, если у вас нет клиентского кода, который пытается обеспечить соблюдение определенных протоколов, исключив других.
Поведение, которое вы описываете, выглядит как клиент, который понижает соединение при неудавшемся соединении, сохраняет это кэширование в течение некоторого времени, но через какое-то время снова пытается выполнить повторную попытку. Чтобы проследить проблему, выполните следующие действия:
Для получения дополнительной информации о том, как отлаживать такие проблемы и какая дополнительная информация будет полезной, можно проверить http://noxxi.de/howto/ssl-debugging.html#aid_external_debugging
CURLOPT_SSLVERSION
конкретную версию TLS с CURLOPT_SSLVERSION
опции CURLOPT_SSLVERSION
. У меня больше нет этой проблемы.
У меня была точная вещь с клиентом, использующим старый шлюз VirtualMerchant. Он начался неудачей в 5:00 вечера в понедельник и волшебно начал работать снова в 10 часов утра на следующий день.
Будь то в командной строке через openssl, или curl, или через curl в PHP, соединение завершится с ошибкой в первый раз, а затем, если вы запустили ту же команду, второй второй будет работать.
Я пытался заставить IPv4 (вместо IPv6), устанавливать таймауты, форсировать разные протоколы, понижать рейтинг openssl и т.д., И ни одна из них не работает.
Предполагается, что это было связано с DNS и/или сервером на стороне шлюза, потому что мы ничего не исправили, и он исправил себя.
Мы запускали более старый opensl, который поддерживался только до TLS 1.1, но он работал, а затем снова начал работать, поэтому это был не только наш клиент. Хотя, возраст нашего клиента, должно быть, был частью проблемы, потому что другие более новые клиенты не испытывали "неудачу первой попытки" в течение того же самого окна.
Короче говоря, если это произойдет, возможно, вы НЕ (кроме того, у вас есть более старый OpenSSL), а другой шлюз/сервер, которому вы звоните, вероятно, потребуется исправить/настроить что-то, чтобы он снова начал работать.
Имейте в виду, что openssl является частью основных пакетов Linux, поэтому вы не можете просто обновить openssl без серьезного риска испортить сервер. Вам нужно будет перейти на более новую версию операционной системы, чтобы получить более современный opensl.