php 如何修复 curl：(35) 无法与对等方安全通信：没有通用的加密算法

How to fix curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s)

提问by AMB

I am trying to access and download some .torrentfiles from https://torrage.comusing php curl. But nothing happens , curl_error($ch)gives

我试图访问和下载一些.torrent从文件中https://torrage.com使用php curl。但什么也没发生，curl_error($ch)给

$ch = curl_init ('https://torrage.com/torrent/640FE84C613C17F663551D218689A64E8AEBEABE.torrent');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0');
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_VERBOSE,true);
$data = curl_exec($ch);
$error = curl_error($ch);
curl_close ($ch);
echo $error;

this gives.

这给。

Cannot communicate securely with peer: no common encryption algorithm(s).

If I try from shell like this

如果我像这样从 shell 中尝试

[root@prod1 yum.repos.d]# curl -I https://torrage.com
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).

in verbose mode

在详细模式下

[root@prod1 yum.repos.d]# curl -v https://torrage.com
* Rebuilt URL to: https://torrage.com/
*   Trying 81.17.30.48...
* Connected to torrage.com (81.17.30.48) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Closing connection 0
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).

system info centos 7. x86_64

系统信息centos 7. x86_64

[root@prod1 yum.repos.d]# uname -a
Linux prod1.localdomain 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

curl version

卷曲版本

[root@prod1 yum.repos.d]# curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu)

openssl , already patched.

openssl ，已经打过补丁。

[root@prod1 yum.repos.d]# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Mon Jun 15 18:39:20 UTC 2015
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  dynamic

verifying openssl patched or not.

验证 openssl 是否打补丁。

[root@prod1 yum.repos.d]# rpm -q --changelog openssl | grep CVE-2014-0224
- fix CVE-2014-0224 fix that broke EAP-FAST session resumption support
- fix CVE-2014-0224 - SSL/TLS MITM vulnerability

---

---

What i have tried :

我试过的：

1) i have tried using HTTP insted of HTTPS, but the site forces to use HTTPS. e.g.

1) 我曾尝试使用 HTTP insted of HTTPS，但该站点强制使用 HTTPS。例如

[root@prod1 yum.repos.d]# curl -I http://torrage.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.9.0
Date: Mon, 29 Jun 2015 04:13:17 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://torrage.com/

2) updating ca-bundle.crt

2) 更新 ca-bundle.crt

cp /etc/pki/tls/certs/ca-bundle.crt /root/backup/
curl http://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt

3) Updating Curl to latest version 7.43.0

3) 将 Curl 更新到最新版本 7.43.0

nano /etc/yum.repos.d/city-fan-for-curl.repo

with this repo.

有了这个回购。

[CityFanforCurl]
name=City Fan Repo
baseurl=http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/
enabled=0
gpgcheck=0

and then doing

然后做

yum update curl --enablerepo=CityFanforCurl

then verifying curl version

然后验证 curl 版本

[root@prod1 yum.repos.d]# curl -V
curl 7.43.0 (x86_64-redhat-linux-gnu) libcurl/7.43.0 NSS/3.18 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.6.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets Metalink

4) i have tried this to check whether my curl is outdated or not.

4）我试过这个来检查我的卷曲是否过时。

reference: https://unix.stackexchange.com/questions/162816/disable-sslv3-in-curl

参考：https: //unix.stackexchange.com/questions/162816/disable-sslv3-in-curl

[root@prod1 yum.repos.d]# curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com
HTTP/1.1 200 OK
Server: nginx centminmod
Content-Type: text/html; charset=utf-8
Connection: close
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000; includeSubdomains
Date: Mon, 12 Jan 1970 23:00:11 GMT
X-Page-Speed: ngx_pagespeed
Cache-Control: max-age=0, no-cache

---

---

How can i fix the issue ? and download files from Torrage.com using PHP Curl?

我该如何解决这个问题？并使用PHP Curl?

*I cant use file_get_contents as i am using curl_multifor simultaneous downloads.

*我不能使用 file_get_contents，因为我正在使用它curl_multi进行同步下载。

---

---

Update 1:

更新 1：

As suggested by steffen-ullrich

正如steffen-ullrich所建议的

[root@prod1 randoadmin]# curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 -I https://torrage.com
HTTP/1.1 200 OK
Server: nginx/1.9.0
Date: Mon, 29 Jun 2015 05:54:17 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Mon, 29 Jun 2015 05:50:40 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding, Accept-Encoding
Strict-Transport-Security: max-age=31536000
X-Frame-Options: DENY
X-Content-Type-Options: nosniff

but thats with shell how can i implement it with PHP-curl?

但这就是外壳，我该如何实现它PHP-curl？

Update 2:

更新 2：

i have modified code and defined cipher to use while using curl like this.

我已经修改了代码并定义了密码，以便在像这样使用 curl 时使用。

$ch = curl_init ('https://torrage.com/torrent/640FE84C613C17F663551D218689A64E8AEBEABE.torrent');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0');
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ecdhe_rsa_aes_128_gcm_sha_256');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_VERBOSE,true);
$data = curl_exec($ch);
$error = curl_error($ch);
curl_close ($ch);
echo $error;
echo $data ;

Its working great. Issue solved many thanks to steffen-ullrich.

它的工作很棒。非常感谢steffen-ullrich解决了问题。

回答by Steffen Ullrich

The server supports only ECC ciphers (ECDHE-*). The version of curl is built with the NSS library on Redhat/CentOS. There is a bug report that Redhat/CentOS overrides the curl settings and disables ECC ciphers by default. Because there are thus no ECC ciphers offered by the client but only ECC ciphers are supported by the server the connection will fail.

服务器仅支持 ECC 密码 (ECDHE-*)。curl 的版本是使用 Redhat/CentOS 上的 NSS 库构建的。有一个错误报告，Redhat/CentOS默认覆盖 curl 设置并禁用 ECC 密码。由于客户端不提供 ECC 密码，而服务器仅支持 ECC 密码，因此连接将失败。

You might try to explicitly give the cipher, i.e.

您可能会尝试明确给出密码，即

curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 ...

Note that upgrading OpenSSL would not help because curl is not built with the OpenSSL backend. Also it does not help to disable certificate validation (bad idea anyway) or to change the root CA's since the problem is not related to certificate validation at all.

请注意，升级 OpenSSL 无济于事，因为 curl 不是使用 OpenSSL 后端构建的。此外，禁用证书验证（无论如何都是坏主意）或更改根 CA 也无济于事，因为问题根本与证书验证无关。

Trying to explicitly give the cipher with --ciphers ecdhe_ecdsa_aes_128_shaas the cipher to solve the problem goes into the right direction but will not help in this case, because this is not one of the ciphers supported by the servers. The server supports only various ECDHE-RSA-* ciphers but not ECDHE-ECDSA-* ciphers. See SSLLabsfor details.

试图明确给出密码，--ciphers ecdhe_ecdsa_aes_128_sha因为解决问题的密码是正确的，但在这种情况下无济于事，因为这不是服务器支持的密码之一。服务器仅支持各种 ECDHE-RSA-* 密码，但不支持 ECDHE-ECDSA-* 密码。有关详细信息，请参阅SSLLabs。

回答by Joao Coutinho

If you're on CentOS 7 and are getting these errors while using yum, updating nss nss-util nss-sysinit nss-tools will fix it.

如果您使用的是 CentOS 7 并且在使用 yum 时遇到这些错误，更新 nss nss-util nss-sysinit nss-tools 将修复它。

回答by automated_bot

On Centos 7 or above upgrading the curl to the latest version i.e. 7.29.* fixed the issue for me.

在 Centos 7 或更高版本上，将 curl 升级到最新版本，即 7.29.* 为我解决了这个问题。

回答by Subdigger

There is also possibility to check

也有可能检查

on unix (hope win also):

在 unix 上（希望也能赢）：

> curl -v https://www.youtube.com > test.html

note: replace "https://www.youtube.com" with your domain with protocol

注意：将“ https://www.youtube.com”替换为您的域名和协议

Directing output to test.html so we will only see wanted information on the screen

将输出定向到 test.html 所以我们只会在屏幕上看到想要的信息

result:

结果：

* Rebuilt URL to: https://www.youtube.com/
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2404:6800:4005:80d::200e...
*   Trying 216.58.221.238...
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to www.youtube.com (2404:6800:4005:80d::200e) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS Unknown, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv2, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv2, Unknown (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv2, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv2, Unknown (20):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
*        start date: 2017-11-29 09:44:32 GMT
*        expire date: 2018-02-21 09:37:00 GMT
*        subjectAltName: www.youtube.com matched
*        issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
*        SSL certificate verify ok.
* SSLv2, Unknown (23):
} [data not shown]
> GET / HTTP/1.1
> User-Agent: curl/7.37.0
> Host: www.youtube.com
> Accept: */*
> 
* SSLv2, Unknown (23):
{ [data not shown]
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Expires: Tue, 27 Apr 1971 19:44:06 EST
< Strict-Transport-Security: max-age=31536000
< P3P: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=uk for more info."
< Cache-Control: no-cache
< Date: Tue, 26 Dec 2017 12:26:21 GMT
* Server YouTube Frontend Proxy is not blacklisted
< Server: YouTube Frontend Proxy
< Set-Cookie: YSC=lkUUrudTNJM; path=/; domain=.youtube.com; httponly
< Set-Cookie: PREF=f1=50000000; path=/; domain=.youtube.com; expires=Mon, 27-Aug-2018 00:19:21 GMT
< Set-Cookie: VISITOR_INFO1_LIVE=Qo2rlICrfJM; path=/; domain=.youtube.com; expires=Mon, 27-Aug-2018 00:19:21 GMT; httponly
< Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< 
{ [data not shown]
100   152    0   152    0     0    114      0 --:--:--  0:00:01 --:--:--   114* SSLv2, Unknown (23):
{ [data not shown]
* SSLv2, Unknown (23):
{ [data not shown]
* SSLv2, Unknown (23):
{ [data not shown]
* SSLv2, Unknown (23):

.......... many-other-same-not-interesting-rows .........

{ [data not shown]
* SSLv2, Unknown (23):
{ [data not shown]
100  425k    0  425k    0     0   113k      0 --:--:--  0:00:03 --:--:--  113k
* Connection #0 to host www.youtube.com left intact

See:

看：

* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256

* SSL 连接使用 TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256

and use:

并使用：

curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ECDHE-ECDSA-AES128-GCM-SHA256');

回答by Walt

Neither of the above worked for me. I suspected it had to do with Curl version. Curl_version();returned 7.29, while on the server I installed 7.49.1, which probably had those SSL issues fixed.

以上都不适合我。我怀疑这与 Curl 版本有关。Curl_version();返回 7.29，而我在服务器上安装了 7.49.1，这可能修复了那些 SSL 问题。

Suddenly I remembered about Cloudflare and disabled CDN just in case. Curl started working. Then I switched to PHP 7 and Curl started working even with Cloudflare CDN on. Curl_version();started returning 7.49.1.

突然我想起了 Cloudflare 并禁用了 CDN 以防万一。Curl 开始工作。然后我切换到 PHP 7，即使在 Cloudflare CDN 上，Curl 也开始工作。Curl_version();开始返回 7.49.1。

I don't know how that worked and what exactly happened, but after tireless hours of looking for the solution this was what I found.

我不知道它是如何工作的以及究竟发生了什么，但经过几个小时的不知疲倦地寻找解决方案，这就是我发现的。