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.
- Anmelden oder Registieren, um Kommentare verfassen zu können
Comments
fromano, the client-server…
Gespeichert von service am/um Di, 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,…
Gespeichert von fromano am/um Mi, 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…
Gespeichert von service am/um Fr, 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…
Gespeichert von fromano am/um Mo, 10/26/2020 - 21:29
Antwort auf fromano, please have a look… von 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…
Gespeichert von fromano am/um Mo, 10/26/2020 - 21:58
Antwort auf fromano, please have a look… von 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 …
Gespeichert von fromano am/um Mo, 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…
Gespeichert von alexander.remesch am/um Do, 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.