When I try to execute this curl command :
curl -v --key some_key_file.key --cert certificate_file.pem --show-error --header "Content-Type: application/json;charset=UTF-8" https://some-api/service
I get the following error : curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
And the full execution log :
I have searched this error online and haven't found anyone explaining what it really meant.
Do you have any idea what the source cause could be ?
And do you know if there is a way to get more information about the error ?
Turns out the problem was with my curl version which, for some reason didn't accept the arguments --cert and --key.
To solve the problem, I installed a completely new curl version and ran it from the instllation folder and it worked.
Run the command from the path where you have curl package.
if you place in c:\curl goto this path and run the curl command it will work.
I also try installing latest curl (given below) but it didn't solve my issue.
curl 7.77.0 (x86_64-pc-win32) libcurl/7.77.0 OpenSSL/1.1.1k (Schannel)
zlib/1.2.11 brotli/1.0.9 zstd/1.5.0 libidn2/2.3.1 libssh2/1.9.0
nghttp2/1.43.0 libgsasl/1.10.0 Release-Date: 2021-05-26 Protocols:
dict file ftp ftps gopher gophers http https imap imaps ldap ldaps
mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl HSTS HTTP2 HTTPS-proxy IDN
IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP
Unicode UnixSockets zstd
This error happens when you are behind a 7 layer firewall (i.e Palo Alto) that Allow SSL connections only via application, so you have to configure 2 rules in such solution.
Allow 443 or whatever port with higher priority
Allow Application SSL with lower priority
Related
I am trying to connect to server B from server A using curl (https). I have already tried with -k and it doesn't work.
I have looked into several posts and I spotted blog on this link but still issue exists.
When I do a curl from server A, I am getting following error:
* Rebuilt URL to: https://x.x.x.x:8443/
* Hostname was NOT found in DNS cache
* Trying x.x.x.x...
* Connected to x.x.x.x (x.x.x.x) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: /tmp/cert_test/certRepo
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:**SSL routines:SSL23_GET_SERVER_HELLO:**unknown protocol
I went on the server B (https://x.x.x.x:8443/) from the browser and downloaded the root, intermediate and the client certificate. As suggested in the blog, I have created a new folder and combined all the public certs into one directory and tried to execute the curl command
curl -v --cacert /tmp/cert_test/certRepo https://x.x.x.x:8443
I am getting GET_SERVER_HELLO:unknown protocol
any thoughts?
Curl version from the Client machine:
curl 7.37.0 (x86_64-suse-linux-gnu)
libcurl/7.37.0 OpenSSL/0.9.8j
zlib/1.2.7
libidn/1.10
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet
tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz
I am very sure the server is using TLSv1.2.
you did not post your curl/libssl version, but my best guess is that you're using an ancient build of a ssl/tls library, and/or an ancient version of curl which does not support whatever version of ssl/tls that server us ysubg. update your libssl and curl and try again. also post the output of curl --version.
PS, if you're on linux, you can get rough curl+openssl compile instructions here.
I'm on Windows 10 Professional Plus
I have a CURL command in DOS that works fine for standard FTP on Port 21
Once I'm in the folder C:\Program Files\cURL\bin> I issue the command:
curl -v -T (C:\folders\file_to_be_transferred.pdf) ftp://(username):(password)#(host.top_level_domain.com)/file_to_be_transferred.pdf
I'm trying to transfer the file using FTP over TLS. When I change FTP to FTPS and change the command to:
curl -v -T (C:\folders\file_to_be_transferred.pdf) ftps://(username):(password)#(host.top_level_domain.com)/file_to_be_transferred.pdf
I get the following response from CURL:
* 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 999.999.999.999...
* Connected to host.top_level_domain.com (999.999.999.999) port 21 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files\cURL\bin\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
When I request the CURL version using CURL -V I get the following response:
curl 7.39.0 (x86_64-pc-win32) libcurl/7.39.0 OpenSSL/1.0.1g zlib/1.2.8 WinIDN libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile SSPI SPNEGO NTLM SSL libz
How do I enable TLS over FTP with CURL on Windows 10?
Thanks for looking at this.
I resolved the problem. It was how I referenced the certificates. Earlier I had transferred the certificate generated by the FileZilla Server (certificate.crt) to the Windows Client. I placed that certificate file in the folder C:\Program Files\cURL\bin. Also, I copied the contents of certificate.crt and appended it to the existing certificate called curl-ca-bundle.crt. Appending the new certificate to that bundle file is very important. That was my problem. Now, when I reference only the FileZilla_Server generated certificate in the client's CURL command, the transfer works. It seems that cURL will always reference the curl-ca-bundle.crt file in addition to what is referenced in the command line. The logs referenced the details of the SSLv3 handshake. Also I restructured the command a little bit to make it more readable. Here it is:
curl --user username:password --cert "C:\Program Files\cURL\bin\certificate.crt" -v -T C:\folder_and_file_to_be_transferred.pdf ftps://host.top_level_domain.com/filename.pdf
By the way, the default port for FTPS is 990. On the router I had to open up port 990 and the port range 20101-20120. I did NOT have to open up port 21 since I was using ftpS.
I hope this helps someone else.
I have run a curl query: curl https://login:password#mywebsite.com/script/
I have few curl executables, one installed with cygwin:
1:
curl 7.59.0 (x86_64-unknown-cygwin) libcurl/7.59.0 OpenSSL/1.0.2o zlib/1.2.11 libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 nghttp2/1.31.0
Release-Date: 2018-03-14
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 Debug IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL Metalink
other two that I compiled:
2 - libcurl-vc14-x86-release-static-ipv6-sspi-winssl :
curl 7.60.0 (i386-pc-win32) libcurl/7.60.0 OpenSSL/1.0.2k WinIDN
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL HTTPS-proxy
3 - libcurl-vc14-x86-release-static-ssl-static-ipv6-sspi:
curl 7.60.0 (i386-pc-win32) libcurl/7.60.0 WinSSL WinIDN
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
1 + 3 can do this 'TSL request', 2 returns error message:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
All the advices I found on this problem is - you have to get the cert file from the server and store it into local store (or tell to curl to ignore the error).
My question is - why is that a proposed answer, when 1 + 3 can do it without that? What is the difference? And what do have 1 + 3 in common that they can do what 2 can't?
Because...
cygwin probably has a CA store locally already as part of its main install. It is used by more tools than just curl.
curl built with the "WinSSL" backend automatically uses the CA store that your windows installation has bundled with the operating system.
Your custom build using OpenSSL needs a CA store to verify the remote server's certificate against...
I have been using a curl command to get data from squareup.com:
curl -s -H "authorization: Bearer "xyz" https://connect.squareup.com/v1/me
This had been working correctly until last week, when it started to fail.
In working with my hosting company, it turns out they made a server change and had SSL proxy enabled on the server. Now when it runs I get the following error:
== Info: SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
== Info: Closing connection 0.
My curl is
$ curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP
Any idea how I can get curl to work with SSL proxy enabled on the server?
I have a server running Rundeck to handle a large amount of various integration tasks.
The scheduled tasks each make a curl request to a given URL on our intranet system - essentially Rundeck just runs a temporary bash script.
About 99% of the time, this works fine - but we're seeing curl fail intermittently with Error 35: Unknown SSL protocol error in connection.
I've tried specifying the ssl protocol explicitly, with a known-good protocol, but we're still experiencing the issue.
We have a pretty high volume of requests going out - I'm not sure if that could have something to do with it. There is a chance we could have ~3 curl processes running at any given time.
Any advice would be appreciated.
curl --version
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
I've figured this out myself.
I ended up using wireshark to watch the communication on the server side of the SSL connection. The only anomaly I could see in the trace of the failures was that our Diffie-Hellman Public Key was 127 bytes, when typically it would be 128.
It looks like IIS didn't know how to handle this, and terminated the communication.
I'm not 100% clear on what the root cause of the issue was, but forcing a non-DH TLS cipher suite completely stopped the error messages.
Check This Article On Security.StackExchange For More Information