$ curl -I https://9.185.173.135
curl: (35) Unknown SSL protocol error in connection to 9.185.173.135:443
This is an secured page that I need to access. But I don’t know how to obtain its certificate file. I tried to use Firefox, but it says couldn’t get any ssl certificate once the url is entered.
$ curl -I http://9.185.173.135
HTTP/1.1 200 OK
Content-Length: 686
Content-Type: text/html
Content-Location: http://9.185.173.135/Default.htm
Last-Modified: Mon, 16 Mar 2009 05:05:38 GMT
Accept-Ranges: bytes
ETag: "a851dbd8f4a5c91:d41"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 13 Jul 2010 04:09:35 GMT
The server is definitely reachable from my laptop. Once I get the certificate file, I assume I can then import it to Firefox and then use my credentials to pass the authentication (I already got the username/password).
Sorry I am no expert in security at all. Is there anything else I can try?
Many thanks in advance.
asked Jul 13, 2010 at 4:11
Michael MaoMichael Mao
9,70823 gold badges75 silver badges91 bronze badges
4
try this
curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv3); // Force SSLv3 to fix Unknown SSL Protocol error
answered Jun 5, 2013 at 11:44
4
To Rudi : Thanks for the hint, that tells me a hell lot of info.
Somehow the admin of the secured page «refreshes» the state of certifications every day. So although I got blocked from accessing it yesterday, it generously lets me to grab another certificate and add it to the exception list of Firefox.
So everything is working, and I really learn something from yesterday’s experience.
answered Jul 13, 2010 at 22:43
Michael MaoMichael Mao
9,70823 gold badges75 silver badges91 bronze badges
You can use --tlsv1 option to solve the issue in case the curl version is below 7.34
curl -I --tlsv1 https://9.185.173.135
answered Jul 16, 2019 at 6:21
1
In my case on a AIX VM also this problem, use --cacert to specific a cacert.pem
curl --cacert /var/ssl/cacert.pem https://localhost:3000
edbighead
4,9675 gold badges27 silver badges34 bronze badges
answered Jun 5, 2020 at 8:01
1
I got the same error when running curl/httpie against a Tomcat server on my localhost deployed from Eclipse. It turns out that default server.xml deployed by Eclipse disables https. Specifically, the section below is commented out in server.xml.
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
After uncommenting it out and adding the two keystore parameters, the curl command starts working (with —insecure option if the certificate is self-signed).
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
keystoreFile="/path/to/your/keystore"
keystorePass="yourpass" />
answered Aug 17, 2016 at 20:22
Big PumpkinBig Pumpkin
3,5471 gold badge25 silver badges18 bronze badges
i have some solutions that fix the issue for me:
1] try update your curl/php/apache [ yum update ]
2] restart apache
Those worked for me!
answered Oct 19, 2017 at 8:06
mr.baby123mr.baby123
2,16822 silver badges12 bronze badges
I had the same error after updating my SSL certificate on the target SSL site.
My source OS was Centos 6 and updating to a new curl version solved it.
*Note I was already using the curl -k (insecure option) but I would still get that error. Essentially this error is caused by nss or openssl being out of date.
yum -y install curl nss openssl
Remember if you have a web application like PHP calling curl you will need to restart Apache to make the update take effect.
I’ve updated based on this guide: http://realtechtalk.com/curl_35_Unknown_SSL_protocol_error_in_connection_Solution_Centos-1988-articles
answered Apr 26, 2016 at 21:37
I had a similar issue:
curl https://localhost:3000
...
curl: (35) Unknown SSL protocol error in connection to localhost:-9847
(not sure where that number -9847came from since I requested port 3000)
fix: turns out my server on port 3000 was running «http» not «https» go figure.
answered Oct 4, 2018 at 6:04
rogerdpackrogerdpack
60.4k35 gold badges259 silver badges379 bronze badges
I did this
curl -v https://packagist.org
curl -v --insecure https://packagist.org
I also tried wget -q -S -O - https://packagist.org and it works perfectly without any errors.
I expected the following
Response from server.
I received the following
* Rebuilt URL to: https://packagist.org/
* Trying 144.217.203.53...
* TCP_NODELAY set
* Connected to packagist.org (144.217.203.53) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to packagist.org:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to packagist.org:443
curl/libcurl version
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
operating system
Distributor ID: Debian
Description: Debian GNU/Linux 9.3 (stretch)
Release: 9.3
Codename: stretch
I can’t reproduce that here in Ubuntu. I also tried in Windows using libcurl and each of mbedTLS, OpenSSL, WinSSL and wolfSSL. Is it possible something is intercepting the connection? Can you still reproduce? Do other https requests work?
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2j zlib/1.2.8 nghttp2/1.18.1 librtmp/2.3
curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.23.1 librtmp/2.3
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.0.2n zlib/1.2.8 nghttp2/1.30.0 librtmp/2.3
Is it possible something is intercepting the connection?
I don’t know how to check it. If you have any suggestions, please share it. This machine connected directly to provider coaxial modem and problem is still there. Actually problem is not new, I was witnessing it at least few months but I’ve decided to do something with it 
I also have a couple of other machines (with Windows 10) it the same network and I cannot reproduce problem from these machines.
Results of fresh tests:
Debian 9 machine (with problems):
curl https://google.com -v --cacert /home/qcl/curl-ca-bundle.crt
* Rebuilt URL to: https://google.com/
* Trying 172.217.2.174...
* TCP_NODELAY set
* Connected to google.com (172.217.2.174) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /home/qcl/curl-ca-bundle.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to google.com:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to google.com:443
Windows 10 machine (no problems):
curl https://google.com -v --cacert C:curlcurl-ca-bundle.crt
* Rebuilt URL to: https://google.com/
* Trying 2607:f8b0:400b:808::200e...
* TCP_NODELAY set
* Connected to google.com (2607:f8b0:400b:808::200e) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: C:curlcurl-ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
* start date: Jan 23 13:36:00 2018 GMT
* expire date: Apr 17 13:36:00 2018 GMT
* subjectAltName: host "google.com" matched cert's "google.com"
* issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Location: https://www.google.ca/?gfe_rd=cr&dcr=0&ei=T7N-WrKGF4aR8QeJ7oioDA
< Content-Length: 269
< Date: Sat, 10 Feb 2018 08:54:39 GMT
< 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"
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.ca/?gfe_rd=cr&dcr=0&ei=T7N-WrKGF4aR8QeJ7oioDA">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact
Do other https requests work?
No. No one HTTPS request works.
If you need any additional information, please tell me. I don’t know which information may be helpful in this case.
#1681 is another report with the same curl on stretch, but that only affected a select host.
On the affected computer use wireshark and set capture filter host test.com and then run curl https://test.com. Check to make sure the capture only contains the attempt to connect to test.com. Stop the capture, save it, .zip it [1] and then upload it here.
[1]: GitHub only allows certain file types like zip. Also, before zipping it you may want to remove possibly sensitive information from the packet capture such as IP/MAC by using TraceWrangler, but disable remove unknown layers.
@mrsmallyi, thank you for suggestion but this solution does not help in my case, errors are the same.
@jay, I was wrong when I said «No one HTTPS request work». Requests to https://test.com suddenly work. However requests to https://google.com and https://packagist.org still lead to error.
I’ve captured three dumps: one of them contains successful request to test.com, another one contains failed request to packagist.org and third one contains successful request to packagist.org using wget.
Dumps: dump-curl-test-20180211.zip
Logs of requests:
Failed request (https://packagist.org using curl):
curl https://packagist.org -v
* Rebuilt URL to: https://packagist.org/
* Trying 144.217.203.53...
* TCP_NODELAY set
* Connected to packagist.org (144.217.203.53) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to packagist.org:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to packagist.org:443
Successful request (https://packagist.org using wget):
wget -S -O - https://packagist.org
--2018-02-11 05:05:01-- https://packagist.org/
Resolving packagist.org (packagist.org)... 144.217.203.53, 2607:5300:60:7113::3
Connecting to packagist.org (packagist.org)|144.217.203.53|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 11 Feb 2018 10:05:01 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
Set-Cookie: packagist=08pqb21q7i8ev1q6c1ks6auvv3; expires=Sun, 11-Feb-2018 11:05:01 GMT; Max-Age=3600; path=/; secure; HttpOnly
Cache-Control: private, must-revalidate
Strict-Transport-Security: max-age=31104000
pragma: no-cache
expires: -1
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' *.algolia.net *.algolianet.com; font-src 'self' https://fonts.gstatic.com/; img-src 'self' https://www.gravatar.com/ https://camo.githubusercontent.com/ https://ssl.google-analytics.com/ http://www.google-analytics.com/; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net/ https://ssl.google-analytics.com/; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/ https://fonts.googleapis.com/
X-Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' *.algolia.net *.algolianet.com; font-src 'self' https://fonts.gstatic.com/; img-src 'self' https://www.gravatar.com/ https://camo.githubusercontent.com/ https://ssl.google-analytics.com/ http://www.google-analytics.com/; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net/ https://ssl.google-analytics.com/; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/ https://fonts.googleapis.com/
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
Length: unspecified [text/html]
Saving to: ‘STDOUT’
- [<=> ] 0 --.-KB/s <!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Packagist</title>
<meta name="description" content="The PHP Package Repository" />
<meta name="author" content="Jordi Boggiano" />
...
Successful request (https://test.com using curl)
* Rebuilt URL to: https://test.com/
* Trying 69.172.200.235...
* TCP_NODELAY set
* Connected to test.com (69.172.200.235) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: OU=Domain Control Validated; OU=nsProtect Secure Xpress; CN=www.test.com
* start date: Jan 15 00:00:00 2017 GMT
* expire date: Jan 24 23:59:59 2020 GMT
* subjectAltName: host "test.com" matched cert's "test.com"
* issuer: C=US; ST=VA; L=Herndon; O=Network Solutions L.L.C.; CN=Network Solutions DV Server CA 2
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: test.com
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.13.4
< Date: Sun, 11 Feb 2018 09:30:04 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Keep-Alive: timeout=20
< Location: https://www.test.com/
< X-DIS-Request-ID: bdf804ffc0cd5ff24958ca932b1457ae
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.13.4</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host test.com left intact
The ClientHello is essentially the same for both the good and the bad connection. For bad conn to packagist.com there is no reply received to the ClientHello, despite several retransmissions over the next minute. Exactly 1 minute after the ClientHello the server initiates a close FIN which is what packagist would do without receiving one. Also if you look at the TSecr (timestamp echo reply) the number is from before the ClientHello was sent, meaning it has not received the ClientHello or the retransmissions, since if it did it could send any one of those as the echoreply.
I don’t know why it’s happening but I doubt it has to do with curl. It’s possible something curl does may contribute, for example the ClientHello may be seen as too big and rejected by some middleman? Are you in China and maybe some of these hosts are blocked? That doesn’t explain why wget isn’t doing that or its ClientHello is otherwise different and can pass through. Try making the ClientHello smaller by only sending a single cipher, for example here is a cipher that connected you to test.com and also works for me for packagist.com:
curl -v --cipher ECDHE-RSA-AES256-GCM-SHA384 https://packagist.com
Also I’m curious what ClientHello wget is sending that works.
Are you in China and maybe some of these hosts are blocked?
No, I’m in Toronto and in this case it would affect the other devices in the network too. And wget also works…
Try making the ClientHello smaller by only sending a single cipher, for example here is a cipher that connected you to test.com and also works for me for packagist.com
Yes. it works. But regular request without ‘cipher’ option still does not work. I’m not sure I totally understand what cipher is and what did I change using this option. I would you very appreciate if you explain it Also, do you have any idea, what further actions can I do to solve my problem?
Dump: curl-test-packagist-org-cipher-20180212.zip
Log:
curl -v --cipher ECDHE-RSA-AES256-GCM-SHA384 https://packagist.org
* Rebuilt URL to: https://packagist.org/
* Trying 144.217.203.53...
* TCP_NODELAY set
* Connected to packagist.org (144.217.203.53) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ECDHE-RSA-AES256-GCM-SHA384
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=DE; L=Berlin; O=Packagist Conductors UG (haftungsbeschr▒nkt); CN=packagist.org
* start date: Jul 12 00:00:00 2017 GMT
* expire date: Aug 25 12:00:00 2020 GMT
* subjectAltName: host "packagist.org" matched cert's "packagist.org"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: packagist.org
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 12 Feb 2018 23:54:45 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Vary: Accept-Encoding
< Set-Cookie: packagist=ffdshrd5v45qkjhl28o3un0u93; expires=Tue, 13-Feb-2018 00:54:45 GMT; Max-Age=3600; path=/; secure; HttpOnly
< Cache-Control: private, must-revalidate
< Strict-Transport-Security: max-age=31104000
< pragma: no-cache
< expires: -1
< X-Frame-Options: DENY
< Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' *.algolia.net *.algolianet.com; font-src 'self' https://fonts.gstatic.com/; img-src 'self' https://www.gravatar.com/ https://camo.githubusercontent.com/ https://ssl.google-analytics.com/ http://www.google-analytics.com/; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net/ https://ssl.google-analytics.com/; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/ https://fonts.googleapis.com/
< X-Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' *.algolia.net *.algolianet.com; font-src 'self' https://fonts.gstatic.com/; img-src 'self' https://www.gravatar.com/ https://camo.githubusercontent.com/ https://ssl.google-analytics.com/ http://www.google-analytics.com/; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net/ https://ssl.google-analytics.com/; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/ https://fonts.googleapis.com/
< X-Xss-Protection: 1; mode=block
< Referrer-Policy: strict-origin-when-cross-origin
< X-Content-Type-Options: nosniff
<
<!DOCTYPE html>
Please try packagist.com not packagist.org. Sometimes you are referring to one and sometimes the other and I examined packagist.com which is in your first trace. Monitor host 54.72.156.240 and try both of:
curl -v --resolve packagist.com:443:54.72.156.240 https://packagist.com
curl -v --cipher ECDHE-RSA-AES256-GCM-SHA384 --resolve packagist.com:443:54.72.156.240 https://packagist.com
Please try packagist.com not packagist.org. Sometimes you are referring to one and sometimes the other
I did this mistake once and then I noticed that and remade tests and edited my comment. If you take a look to all my comments you’ll see only packagist.org in them. Anyway, there is no difference in results between any of hosts of both packagist.org and packagist.com.
Monitor host 54.72.156.240 and try both
I did it.
Dumps: curl-test-packagist.com-2018-02-13.zip
Logs:
Unsuccessful regular request to https://packagist.com using curl:
curl -v --resolve packagist.com:443:54.72.156.240 https://packagist.com
url -v --resolve packagist.com:443:54.72.156.240 https://packagist.com
* Added packagist.com:443:54.72.156.240 to DNS cache
* Rebuilt URL to: https://packagist.com/
* Hostname packagist.com was found in DNS cache
* Trying 54.72.156.240...
* TCP_NODELAY set
* Connected to packagist.com (54.72.156.240) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to packagist.com:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to packagist.com:443
Successful request to https://packagist.com using curl with one cipher:
curl -v --cipher ECDHE-RSA-AES256-GCM-SHA384 --resolve packagist.com:443:54.72.156.240 https://packagist.com
* Added packagist.com:443:54.72.156.240 to DNS cache
* Rebuilt URL to: https://packagist.com/
* Hostname packagist.com was found in DNS cache
* Trying 54.72.156.240...
* TCP_NODELAY set
* Connected to packagist.com (54.72.156.240) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ECDHE-RSA-AES256-GCM-SHA384
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=packagist.com
* start date: Sep 15 00:00:00 2017 GMT
* expire date: Oct 15 12:00:00 2018 GMT
* subjectAltName: host "packagist.com" matched cert's "packagist.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55ff3708cc00)
> GET / HTTP/1.1
> Host: packagist.com
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Tue, 13 Feb 2018 13:00:11 GMT
< content-type: text/html; charset=UTF-8
< server: nginx
< vary: Accept-Encoding
< set-cookie: PHPSESSID=48692f734925c98ba6c1c011a5d92014; path=/; secure; HttpOnly
< cache-control: no-cache, private
< x-content-type-options: nosniff
< strict-transport-security: max-age=31104000
< x-frame-options: DENY
< content-security-policy: default-src 'self'; block-all-mixed-content; connect-src 'self' https://api.intercom.io https://api-iam.intercom.io https://api-ping.intercom.io https://nexus-websocket-a.intercom.io https://nexus-websocket-b.intercom.io https://nexus-long-poller-a.intercom.io https://nexus-long-poller-b.intercom.io wss://nexus-websocket-a.intercom.io wss://nexus-websocket-b.intercom.io https://uploads.intercomcdn.com https://uploadsintercomusercontent.coms-websocket-b.intercom.io; font-src 'self' fonts.gstatic.com https://js.intercomcdn.com; frame-src api.recurly.com; img-src data: *; media-src https://js.intercomcdn.com; script-src 'self' www.google-analytics.com js.recurly.com https://app.intercom.io https://widget.intercom.io https://js.intercomcdn.com 'unsafe-inline' 'sha256-UCscuFdInH+Tb2zoqU/yYIJdpqP4aF+6hny3ClW5DfU=' 'sha256-1gcjkQmF3vDBHqTK/GCaJKMg/UjNNomsjObGfUSd8GU=' 'sha256-DcokebrOSmWciSX1qQC5mQVZVTuYP7rxG1GdCn4I4Ls='; style-src 'self' fonts.googleapis.com 'unsafe-inline'
< x-content-security-policy: default-src 'self'; block-all-mixed-content; connect-src 'self' https://api.intercom.io https://api-iam.intercom.io https://api-ping.intercom.io https://nexus-websocket-a.intercom.io https://nexus-websocket-b.intercom.io https://nexus-long-poller-a.intercom.io https://nexus-long-poller-b.intercom.io wss://nexus-websocket-a.intercom.io wss://nexus-websocket-b.intercom.io https://uploads.intercomcdn.com https://uploadsintercomusercontent.coms-websocket-b.intercom.io; font-src 'self' fonts.gstatic.com https://js.intercomcdn.com; frame-src api.recurly.com; img-src data: *; media-src https://js.intercomcdn.com; script-src 'self' www.google-analytics.com js.recurly.com https://app.intercom.io https://widget.intercom.io https://js.intercomcdn.com 'unsafe-inline' 'sha256-UCscuFdInH+Tb2zoqU/yYIJdpqP4aF+6hny3ClW5DfU=' 'sha256-1gcjkQmF3vDBHqTK/GCaJKMg/UjNNomsjObGfUSd8GU=' 'sha256-DcokebrOSmWciSX1qQC5mQVZVTuYP7rxG1GdCn4I4Ls='; style-src 'self' fonts.googleapis.com 'unsafe-inline'
< x-xss-protection: 1; mode=block
<
<!DOCTYPE html>
...
Successful request to https://packagist.com using wget:
wget -S -O - https://packagist.com
--2018-02-13 08:09:55-- https://packagist.com/
Resolving packagist.com (packagist.com)... 54.72.156.240, 54.76.37.177, 54.246.163.107
Connecting to packagist.com (packagist.com)|54.72.156.240|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Tue, 13 Feb 2018 13:09:56 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: nginx
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=4aa182b3aab87262ad0eb05d15070048; path=/; secure; HttpOnly
Cache-Control: no-cache, private
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31104000
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' https://api.intercom.io https://api-iam.intercom.io https://api-ping.intercom.io https://nexus-websocket-a.intercom.io https://nexus-websocket-b.intercom.io https://nexus-long-poller-a.intercom.io https://nexus-long-poller-b.intercom.io wss://nexus-websocket-a.intercom.io wss://nexus-websocket-b.intercom.io https://uploads.intercomcdn.com https://uploadsintercomusercontent.coms-websocket-b.intercom.io; font-src 'self' fonts.gstatic.com https://js.intercomcdn.com; frame-src api.recurly.com; img-src data: *; media-src https://js.intercomcdn.com; script-src 'self' www.google-analytics.com js.recurly.com https://app.intercom.io https://widget.intercom.io https://js.intercomcdn.com 'unsafe-inline' 'sha256-UCscuFdInH+Tb2zoqU/yYIJdpqP4aF+6hny3ClW5DfU=' 'sha256-1gcjkQmF3vDBHqTK/GCaJKMg/UjNNomsjObGfUSd8GU=' 'sha256-DcokebrOSmWciSX1qQC5mQVZVTuYP7rxG1GdCn4I4Ls='; style-src 'self' fonts.googleapis.com 'unsafe-inline'
X-Content-Security-Policy: default-src 'self'; block-all-mixed-content; connect-src 'self' https://api.intercom.io https://api-iam.intercom.io https://api-ping.intercom.io https://nexus-websocket-a.intercom.io https://nexus-websocket-b.intercom.io https://nexus-long-poller-a.intercom.io https://nexus-long-poller-b.intercom.io wss://nexus-websocket-a.intercom.io wss://nexus-websocket-b.intercom.io https://uploads.intercomcdn.com https://uploadsintercomusercontent.coms-websocket-b.intercom.io; font-src 'self' fonts.gstatic.com https://js.intercomcdn.com; frame-src api.recurly.com; img-src data: *; media-src https://js.intercomcdn.com; script-src 'self' www.google-analytics.com js.recurly.com https://app.intercom.io https://widget.intercom.io https://js.intercomcdn.com 'unsafe-inline' 'sha256-UCscuFdInH+Tb2zoqU/yYIJdpqP4aF+6hny3ClW5DfU=' 'sha256-1gcjkQmF3vDBHqTK/GCaJKMg/UjNNomsjObGfUSd8GU=' 'sha256-DcokebrOSmWciSX1qQC5mQVZVTuYP7rxG1GdCn4I4Ls='; style-src 'self' fonts.googleapis.com 'unsafe-inline'
X-XSS-Protection: 1; mode=block
Length: unspecified [text/html]
Saving to: ‘STDOUT’
- [<=> ] 0 --.-KB/s <!DOCTYPE html>
...
Can I use only one cipher as a temporary solution? Is it possible to set this option in config permanently?
Unsuccessful regular request to https://packagist.com using curl:
Thanks I downloaded the capture and was unable to reproduce. I extracted the raw ClientHello and sent it like this:
nc -q90 54.72.156.240 443 < curl-test-packagist-com_ClientHello.raw
I received a ServerHello in reply. Since I am now sending the exact same ClientHello and receiving a reply I believe there is something on your end interfering with the traffic that prevents the ClientHello from being received by the server. My guess is it has something to do with the size of the ClientHello.
Attached are the files I used to reproduce and also several files where I modified the raw data in the ClientHello for making the length of data in the padding extension 1, 0, and also removing the padding extension. In all cases I received a ServerHello in reply. You can try sending the raw data in netcat and monitor in Wireshark to see if you receive a server reply to any of them. (Note nc option -q90 is wait 90 seconds after sending, probably unnecessary and this server should terminate after 1 min if no ServerHello.)
ClientHello_sent_via_nc__anon.zip
It is possible to stop libcurl from requesting the ClientHello be padded by removing flag SSL_OP_TLSEXT_PADDING from SSL_OP_ALL:
diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c index 2a6b3cf..94092d0 100644 --- a/lib/vtls/openssl.c +++ b/lib/vtls/openssl.c @@ -2181,6 +2181,9 @@ static CURLcode ossl_connect_step1(struct connectdata *con ctx_options = SSL_OP_ALL; + /* disable padding test */ + ctx_options &= ~SSL_OP_TLSEXT_PADDING; + #ifdef SSL_OP_NO_TICKET ctx_options |= SSL_OP_NO_TICKET; #endif
Can I use only one cipher as a temporary solution? Is it possible to set this option in config permanently?
I think that would cause more problems than it would solve if you put it in the curlrc. There’s no guarantee an arbitrary server that you connect to will accept that cipher. For that server specifically even it could stop accepting that cipher.
Impressive research @jay!
This clienthello extension extension is even documented in RFC 7685 and the RFC says:
As an example, consider a client that wishes to avoid sending a
ClientHello with a TLSCiphertext.length between 256 and 511 bytes
(inclusive). This case is considered because at least one TLS
implementation is known to hang the connection when such a
ClientHello record is received.
So, while this is clearly not a curl bug we can of course discuss whether to add support for this padding option.
@jay, I successfully receive response for raw ClientHello packet. However, I still cannot receive response for ClientHello sent by curl.
Dumps: curl-raw-ClientHello.zip
It is possible to stop libcurl from requesting the ClientHello be padded by removing flag
Is it possible for me to apply this patch somehow?
@bagder, I would very appreciate if you describe, how I can do that. I installed curl by command apt-get install curl. If I understand right, I have to do next steps:
- Download sources.
- Apply patch (https://www.thegeekstuff.com/2014/12/patch-command-examples).
- Compile library (how?).
- Replace installed library with compiled library.
Is that correct sequence? If is so, what should I do on the step 3?
Experiencing same in latest Jenkins LTS docker image behind a corporate firewall. wget works while curl fails:
jenkins@501c9ac248ea:/tmp$ curl -v --insecure https://google.com
* Rebuilt URL to: https://google.com/
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to (nil) (x.x.x.x) port 8080 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to x.x.x.x:8080
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to x.x.x.x:8080
jenkins@501c9ac248ea:/tmp$ wget -v --no-check-certificate https://google.com
--2018-04-16 19:09:59-- https://google.com/
Connecting to x.x.x.x:8080... connected.
WARNING: The certificate of ‘google.com’ is not trusted.
WARNING: The certificate of ‘google.com’ hasn't got a known issuer.
Proxy request sent, awaiting response... 301 Moved Permanently
Location: https://www.google.com/ [following]
--2018-04-16 19:09:59-- https://www.google.com/
Connecting to x.x.x.x:8080... connected.
WARNING: The certificate of ‘www.google.com’ is not trusted.
WARNING: The certificate of ‘www.google.com’ hasn't got a known issuer.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 10.42K --.-KB/s in 0.07s
2018-04-16 19:10:00 (151 KB/s) - ‘index.html’ saved [10672]
curl —version
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
We have no reason to believe this is a curl problem. If you have more information that makes you think what you are reporting is different then please open a new issue.
I’m going to add an item to the TODO about this extension and then move to close this issue.
The padding AFAIK is added by default by the ssl backend when necessary but the patch here disables that for openssl. Too little is known about why the padding would be causing the issue so I don’t think it’s appropriate to add even as an option.
lock
bot
locked as resolved and limited conversation to collaborators
Jul 29, 2018
Q: On one of our server, the webserver is not setup to support SSLv2 or SSLv3. Both are disabled on the server side. It supports only TLSv1. How can I get curl to work from both command line, and from inside my PHP code?
A: In most case, curl will automatically pick the correct protocol and connect to it. But, you can also specify a specific protocol to use for curl command. In this example, you have to instruct CURL to use TLSv1, as explained in this tutorial.
Specify Protocol on Curl Command Line
The following are the various protocol options supported on the command line by curl:
- -0 (or) –http1.0 for HTTP 1.0 (H)
- -1 (or) –tlsv1 for TLSv1 (SSL)
- -2 (or) –sslv2 for SSLv2 (SSL)
- -3 (or) –sslv3 for SSLv3 (SSL)
In this example, this particular server, works on regular HTTP. No issues here.
$ curl http://192.168.101.1 <html><body><h1>It works!</h1></body></html>
Refer this: 15 Practical Linux cURL Command Examples
But, if you use SSLv3, using the -3 option, it returns the “sslv3 alert handshake failure” error message.
$ curl -3 https://192.168.101.1 curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
If you use SSLv2, using -2 option, it returns the “Unknown SSL protocol” error message.
$ curl -2 https://192.168.101.1 curl: (35) Unknown SSL protocol error in connection to 192.168.101.1:443
In this case, on this particular server, it supports only TLS. So, use -1 option as shown below.
$ curl -1 https://192.168.101.1 curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
In this case, since we are using the ip-address, which doesn’t match the SSL certificate that is installed on the webserver. So, we are getting the above “SSL3_GET_SERVER_CERTIFICATE:certificate verify failed” error message.
Curl by default performs the SSL cert verification. If you are using a CA authority bundle, then the default bundle name is curl-ca-bundle.crt. You can specify a different bundle using the –cacert option.
But, in our case, we want to use the TLSv1 protocol, but without the SSL certificate verification. For this, use the -k option (or –insecure option), which will not perform the SSL certificate verification.
The following is a usage of the -k option.
$ curl -k https://192.168.101.1 curl: (35) Unknown SSL protocol error in connection to 192.168.101.1:443
If you want to know more details about the error thrown by CURL command, use -v option. As you see below. Even when we didn’t pass the protocol option, from the command output, we can see it is trying to use SSLv2 for this.
$ curl -k -v https://192.168.101.1 * About to connect() to 192.168.101.1 port 443 * Trying 192.168.101.1... connected * Connected to 192.168.101.1 (192.168.101.1) port 443 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv2, Client hello (1): Unknown SSL protocol error in connection to 192.168.101.1:443 * Closing connection #0 curl: (35) Unknown SSL protocol error in connection to 192.168.101.1:443
Solution From Command Line
Refer this: wget vs curl: How to Download Files Using wget and curl
So, in our case, since SSLv2 and SSLv3 are disabled on the server side, and for some reason if the curl doesn’t automatically set the right protocol, the following works when we want to use only TLSv1 protocol with curl from command line as shown below.
$ curl -k -1 https://192.168.101.1 <html><body><h1>It works!</h1></body></html>
If you want to see the details of what exactly this does, pass the -v option as shown below.
$ curl -k -1 -v https://192.168.101.1
The above can also be done using the following alternative options
$ curl --insecure --tlsv1 --verbose https://192.168.101.1
Again, in the above command:
- -1 (or) –tlsv1 for TLSv1 (SSL)
- -k (or) –insecure to Allow connections to SSL sites without certs (H)
- -v (or) –verbose to Make the operation more talkative (lower case v)
Solution From PHP
From your PHP code, if you are using the cURL functions, and like to set the protocol options, you should use curl_setopt or curl_setopt_array function.
Use curl_setopt if you want to set only one option.
curl_setopt($c, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
In the above:
- $c is the curl variable that you got from the curl_init() function, when you created a new cURL resource from your PHP program.
- CURLOPT_SSLVERSION is a curl option name.
- CURL_SSLVERSION_TLSv1 is a curl value for the corresponding option in parameter#2
You can also use a numer instead of “CURL_SSLVERSION_TLSv1”. In this example, this is equivalent to 1.
curl_setopt($c, CURLOPT_SSLVERSION, 1);
The following are possible CURLOPT_SSLVERSION values you can set. You can either use the descriptive constant or the corresponding number that are shown below.
- CURL_SSLVERSION_DEFAULT (0)
- CURL_SSLVERSION_TLSv1 (1)
- CURL_SSLVERSION_SSLv2 (2)
- CURL_SSLVERSION_SSLv3 (3)
- CURL_SSLVERSION_TLSv1_0 (4)
- CURL_SSLVERSION_TLSv1_1 (5)
- CURL_SSLVERSION_TLSv1_2 (6)
When you want to set multiple CURL option, use the curl_setopt_array as shown below. Here, apart from setting the CURLOPT_SSLVERSION, it also set’s few other curl options.
In this case, the 2nd parameter will be an array which will contain multiple CURL options as shown below.
curl_setopt_array($c, array ( CURLOPT_SSL_VERIFYHOST => 0, CURLOPT_SSL_VERIFYPEER => 0, CURLOPT_SSLVERSION => 1 ));
I see a lot of people hitting this site looking for reasons as to why curl is logging the following message when an SSL connection is attempted:
curl: (35) Unknown SSL protocol error in connection to ${some_server}
So, I thought it would be helpful to publish my 3 most common reasons why I’ve experienced this error during my web mastering career. It should not serve as an end-all list but it should provide some quick pointers.
- The Destination Site Does Not Like the Protocol
Let’s take my Techstacks Tools site as an example. Firing off a request like the following, results in the Unknown SSL Protocol error:
curl --sslv2 https://techstacks-tools.appspot.com/Why? Well, in this case it is because the techstacks tools site does not support SSLv2, thus, generating the curl (35) error.
- The Destination Site Does Not Like the Cipher
You could be trying to connect to the site using an ssl cipher that the site is configured to reject. For example, anonymous ciphers are typically disabled on ssl-encrypted sites that are customer-facing. (Many of us set a blanket rejection policy on any SSL-encrypted web site—regardless of it’s purpose.) The following command string «can» also result in the curl (35) error:
curl --ciphers ADH-RC4-MD5 https://some_web_site.some_domain.com/Unfortunately, the type of error response you can get from curl depends largely upon the ssl server. On some sites, you’ll receive the Unknown SSL Protocol error but on my techstacks-tools site, I get:
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failureKudos to Google because this particular error is a bit more descriptive than the one my websites at work generate because this at least tells you that a ssl socket was started but because of handshake failures, the socket was never able to complete.
Try connecting to the site with a cipher that the site supports. Not sure which cipher to use? Well, let me introduce my cryptonark ssl cipher tester…
- The SSL Private Key Has Expired
I came across this one earlier today working with an old WebSeAL site. In IBM GSKit, you can specify how long the private key password is valid. After reaching a certain date, you will still be able to get webseal started and listening on port 443 (or whatever you set your https-port value to) but you will not be able to successfully negotiate an SSL session. In today’s case, the old WebSEAL instance was using long-expired kdb file with a long expired private key password. Once replaced with the correct, more-up-to-date version, everything worked again.
UPDATE (March 15, 2012): Since publishing this post two years ago, I have learned that you can see unknown protocol errors for another somewhat common reason. Some ISP’s and DNS providers like to intercept your failed DNS queries in order to redirect you to a search engine results-style page offering you alternative URLs or «Did you mean…?» counter-query results. If you see an error like this: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol, it could be due to you typing the hostname incorrectly or the hostname is not yet tabled in your DNS. You can verify that with a simple «host» or «nslookup».
Do you try to activate a license key and get one of the curl errors below?
cURL error 35: Unknown SSL protocol error in connection to wp-staging.com:443
or
cURL error 28: Operation timed out after 100001 milliseconds with 0 out of 0 bytes received
The first cURL error 35 happens because your site is trying to connect to WP STAGING servers but failing because the connection method your server is using is not supported anymore. (If you are familiar with SSL: We switched off support for TLS 1.0)
What needs to be updated is curl and OpenSSL.You should update not only for the functionality of WP STAGING and your SSL connections but also for the security of your website in general!
If you are not hosting the site yourself, you will need to reach out to your host and ask them to update the curl and the TLS version.
If you are not able to update curl and OpenSSL and your host is refusing it, you can contact us, and we will create a workaround for you to be able to use the push function without activating the license key.
Despite that, updating curl and OpenSSL on your server is highly recommended for security purposes.
cURL error 28
This cURL error can happen if the firewall on your server blocks outgoing connections to wp-staging.com.
Please allow your server to open a connection to wp-staging.com to solve this. Usually, your hosting provider is the first contact person for doing that.
You will not able to update WP STAGING automatically until both cURL errors are solved, but you can still always download the latest version from your account.
Updated on December 18, 2022
I can’t seem to connect to a specific server over SSL from our Ubuntu servers. Locally, on my Mac, it works flawlessly.
The server address: powerschool.spokaneschools.org
curl -v https://powerschool.spokaneschools.org output:
- Rebuilt URL to: https://powerschool.spokaneschools.org/
- Hostname was NOT found in DNS cache
- Trying 206.193.1.72…
- Connected to powerschool.spokaneschools.org (206.193.1.72) port 443 (#0)
- successfully set certificate verify locations:
- CAfile: none CApath: /etc/ssl/certs
- SSLv3, TLS handshake, Client hello (1):
- Unknown SSL protocol error in connection to powerschool.spokaneschools.org:443
- Closing connection 0 curl: (35) Unknown SSL protocol error in connection to powerschool.spokaneschools.org:443
openssl s_client -connect powerschool.spokaneschools.org:443 output:
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1466726411
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I tried checking the site in different SSL check tools, all seem to be OK (apart from some security issues). I have no issues connecting to other servers, even within that domain.
OS
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty
$ curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon May 2 16:53:18 UTC 2016
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -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: "/usr/lib/ssl"