一年多来，我一直在运营一个照片网站，该网站允许客户订购照片，然后由印刷公司完成。订单以 XML 格式发布到指定的 URL。最近订单没有发布，我在检查服务器日志时遇到了以下错误：
[Mon Dec 01 21:17:38 2014] [error] [client XXX] cURL error: [35] Cannot communicate securely with peer: no common encryption algorithm(s).
印刷公司的技术团队为我提供了一些指导，但我仍然感到困惑。最初他们告诉我，服务器目前仅支持 SSLv2、SSLv3 和 TLS1.0，而我们这边很可能只启用了 TLS1.2。他们声称他们那边没有任何变化，我个人知道我们那边几个月都没有修改过任何东西。当我最初遇到问题时，我尝试更新服务器包，但这无法解决问题。后来我想，也许问题出在 Amazon EC2 实例的安全组上，但我并不完全确定。假设尚未启用 TLS1.0，我该如何启用它？我该如何检查当前启用了哪些传输层安全和安全套接字层？还有其他建议吗？
答案1
OpenSSL 的一些版本由于 OpenSSL 的问题（而非 Ubuntu 本身的问题），Ubuntu 中出现问题并且可能在其他发行版中也被破坏，例如 Amazon Linux，当连接到一个古老的服务器时，除非你明确强制执行，否则它不会比 TLS 1.0 更好，正如@AndySmith 上面建议的那样（openssl s_client -connect在这种情况下，尝试从命令行查看它是否工作的选项是-tls1）。
我在你的问题中没有看到这一点，但我假设你使用的是 PHP。我不是 PHP 专家，但看起来你的解决方法可能是使用CURLOPT_SSLVERSION强迫CURL_SSLVERSION_TLSv1_0。
如果您的供应商无法做得比 TLS 1.0 更好，并且（更糟）仍然支持 SSLv2 和 SSLv3，那么他们真的应该感到尴尬。甚至 PHP 文档也建议不要使用旧版本：
最好的办法是不要设置它，让它使用默认值。考虑到 SSLv2 和 SSLv3 中已知的漏洞，将其设置为 2 或 3 非常危险
但是，我的系统连接到一个古老的负载平衡硬件，强制使用 TLS 1.0 正是我必须做的才能使其工作，即使它“应该”工作……而且它在旧版本的 OpenSSL 上工作得很好。系统上的安全更新可能通过将您更新到存在此问题的 OpenSSL 版本而引入了更改的行为。