How to use the self-signed certificate for client SSL connections?

cwt237

I have been trying to use the already provided self-signed certificate for setting up SSL, using the .NET client, but without luck.

I have configured the use of https_server in lightstreamer.conf file, but both the browser and the .NET client is reporting that it does not trust the certificate (which is not that odd, since it is self-signed).

Installing the certificate in the trusted root CA certificate store, makes the browser ignore this (while setting up push.mycompany.com in the host file). However, that still does not work in the .NET client, and is definitely not the way to go.

I have been trying to bypass this on the server using the truststore element in the config file:

<truststore>
<truststore_file>myserver.keystore</truststore_file>
<truststore_password>mypassword</truststore_password>
</truststore>

However, that requires that either <force_client_auth> or <use_client_auth> is enabled. I have tried that, but it does not seem to work.

Is there a quick way to get SSL working with a self-signed certificate running the .NET client?

cwt237

BTW: Setting force_client_auto to Y and using the local keystore as trusted outputs the following in the log:

24-Sep-13 09:20:50,298|ERROR|ghtstreamerLogger.connections.ssl|LS/SSL AUTH POOLED THREAD 5|Handshake error on Lightstreamer HTTPS Server: null cert chain on 127.0.0.1:61725.

cwt237

A work around for this is to disable the certificate validation in the code executing the call to the server (e.g. through the .NET client), by using:

ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, errors) => true;

This must be done before making the connection, e.g. in static void main().

Dario Crivelli

Actually, we don't cover this topic in our documentation because we consider it external to Lightstreamer, since declaring a certificate as a trusted one for the .NET runtime should occur at a lower level than our client library.
I hope you are happy with the alternative technique you have found.

I confirm that the <force_client_auth> / <use_client_auth> / <truststore> settings on the Server are not related with your problem, but with the opposite, unusual one of having the Server identify the client.
This operation requires that the .NET client has the certificate installed in its own keystore; if the identification fails in your test, it may be that this installation was not successful.

cwt237

The work around is fine, since I only wanted to test the performance and throughput degradation when using SSL - and this is possible with the mentioned fix/hack.

That code should never make it out of the sandbox though :Smile_Ad: