wthttp, Self-signed certificates, localhost, OpenSSL and handshake error...
Added by Plug Gulp almost 6 years ago
Hi,
I am trying to use self-signed certificates created using OpenSSL with whttp. I followed the instruction provided here: https://redmine.webtoolkit.eu/projects/wt/wiki/Frequently_Asked_Questions#Q-How-do-I-use-the-built-in-HTTPS-server-in-wthttpd
But I get "wthttp/async: SSL handshake error: no shared cipher" error on the server-side. Similar issues were raised earlier by others on this forum:
https://redmine.webtoolkit.eu/boards/2/topics/15528 and https://redmine.webtoolkit.eu/boards/2/topics/14063
I tried removing the ---ssl-cipherlist option from the wthttp commandline but there is no change. I also tried specifying the same cipher list to wthttp that OpenSSL retuns for the 'openssl ciphers' command. Still no difference. Then I tried running the OpenSSL test client s_client against wthttp server using the following command:
openssl s_client -servername localhost -connect localhost:8080
I get the following error:
CONNECTED(00000003)
140627969496728:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 323 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1560712136
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
And I get the same earlier error on the server-side:
"wthttp/async: SSL handshake error: no shared cipher"
I tried specifying the same cipher list both for the wthttp server and the s_client, but there is no change in the error.
On one of the forums it was mentioned that the line SSL handshake has read 0 bytes and written 323 bytes
in the error returned by the s_client suggests that even the handshake did not happen between the client and the server and no data was returned from the server, the server just reset the connection.
I checked that the SSL libraires linked with Wt and my test application are the same. They are:
For Wt HTTP server:
libcrypto.so.1.0.0
libssl.so.1.0.0
And for the Wt application:
libcrypto.so.1.0.0
libk5crypto.so.3
libhcrypto.so.4
libcrypt.so.1
libssl.so.1.0.0
I am on Ubuntu 16.04, using the system provided OpenSSL(version 1.0.2g) and using latest stable Wt 4.0.5.
Has anyone managed to use self-signed certificate with wthttp on localhost and also tested the 'handshake issue' using s_client?
Thanks and kind regards,
~Plug
Replies (3)
RE: wthttp, Self-signed certificates, localhost, OpenSSL and handshake error... - Added by Plug Gulp almost 6 years ago
I have old Wt code(ver 3.5.5). The certificates work without problem with older wthttp. It is the newer version(4.0.5) that is giving the error. Comparing SslConnection.C file under wt/src/http for both versions does show some changes made to wthttp related to boost::asio version. Could that be the cause of the issue?
Thanks and regards,
~Plug
RE: wthttp, Self-signed certificates, localhost, OpenSSL and handshake error... - Added by Ray . almost 6 years ago
I would like to add my 'support' for the question. I have carried out similar troubleshooting steps, and have the same result: 'no shared cipher'.
This is with the latest git (2019/08/03) aka wt 4.1.0.
Libraries linked are libssl.so.1.1 and libcrypto.so.1.1 when viewed from lsof. Package is 1.1.1c-1 of openssl. Boost 1.69.
This on Debian Buster.
RE: wthttp, Self-signed certificates, localhost, OpenSSL and handshake error... - Added by Ray . almost 6 years ago
I think I have narrowed this down to line 207 in src/http/Server.C:
if (!config_.httpsAddress().empty() && config_.parentPort() == -1) {
This forces the use of:
--https-address
--https-port
rather than the newer
--https-listen
After changing the command line arguments to match, the 'no shared cipher' message goes away and successful ssl connections are made.