Client Server TLS won't work

We had this problem show up in 2019 when a customer had a Windows Server 2019 setup.

Now, it is hitting our own network, and two more customers’ networks.

When trying to connect, we get this error:

Failed to synchronize WIN4DX folder.
(There is no Win4DX folder anywhere to be found on our server).

Error code: -10517 (4DRT)
Failed to synchronize WIN4DX folder.
component: ‘4DRT’
task -1, name: ‘Application process’

Error code: 43 (srvr)
SSL write failed
component: ‘srvr’
task -1, name: ‘Application process’

Error code: 49 (srvr)
SSL internal error : error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
component: ‘srvr’
task -1, name: ‘Application process’

This is a CURL error - you can google it:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

4D v17.3 hf3, built C/S OEM application
Windows Server 2019, 2016, 2012 R2
Windows 10

Server app is running as Administrator
No firewall
19812, 19183, 19814 ports are open
The problem does NOT happen with our app running interpreted C/S

Does anyone know what might cause this error?
I have a tech support case but no answer so far.


My first guess is that you are running on a SERVER CORE version of WS2019.

It does not support 4D Server/4D Remote.


Thanks and good to know, but this is happening on Windows Server 2016 Standard, Windows Server 2012 R2, and even Windows Server 2008 R2.

In about instances, encrypted connections have been working for 6-12 months.

And, when we turn off encryption, it does work. (That’s our workaround).



Does the client connexion works when you run the client from the machine (using localhost/ ?

Do you have some sort of firewall between the client and the server which could do some TLS inspection ?

please contact your local tech support / open a TAOW case.

I never heard of that, so I cannot provide a solution.
I would have expected an issue with WIN4DX folder (as I don’t assume anybody tested this folder anymore) but you write it also happens without.

Next job I expect from your local tech support team is to request Diagnostic Log (best from Server and client) and Network Request log. This will provide information what was transferred so far and where it breaks.

None of actual IP address, localhost and work encrypted with the client on the local machine.
The firewall is off on the local machine. I don’t know if our network firewall would be involved.
However, unencrypted works with the built app, and encrypted works connecting with our development server over the local network.

We have been working with tech support. They took our code and built the app themselves - that didn’t work encrypted.
We also turned on Diagnostic log recording, Server log recording and 4D Info Report on the server, and sent in the logs with encryption on, and encryption off.

We’re working on getting the logs going client side.

The problem turned out to be this, On Server Startup, for the web server.

<code 4D>

SET DATABASE PARAMETER(SSL cipher list;$cipherList_t)

</code 4D>

Not sure what’s wrong with the cipher list, but when we let it go back to the default TLS 1.2 for the C/S connection works.

(The docs say that the cipher list applies to all connections in 4D)

  • HTTP server
  • SQL server
  • client/server
  • etc.

Hi Jim,

Thanks for sharing this information with us.


Note to myself : cipherlist should not be hardcoded, but changeable via some sort of parameter in our code.
We should not have to recompile to change/adjust this.


Another thing I noticed on recent version…
4D creates a “dhparams.pem” file when it needs to use DH algorithm. Did you see that file on your server ?

I see the dhparams.pem file on our development server, next to the .4DB file, along with the default cert.pem and key.pem.

On a built server, the cert.pem and key.pem show up inside the [MyServer]\Resources folder.
There is no dhparams.pem file on the built server we are running in house right now - but we are using the default cipher list.

I think I have seen that file on a built installation though. I think our Uninstaller left it behind - which means the server created it after the install.

Unless we find that our upcoming PEN tests show a problem, I’ll wait until the Chicago Summit to learn more about this.


For information dhparameters.pem is only and only used to enable “Perfect Forward Secrecy” on HTTP Server… Never for Client/Server encryption.