No, the -Djavax.net.debug=ssl:handshake:verbose options must be added to the JAVA_OPTS parameter.
Referring to the factory LS.bat of version 5 just append to the line
set JAVA_OPTS=-server
that will become
set JAVA_OPTS=-server -Djavax.net.debug=ssl:handshake:verbose
I'm sorry I didn't provide more detailed instructions in previous posts.
The ssl debug output does not report any handshake operation, but only the initialization phase where the root certificates are loaded and the cipher suites set.
Could you collect the log only after having performed a connection test with the client?
Furthermore, please could you comment out this configuration in the lightstreamer_conf.xml file:
From the log it seems that among all the cipher suites available on the server side there is none supported also by the client.
So it is no Lightstreamer configuration that precludes the success of the handshake operation.
Maybe your java 8 installation has a problem, please could you upgrade to the latest Java 8 build number.
Unfortunately the result has not changed, but actually the log shows differences from the previous test which seem to indicate the problem in the certificate.
Indeed, the error is due to the authentication scheme that should depend on the type of algorithm used for the generation of the certificate key.
Can you recover the type of algorithm used in that phase?
Yes, if you started the process of generation of the certificate from the key pair creation, the algorithm is specified in the keytool command; referring to the instructions from our documentation (https://lightstreamer.com/docs/ls-se...rtificates.pdf):
But if you have converted an already existing certificate, obviously the algorithm is derived from the existing cert.
Please also remember to test your server url with ssllabs, as already suggested in my previous post, so you can get detailed information about your certificate.
Bookmarks