Project

General

Profile

wthttp, Self-signed certificates, localhost, OpenSSL and handshake error...

Added by Plug Gulp almost 5 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 5 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 . over 4 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 . over 4 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.

    (1-3/3)