仅在第一次尝试时无法建立 SSL 连接答案

【问题标题】：Unable to establish SSL connection on first attempt only仅在第一次尝试时无法建立 SSL 连接
【发布时间】：2015-02-11 08:22:51
【问题描述】：

我有一个电子商务网站已经运行了几个月，没有更改任何代码（并且运行了几年，只对卡处理路径进行了最小的更改）。我现在遇到一个问题，当第一次打开与信用卡处理器安全服务器的连接时，连接失败。在第二次（或第三次、或第四次等）尝试连接成功。一段时间后（可能是 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

有一些类似的问题，但我无法解决问题，并且我没有看到任何具有相同错误消息和后续连接尝试在初始失败后成功的症状，例如：

Unable to establish SSL connection, how do I fix my SSL cert?
curl errno 35 (Unknown SSL protocol error in connection to [secure site]:443)（同样的错误信息）
How to fix cURL SSL connection timeout that only happens the first time the script is called（不同的错误消息，但 SSL 连接第一次尝试失败，随后成功）

【问题讨论】：

你能把类似问题的链接放上去吗？
我刚刚添加了一些具有相同错误消息或类似症状的问题的链接。

标签： php ssl curl openssl certificate

【解决方案1】：

服务器有点坏。它确实支持 TLS1.2 和 TLS1.0，但不支持 TLS1.1（回复 TLS1.0 可以）。这通常不是问题，除非您的客户端代码试图通过排除其他协议来强制执行特定协议。

您描述的行为看起来像一个客户端，它在连接失败时降级连接，将此降级缓存一段时间，但一段时间后再次使用最初失败的版本重试。追查问题：

检查问题是否也与其他服务器有关
检查其他客户端是否与同一服务器有问题
检查底层实现。 Curl 可以使用 GnuTLS、NSS、OpenSSL 等等。从错误消息来看，它看起来像 OpenSSL，但哪个版本？
检查服务器路径中是否存在任何可能导致问题的中间件（防火墙、负载平衡器...）
进行数据包捕获并将其以可用于wireshark（例如cloudshark）的形式发布到此处

有关如何调试此类问题以及哪些附加信息有用的更多信息，请查看http://noxxi.de/howto/ssl-debugging.html#aid_external_debugging

【讨论】：

我相信您正确诊断出问题（服务器端故障），但它与客户端故障相结合。在其他计算机上测试后，只有这个客户端（使用旧版本的 curl）表现出这种行为。由于客户端上的 curl 版本和远程服务器上的服务器软件都超出了我的控制范围，我只是更改了客户端库以通过 CURLOPT_SSLVERSION 选项强制使用特定的 TLS 版本。我不再遇到这个问题了。
嗨，Steffen，希望一切都好。您能帮帮我吗，我目前正在与银行就支付解决方案进行谈判，他们一直说流程太长并且可能导致连接超时。你能澄清一下它们的意思吗？他们还告诉我在欧洲连接的时间限制是 5 秒。
@kd12345：这不是个人帮助台。如果您有问题，请不要将其作为对某些不相关答案的评论提出，而应提出具有足够详细信息的新问题。不，我不知道银行只是这么少的细节意味着什么。

【解决方案2】：

我有一个使用旧的 VirtualMerchant 网关的客户端发生了确切的事情。它在星期一下午 5:00 开始出现故障，并神奇地在第二天上午 10 点再次开始工作。

无论是在命令行上通过 openssl、curl 还是通过 PHP 中的 curl，第一次连接都会失败，然后如果你第二次运行相同的命令，它就会起作用。

我尝试强制使用 IPv4（而不是 IPv6）、设置超时、强制使用不同的协议、降级 openssl 等，但都没有奏效。

假设这是与网关端的 DNS 和/或服务器相关的东西，因为我们没有做任何修复它并且它自己修复了。

我们正在运行一个旧的 openssl，它只支持最高 TLS 1.1，但它正在工作，然后它又开始工作，所以它不仅仅是我们的客户端。不过，我们客户的年龄一定是问题的一部分，因为其他新客户在同一时间窗口内没有经历过“第一次尝试失败”。

长话短说，如果发生这种情况，可能不是您（除了您有较旧的 OpenSSL），您调用的其他网关/服务器可能需要修复/调整某些东西才能重新开始工作。

请记住，openssl 是 Linux 核心软件包的一部分，因此您不能简单地升级 openssl 而不会有严重破坏服务器的风险。您必须升级到较新版本的操作系统才能获得更现代的 openssl。

【讨论】：