Bitshares-core: cli_wallet -s wss://{ANY VALID AUTHORITY}/ws fails with 'TLS handshake failed'

[testlump]

Updated by @abitmore for the readers' convenience:

For Windows, the issue has been fixed in BitShares Core 4.0.0 release via https://github.com/bitshares/bitshares-fc/pull/159, cli_wallet will check the default CAs installed in the OS.

For Ubuntu / Debian, if you encountered this issue, try install ca-certificates (see https://github.com/bitshares/bitshares-core/issues/314#issuecomment-379853099).

sudo apt-get install -y ca-certificates

--- The original message is below ---

The cli_wallet.exe binary part of build BitShares Core Release 2.0.170606 Windows binaries package, fails with TLS handshake failed message when attempting to connect to any wss server.

Attempts have been made against a number of the wss:// uri's listed in the lightweight client as well as the wss:// uri documented in the tutorial: wss://bitshares.openledger.info/ws

The full output from the cli_wallet.exe is posted below (note; the executable has been run in an Administrative level command prompt).

C:\Temp\bitshares-cli>cli_wallet -s wss://bitshares.openledger.info/ws
Logging RPC to file: logs\rpc\rpc.log
1626215ms th_a main.cpp:120 main ] key_to_wif( committee_private_key ): 5KCBDTcyDqzsqehcb52tW5nU6pXife6V2rX9Yf7c3saYSzbDZ5W
1626215ms th_a main.cpp:124 main ] nathan_pub_key: BTS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
1626215ms th_a main.cpp:125 main ] key_to_wif( nathan_private_key ): 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
Starting a new wallet with chain ID 4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8 (from egenesis)
1626231ms th_a main.cpp:172 main ] wdata.ws_server: wss://bitshares.openledger.info/ws
0 exception: unspecified
TLS handshake failed
{"message":"TLS handshake failed"}
asio websocket.cpp:518 fc::http::detail::websocket_tls_client_impl::{ctor}::<lambda_79cc34a518286825a5be07605053c212>::operator ()

{"uri":"wss://bitshares.openledger.info/ws"}
th_a websocket.cpp:704 fc::http::websocket_client::secure_connect

{"uri":"wss://bitshares.openledger.info/ws"}
th_a websocket.cpp:678 fc::http::websocket_client::connect

C:\Temp\bitshares-cli>

Second issue; in addition, the output (above) indicates that a logs\rpc\rpc.log file is created but this file/folder does not exist relative to the the directory from which cli_wallet.exe is executed. A search across the entire file-system of the server which the cli_wallet.exe is being executed on does not locate an rpc.log file anywhere.

Please check that the rpc.log file indicated in the output is being generated and if it is, provide the fully qualified path in which it is located.

[gstempeck]

Anyone looking into this? It's been 3 months and this seems like a critical issue for anyone attempting to use the API according to your instructions on the "How to prepare CLI wallet for trading" located here:
http://docs.bitshares.org/integration/tutorials/preparing-cli-wallet-trading.html

[xeroc]

Can you please try

wss://node.bitshares.eu

[oxarbitrage]

is the same thing @xeroc . problem is with the windows cli wallets downloaded from https://github.com/bitshares/bitshares-core/releases, this zip file: https://github.com/bitshares/bitshares-core/releases/download/2.0.170606/BitShares-Core-2.0.170606-x64-cli-tools.zip

the cli_wallet binary connecting to servers without ssl works fine and ssl also works fine in linux so this is something related to windows build. probably @abit will be the right person to get a better answer to this.

[webivation]

Also constantly experiencing this.. have there been any updates?

[abitmore]

The reason is cli_wallet tried to verify the server's certificate with OpenSSL but failed, because I didn't include a default list of trusted root certificates into the binary.

Workaround:

• create your own PEM bundle which contains required root / intermediate certificates, or get one from somewhere (at your own risk), for example, download the the Mozilla CA certificate store in PEM format from https://curl.haxx.se/docs/caextract.html, save it as d:\cacert.pem.
• in Windows command prompt (cmd.exe),
  
  
  
  • run set SSL_CERT_FILE=d:/cacert.pem
  
  
  • then run cli_wallet -s wss://{ANY VALID AUTHORITY}/ws, for example, cli_wallet -s wss://bitshares.openledger.info/ws
  
  

//Update: in Ubuntu, there is a default bundle file which openssl can find and use, so didn't have this issue.

[testlump]

I can report that the workaround provided by @abitmore does indeed work and the cli_wallet is now working correctly. Fantastic stuff.

What's the likelihood of getting this list certificate integrated into future builds of the Windows cli_wallet so that the issue can be fully resolved?

[webivation]

Got all the way in... just can't get create_order to work. :-/

[abitmore]

@webivation your issue is off topic here, it's related to STEEM but not BitShares.

[ety001]

If in a ubuntu docker container , need install ca-certificates first.

apt-get install -y ca-certificates

[oxarbitrage]

not fixed with https://github.com/bitshares/bitshares-core/pull/839 ? reason of the reopening ?

[abitmore]

839 is for docker, but this issue is about windows binaries.

[oxarbitrage]

sorry, got confused with the name of the pull. got it now, thanks.

[pmconrad]

@jmjatlanta is this still a problem with the latest windows builds? If not please close.

[jmjatlanta]

Certificates are not included in the binary. I do not believe they should be. Having the user define their certificates increases flexibility and decreases liability IMO.

Documentation may be a better solution (if it is not already documented).

I am open to hear other's comments. If none arrive, this ticket should be closed.

[isamuelson]

is there a way to set the cert on debian/ubuntu?

[abitmore]

@isamuelson

apt-get install -y ca-certificates

[isamuelson]

its already installed...

i'm running under k8s

trying now this legacy fix from https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/tls.md

kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-config
data:
ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"
ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2"

[isamuelson]

yes, this fixed my issue.

[pmconrad]

No other comments arrived. Closing as per @jmjatlanta 's suggestion.

[pmconrad]

Re-opening for proper fix.

[abitmore]

Will close when bumped FC. The fix is https://github.com/bitshares/bitshares-fc/pull/159.

[pmconrad]

Bumped in #1992

[xloem]

Hey, I was on a flaky system and commented here then deleted, sorry. I updated to latest master.
The issue is still present on Ubuntu 20 for me, and I haven't found a fix, including exporting SSL_CERT_FILE, which isn't working for me. One idea is a workaround providing for pinning the specific cert needed.

bin/Ubuntu-focal-x86_64-4.0.0-18-gf149b269$ wget https://curl.haxx.se/ca/cacert.pem
--2020-07-23 18:13:26--  https://curl.haxx.se/ca/cacert.pem
Resolving curl.haxx.se (curl.haxx.se)... 151.101.250.49, 2a04:4e42:50::561
Connecting to curl.haxx.se (curl.haxx.se)|151.101.250.49|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 222172 (217K) [application/x-pem-file]
Saving to: ‘cacert.pem’

cacert.pem                    100%[================================================>] 216.96K   906KB/s    in 0.2s    

2020-07-23 18:13:27 (906 KB/s) - ‘cacert.pem’ saved [222172/222172]

bin/Ubuntu-focal-x86_64-4.0.0-18-gf149b269$ export SSL_CERT_FILE="$(pwd)"/cacert.pem
bin/Ubuntu-focal-x86_64-4.0.0-18-gf149b269$ ./cli_wallet -s wss://node.bitshares.eu
Starting a new wallet with chain ID 4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8 (from egenesis)
870865ms th_a       main.cpp:231                  main                 ] wdata.ws_server: wss://node.bitshares.eu 
0 exception: unspecified
TLS handshake failed
    {"message":"TLS handshake failed"}
    fc::asio worker #0  websocket.cpp:498 operator()

    {"uri":"wss://node.bitshares.eu"}
    th_a  websocket.cpp:724 secure_connect

    {"uri":"wss://node.bitshares.eu"}
    th_a  websocket.cpp:698 connect

[abitmore]

For Ubuntu / Debian, install ca-certificates. See https://github.com/bitshares/bitshares-core/issues/314#issuecomment-379853099.

sudo apt-get install -y ca-certificates

[xloem]

@abitmore I have that installed already

$ dpkg-query --show ca-certificates
ca-certificates 20190110ubuntu1.1

It's notable that ca-certificates maintains the file /etc/ssl/certs/ca-certificates.crt whereas cli_wallet is checking /usr/lib/ssl/cert.pem; but stills fails to connect even when I provide that file:

$ strace bin/Ubuntu-focal-x86_64-4.0.0-18-gf149b269/cli_wallet -s wss://node.bitshares.eu
# ... snip ...
openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=222172, ...}) = 0
read(6, "##\n## Bundle of CA Root Certific"..., 4096) = 4096
read(6, "GxpYWIuKTEl\nMCMGA1UECxMcKGMpIDE5"..., 4096) = 4096
# ... snip ...
write(2, "0 exception: unspecified\nTLS han"..., 2940 exception: unspecified
TLS handshake failed
    {"message":"TLS handshake failed"}
    fc::asio worker #0  websocket.cpp:498 operator()

    {"uri":"wss://node.bitshares.eu"}
    th_a  websocket.cpp:724 secure_connect

    {"uri":"wss://node.bitshares.eu"}
    th_a  websocket.cpp:698 connect) = 294
# ...

I tried updating to the latest HEAD of libraries/fc, which required providing some extra default parameters to constructor calls in bitshares-core, and I'm getting a timeout error now instead of the handshake failure.

EDIT: I'm no longer using this system. This issue could have been a quirk of my setup, although it was a very new install.

[abitmore]

I tried updating to the latest HEAD of libraries/fc ...

Just FYI, latest FC is included in develop branch of bitshares-core.

It's notable that ca-certificates maintains the file /etc/ssl/certs/ca-certificates.crt whereas cli_wallet is checking /usr/lib/ssl/cert.pem; but stills fails to connect even when I provide that file

I don't know why your cli_wallet checks /usr/lib/ssl/cert.pem. On my Ubuntu 18 and 16 machines the /usr/lib/ssl/cert.pem file doesn't exist but the cli_wallet downloaded from the 4.0.0 release page works fine. I guess it's related to your environment since you're running modified code. Linking cert.pem to ca-certificates.crt would probably work for you (see this link).

sudo ln -s /etc/ssl/certs/ca-certificates.crt /usr/lib/ssl/cert.pem

[abitmore]

Just noticed that in my environment cli_wallet checks /usr/lib/ssl/cert.pem too, but it still works although the file doesn't exist. I don't have a Ubuntu 20 environment right now, will check later. The code currently doesn't support Ubuntu 20 anyway.

Update: can not reproduce the issue on my new computer running Ubuntu 20.04.