I am trying to wget a file from a https server using the command wget -d --no-check-certificate https://abcde.com/test.tar.gz
This is the log i obtained
Setting --check-certificate (checkcertificate) to 0
DEBUG output created by Wget 1.17.1 on linux-gnu.
Reading HSTS entries from /root/.wget-hsts
URI encoding = ‘UTF-8’
URI encoding = ‘UTF-8’
--2018-08-20 19:02:44-- https://abcde.com/test.tar.gz
Resolving proxy.png.mycompany.com (proxy.png.mycompany.com)... 172.xx.x.17x
Caching proxy.png.mycompany.com => 172.xx.x.17x
Connecting to proxy.png.mycompany.com (proxy.png.mycompany.com)|172.xx.x.17x|:911... connected.
Created socket 3.
Releasing 0x0000560ce6ef84f0 (new refcount 1).
---request begin---
CONNECT abcde.com:443 HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Host: abcde.com:443
---request end---
proxy responded with: [HTTP/1.1 200 Connection established
]
Initiating SSL handshake.
SSL handshake failed.
Closed fd 3
Unable to establish SSL connection.
Saving HSTS entries to /root/.wget-hsts
Related
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
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.
When I am opening a url using curl without -k, my request is passing and I am able to see the expected result.
$ curl -vvv https://MYHOSTNAME/wex/archive.info -A SUKU$RANDOM
* Trying 10.38.202.192...
* Connected to MYHOSTNAME (10.38.202.192) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: *.MYCNAME
* Server certificate: ProdIssuedCA1
* Server certificate: InternalRootCA
> GET /wex/archive.info HTTP/1.1
> Host: MYHOSTNAME
> User-Agent: SUKU19816
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.2
< Date: Thu, 26 Jan 2017 01:08:40 GMT
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 19
< Connection: keep-alive
< Set-Cookie: JSESSIONID=1XXXXXXXX3E58093E816FE62D81; Path=/wex/; HttpOnly
< X-WebProxy-Id: 220ffb81872a
<
status=Running
* Connection #0 to host MYHOSTNAME left intact
But when I am opening same url with -k its failing. To me its not making any sense since in my understanding the purpose of -k is only to skip certificate verification
$ curl -vvv https://MYHOSTNAME/wex/archive.info -A SUKU$RANDOM -k
* Trying 10.38.202.192...
* Connected to MYHOSTNAME (10.38.202.192) port 443 (#0)
* Server aborted the SSL handshake
* Closing connection 0
curl: (35) Server aborted the SSL handshake
Request flow:
SSL termination is happening on HAPROXY machine
HAPROXY will forward request to nginx
For troubleshooting this kind of problem, the --resolve option can be useful:
curl -k -I --resolve www.example.com:80:192.0.2.1 https://www.example.com/
Provide a custom address for a specific host and port pair. Using
this, you can make the curl requests(s) use a specified address and
prevent the otherwise normally resolved address to be used. Consider
it a sort of /etc/hosts alternative provided on the command line. The
port number should be the number used for the specific protocol the
host will be used for. It means you need several entries if you want
to provide address for the same host but different ports.
Especially if the site you’re trying to fetch from uses SNI: In that case you can use the --resolve option to specify the server name that gets used in the TLS client hello.
One troubleshooting step to try: update curl or compile it yourself from the sources and retry. For one thing, some curl versions (e.g., MacOS) supposedly don’t send SNI for -k/--insecure.
If that’s the issue you’ve hit and you can’t replace curl, there’s a workaround you can use that essentially involves creating your own CA and private keys and CSRs, and tweaks to your haproxy.
After setting it up, then in place of specifying -k/--insecure, you use --cacert or --capath:
curl https://example.com/api/endpoint --cacert certs/servers/example.com/chain.pem
curl https://example.com/api/endpoint --capath certs/ca
If the issue you’ve hit is due to SNI, you may also troubleshoot it with a site like https://sni.velox.ch/:
curl --insecure https://sni.velox.ch/
Otherwise, if it’s not SNI, then I recall seeing somewhere that -k/--insecure may not work as expected with some proxy configurations. So if you are going through some kind of proxy from the client side and you could somehow test directly without the proxy, that might be worth exploring.
I have an API server (Debian Apache2) with OpenSSL installed and working. I also have a staging and production web server (also Debian Apache2, exactly the same spec - they are VM clones). All servers are on the same subnet. I can browse to the wsdl from my local machine on 443 successfully, and I can wget the wsdl successfully from my staging server on 443, but a wget from my production web server will not connect:
--2015-04-16 10:26:18-- https://www.example.com/index.php/api?wsdl
Resolving https://www.example.com (https://www.example.com)... XX.XX.XX.XX
Connecting to https://www.example.com (https://www.example.com)|XX.XX.XX.XX|:443... failed: Connection refused.
I can connect over https from a PHP nusoap client on staging no problem, but the same code on my production server returns:
wsdl error: HTTP ERROR: cURL ERROR: 7: couldn't connect to host
url: https://www.example.com/index.php/api?wsdl
content_type:
http_code: 0
header_size: 0
request_size: 0
filetime: -1
ssl_verify_result: 0
redirect_count: 0
total_time: 5.272228
namelookup_time: 5.271805
connect_time: 0
pretransfer_time: 0
size_upload: 0
size_download: 0
speed_download: 0
speed_upload: 0
download_content_length: -1
upload_content_length: -1
starttransfer_time: 0
redirect_time: 0
certinfo: Array
primary_ip: XX.XX.XX.XX
primary_port: 443
local_ip:
local_port: 0
redirect_url:
An openssl s_client -connect from both web servers produces the same output.
After my production server returns connection refused, there are no new entries in the API server's error.log, therefore this must be a client issue.
Is there a Debian-specific/internal firewall config I may have inadvertently changed that would prevent the one client from connecting to a secure web server over HTTPS and not another?
"Connection refused" usually indicates a failure to complete the initial TCP connection. Things to check include:
iptables, firewalls, hosts.deny
is apache listening on the interface/ip address the is attempting to connect to?
Does wget or curl work from the local server when you use http://127.0.0.1/ but not http://THE-SERVER'S-PUBLIC-IP-ADDRESS/ ?
What do you see when you run wget with --debug and --verbose ?
When I try to connect to my server remotely I get the following error.
$ curl -k --verbose https://myserver.com:9010/test
* Adding handle: conn: 0x7f8bfb801a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f8bfb801a00) send_pipe: 1, recv_pipe: 0
* About to connect() to myserver.com port 9010 (#0)
* Trying <myserver ip>...
* Connected to myserver.com (myserver ip) port 9010 (#0)
* Server aborted the SSL handshake
* Closing connection 0
curl: (35) Server aborted the SSL handshake
However, if I run this very command from within the server where the service is running then the connection completes successfully.
I am using a self-signed certificate. I used the guide at codeproject.com to create my certificate. And my Dropwizard server config is:-
server:
requestLog:
timeZone: UTC
appenders:
- type: file
currentLogFilename: logs/requests.log
archivedLogFilenamePattern: logs/requests-%d.log
archivedFileCount: 3
threshold: ALL
applicationConnectors:
- type: https
port: 9010
keyStorePath: myserver.keystore
keyStorePassword: password
certAlias: myserverAlias
validateCerts: false
trustStorePath: /etc/pki/java/cacerts
adminConnectors:
- type: https
port: 9011
keyStorePath: myserver.keystore
keyStorePassword: password
certAlias: myserverAlias
validateCerts: false
trustStorePath: /etc/pki/java/cacerts
Also I see no error in the logs.
Additional details
The successful connection from within the server looks like this.
$ curl -k --verbose https://myserver.com:9010/test
* Trying <myserver ip>...
* Connected to myserver.com (myserver ip) port 9010 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* Server certificate:
* subject: CN=myserver.com,OU=TECH,O=AppleGrew,L=HYD,ST=TS,C=IN
* start date: Apr 05 06:16:32 2015 GMT
* expire date: Apr 04 06:16:32 2018 GMT
* common name: myserver.com
* issuer: CN=myserver.com,OU=TECH,O=AppleGrew,L=HYD,ST=TS,C=IN
> GET /test HTTP/1.1
> User-Agent: curl/7.40.0
> Host: myserver.com:9010
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 06 Apr 2015 06:01:23 GMT
< Content-Type: application/json
< Vary: Accept-Encoding
< Content-Length: 99
<
* Connection #0 to host myserver.com left intact
{"status":"OK","message_type":"INFO","message_recipient":"SYSTEM","testMsg":"The service is live!"}
However, the version of curl running server-side and remote client-side are different.
Server-side it is:
curl 7.40.0 (x86_64-redhat-linux-gnu) libcurl/7.40.0 NSS/3.16.2 Basic ECC zlib/1.2.8 libidn/1.18 libssh2/1.4.2
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
Client-side it is:
curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
Update
I was able to connect to the server from a remote Linux system. The curl version on that system is:-
curl 7.19.7 (i686-pc-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Just a guess because your question lacks the necessary details:
you have a different version of curl on your client and on the server
your server setup triggers any of the differences between your curl versions, like:
support for RC4 disabled in newer versions
support for SSL 3.0 disabled in newer versions
no ciphers overlap
...
To get more help you should provide the versions and SSL stacks of curl you are using (curl -V), server side settings and maybe debug output (curl -v) for successful and unsuccessful connections.
Server aborted the SSL handshake
Because of this you should also have a look at the logs on the server side. It might even be that a firewall is blocking the connections, so you might check if the server gets he connection at all.