Wt

I also installed wt with following this [1] for "mac OS X Yosemite or El Capitan (macosx 10.10-10.11+)", but i am on macOS Mojave 10.14.1, would that cause any issue? mojave is fairly new and the wiki is a bit over a year old.

1. 1 https://redmine.webtoolkit.eu/projects/wt/wiki/Installing_Wt_on_Mac_OS_X_Yosemite

I use a reverse proxy (Apache httpd) and terminate the SSL there. Are you planning on serving your website permanently behind Apple Macintosh OS?

Nope, i was planning on deploying on Linux. i was hoping to avoid using a reverse proxy if possible though - otherwise ill probably just throw nginx in-front of it :).

Hey Matt,

You'd have to check if your server actually offers to connect with cyphers that are acceptable to your browser. There apparently are tools to list the cyphers actually supported by the server:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html

Possibly the ssl-cypherlist suggestion from our FAQ is outdated, or you want to be less strict than the list. You can try to omit the parameter and use the default cypherlist built-in in openssl. Possibly there is something wrong with the openssl library.

Wim.

I tried that nmap script but that returned no ciphers. i suspect it has something to do with openssl.

ill keep trying things in the future and keep this post updated.

Thanks!

So upon building wt from source on linux i found that it looks for crypt when building the httpd, but not on macos, eg

Linux build:

...
** Enabling built-in httpd.
-- Looking for strcasestr
-- Looking for strcasestr - found
-- Looking for strcasecmp
-- Looking for strcasecmp - found
-- Looking for crypt
-- Looking for crypt - not found
-- Looking for crypt in crypt
-- Looking for crypt in crypt - found
...

MacOS:

...
** Enabling built-in httpd.
...

Funnily enough, i still get the same no shared cipher error on linux lol.

• That crypt finding on macos was actually because i passed cmake the -DSSL_PREFIX prefix, nothing to do with the problem

crypt is only used for some examples to add another hash function to Wt::Auth. It's not an integral part of Wt.

I made a little progress, i had to tell cmake to look in the homebrew openssl at /usr/local/opt/openssl/ rather than the default macOS openssl which is /usr/bin/openssl

However, now when i try to access the page my browser tries to establish a secure connection but times out, and i get no error from wt. Any suggestions?

Hey Matt,

Possibly something went wrong with your openssl build, so that it does not support any ciphers. What does 'openssl ciphers' tell you? And then check that your openssl binary is linked against the same openssl library as the one Wt is linked to.

I think this is an openssl issue rather than a Wt issue.

Best regards,

Wim.

Were the issues ever resolved? I am building with a similar fashion, but on Debian Buster, with wt 4.1.0, boost 1.69, and openssl 1.1.1. I too see 'no shared cipher'.

'openssl ciphers' shows a long list of ciphers and used that string as input to the command line cipher list.

'openssl s_client -connect :443 -showcerts -servername ' provides a result of 'SSL handshake has read 0 bytes and written 299 bytes'

If this is an openssl issue, any suggestions on how to debug or trace this?

I have used a self-signed certificate and a letsencrypt certificate. Identical 'no shared cipher' results.

Hi Wim Dumon

I see this style of issue in a number of different forum posts. What sort of platform do you build and test? Are you unable to re-create the problem?

Raymond.

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.