Hallo,
I wanted to report a strange issue faced installing mendelson_opensource_as2_1.1b57 on CENTOS 8.
I first installed openjdk 11 via yum command. This resulted in the installation of openjdk version "11.0.8 2020-07-14 LTS".
After that, the setup of Mendelson goes fine, but the client GUI does not start. A window appears saying "Connecting to localhost/127...." and stays like that forever.
I can telnet to port 1235 locally and from remote without issues, but the JAVA client seems unable to connect.
I therefore installed an earlier version of openjdk ("11.0.1" 2018-10-16) and with that I could launch mendelson without issues.
I don't know if someone has a better idea of what could be the cause, but hopefully this workaround can help other people for now.
Comments
fromano, the client-server…
Submitted by service on Tue, 10/20/2020 - 11:44
fromano,
the client-server connection of the mendelson_opensource_as2_1.1b57 tries to perform a TLSv1 handshake. This is no longer permitted under CentOS. We changed the handshake to TLSv1.2 in the commercial version already. Perhaps there is a setting in CentOS to allow TLSv1?
Regards
Thank you for the reply,…
Submitted by fromano on Wed, 10/21/2020 - 12:40
Thank you for the reply, however the issue does not seem to be related to CENTOS in particular, but with its (current) default java 11 version.
When I switched from using openJDK version "11.0.8 2020-07-14 LTS" to openJDK version "11.0.1 2018-10-16", the Mendelson client started working.
To make it work I only changed the path of the java command in the .sh file to point to the older version, so everything else was exactly the same.
I also checked that both Java versions had jce unlimited strength enabled (in any case I think with latest versions of Java that comes by default)
fromano, please have a look…
Submitted by service on Fri, 10/23/2020 - 08:52
fromano,
please have a look at
{JRE_HOME}/lib/security/java.security
You should always find the line
jdk.tls.disabledAlgorithms=SSLv3
..but is there also an entry like
jdk.tls.disabledAlgorithms=TLSv1
?
Regards
Hi, There is no such file in…
Submitted by fromano on Mon, 10/26/2020 - 21:29
In reply to fromano, please have a look… by service
Hi,
There is no such file in either of the JDKs I installed (both the one working and the one not working):
That file seems located in {JRE_HOME}/conf/security
If I grep for "jdk.tls.disabledAlgorithm", I obtain the following, which seems the same for both versions:
CLIENT-LOGOFF EVENT What I…
Submitted by fromano on Mon, 10/26/2020 - 21:58
In reply to fromano, please have a look… by service
CLIENT-LOGOFF EVENT
What I just noticed is that with the 'wrong' java version, the following event is recorded:
whereas with the 'correct' java version, I get this:
These are the 2 sessions …
Submitted by fromano on Mon, 10/26/2020 - 22:47
These are the 2 sessions (good and bad) taken from wireshark. It seems in the bad one the client does not get to send a "Client Hello".
Hope it helps. For me in any case it is working with the old java version, But if you want more info for your own use, I'll be glad to help.
On a Ubuntu 20.04.5 LTS…
Submitted by alexander.remesch on Thu, 12/22/2022 - 12:26
On a Ubuntu 20.04.5 LTS system with openjdk 11.0.17 installed I had the problem described.
I changed
/etc/java-11-openjdk/security/java.security
from the original linejdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
to:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
i.e. removed (or re-enabled TLSv1 and TLSv1.1).
After this change the X11 GUI worked again.