CGate ssl Connection from Toolkit fails

I am using a Raspberry Pi 3B+ using the Bullseye OS to run CGate for my installation, and have recently created this version to replace an older Buster OS version which was running fine. The new version is able to operate the CBus network without incident, but it does not accept remote connections from a LAN PC running windows 10 from Toolkit, as it requires an ssl connection on port 20123. Using the unsecured connection 20023 from the same PC from telnet is fine.

The version of Toolkit is 1.15.7 and CGate is 2.11.5. Cgate is run using java on the Raspberry Pi.

I have read a previous post which had a similar issue, which seem to have been resolved by aligning version numbers, but in my case, the cgate and toolkit versions are from the same download and should theoretically not have this issue. The previous installation used the same version of toolkit but was an older version of cgate on the Raspberry Pi (2.11.4), and this one did not have this connection issue described above.

The error implies to me that there is an ssl certificate mismatch, but I have no idea how to correct this, if it is indeed the problem.

The tag, access.txt and C-GateConfig.txt files were copied from the old working installation to the new one unaltered, but all the other cgate files were copied from the CGate directory which contained the version 2.11.5.

The error returned when trying to connect ToolKit to the Remote CGate is 20053, with the text:
An error has occurred
An error occurred while initialising Secure Socket Layer. Cannot connect to C-Gate server.

Does someone have any idea where I need to change things to eliminate this problem.?

 

Might be something to do with a newer Java version in Bullseye install not supporting older TLS? At some point, TLS 1.0 & 1.1 support were dropped in Java. 8.54.0.21 I think. Maybe Toolkit still relies on the older TLS. This bit me at some point way back...

Check /usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/java.security or similar, and see if jdk.tls.disabledAlgorithms features TLS 1 & 1.1...

(edit) And looking at an older C-Gate I have I did indeed work around this by installing an older specific Java version... I find files at /usr/local/bin/cgate/jre/jre1.8.0_77

And the cgate unit... for C-Gate 2.11.4 build 3251

Code:

[Unit]
Description=cgate

[Service]
ExecStart=/usr/local/bin/cgate/jre/jre1.8.0_77/bin/java -Xms32M -Xmx256M -Djava.awt.headless=true -jar -noverify /usr/local/bin/cgate/cgate.jar
Restart=always
User=root
Group=root
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/usr/local/bin/cgate/

[Install]
WantedBy=multi-user.target

 

Way more information than anyone wants to know about Java crypto...

https://www.java.com/en/configure_crypto.html

 

My currently installed system has java-11-openjdk-armhf under /usr//lib/jvm

Under the /usr/local/bin/cgate directory; it references jre8.

I have just spoken to a support person at Schneider CBus, where he pointed me to a more recent version of the Toolkit/CGate package (1.16.2), which might address this issue. I will update these and report on what happens as soon as it is done.

 

Tested 1.16.2 back in June - Same issue still.
See this thread: https://www.cbusforums.com/threads/c-gate-command-port-issue-with-toolkit.10610/ for details on the issue, and workarounds. Issue is not cgate, but toolkit. Cheers....

 

I have the same problem. Editing /etc/java-11-openjdk/security/java.security to remove TLS1 from jdk.tls.disabledAlgorithms did the trick. It does make java slightly less secure on that host though.

 

It looks like even the the most recent toolkit and cgate (1.16.2) still uses the old Java 8 version as noted by the included files with the release, and that these are also only provided for a windows system so you can't use them to initiate java for cgate.

Best approach is to load up the old java 8 version into this cgate directories as suggested and run that with the system.

 

Thanks to Speedmeup for the important clue. I had struggled to find where this security information file was to be found in the Raspberry Pi system. Pointing me to the /etc/java-11-openjdk/security directory was the key.

I modified the "java.security" file to remove the TLSv1, and TLSv1.1 references from the jdk.tls.disabledAlgorithms section and all is working as expected from the Toolkit link.

It is important to note that as Toolkit uses this older security algorithm, regardless of the version, it cannot be effectively used for a remote CGate server unless it is enabled.

As I am using the system and PC for toolkit in a purely inhouse system, the theoretical security issue is of no interest to me, I just want it to work and be accessible, and the Raspberry Pi, where the CGate server is running, is only used to run Homebridge and nothing else.

I am happy to call this one closed, but it would be nice if Toolkit upgrades were brought up to date to utilise the more recent ssl security algorithms.

 

Been scratching my head for hours on this one. Thank you