CGateToolkit cannot connect to remote CBus system - Apparent TLS issues

Hi I am running into an issue running CGateToolkit from my windows machine, trying to connect to a linux system that is physically connected to the CBus System.

I'm almost 100% certain that this has worked in the past with no changes on the CGate side. I have since updated my laptop and with all the standard OS updates its possible that there are some TLS updates that are no longer compatible.

Version Information
Client:

- Toolkit version: 1.14.4 (On my Windows 11, and tested from another Windows 10 machine)​

Server:

- Clipsal C-Gate: 2.11.3_3249 (Running on linux)
- Java - openjdk version jre1.8.0_77 (I explicitly downloaded and am running cgate via this version as I previously ran into the same issues as noted in this old thread https://www.cbusforums.com/threads/c-gate-command-port-issue-with-toolkit.10610)​

Details
Running telnet to the "insecure" port of 20023 allows me to connect fine (I have some automation software that communicates fine over this port), however am having problems having the toolkit connect via the secure port 20123.

Reviewing the logs from CGate I can See the following

20260104-104524 999 sys Selected client cipher: SSL_NULL_WITH_NULL_NULL
20260104-104524 191 sys javax.net.ssl.SSLPeerUnverifiedException exception encountered : peer not authenticated
20260104-104524 803 cmd35 - Host:/192.168.1.224 opened command interface from port: 52676
20260104-104524 899 sys Debug: New Command Context: cc029 = AccessContext Session /192.168.1.224#36
20260104-104524 766 cmd35 - Response: 201 Service ready: Clipsal C-Gate Version: v2.11.3 (build 3249) #cmd-syntax=1.0
20260104-104524 804 cmd35 - Host:/192.168.1.224 closed command interface from port: 52676​

It sounds like its some sort of probelm with the TLS negotiation so im guessing something has changed somewhere along the lines recently.

I wish wish wish that we could just change the port that the toolkit uses (see previous thread https://www.cbusforums.com/threads/remote-c-gate-and-port-number.9014/), does anyone know if there is any way to bypass this? I even tried decompiling parts of the toolkit to understand what its doing and it actually looks like parts of the code would allow connecting over the insecure port, but I couldn't get any closer to finding how how I could force it to go down this code path. I only really need to get this working for a short period to fix some issues.

Does anyone know if there is anywhere we can get the Toolkit source code, I am happy to rebuild and run it locally myself if needed. Any idea where we could reach out to get more information about this?

I'm starting to think my only solution is to try and decipher the manual and commands enough to do what I need "manually" over the insecure channel. Lets just say I'm hoping that with a future reno I can remove as much of this system as possible. ☹️

 

Ill add some more context. When trying to check what TLS details are exposed I have run the command


openssl s_client -connect <CGATE_IP>:10123 -tls1_2

and it returns the following block

CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=0 C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = Kipper Client, emailAddress = [email protected]
verify error:num=26:unsupported certificate purpose
verify return:1
depth=1 C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
verify return:1
depth=0 C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = Kipper Client, emailAddress = [email protected]
verify return:1
139714652407104:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1552:SSL alert number 42
---
Certificate chain
0 s:C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = Kipper Client, emailAddress = [email protected]
i:C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
1 s:C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
i:C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFuDCCBKCgAwIBAgIBAjANBgkqhkiG9w0BAQsFADCBzzELMAkGA1UEBhMCQVUx
GDAWBgNVBAgTD1NvdXRoIEF1c3RyYWxpYTERMA8GA1UEBxMIQWRlbGFpZGUxLzAt
BgNVBAoTJlNjaG5laWRlciBFbGVjdHJpYyAoQXVzdHJhbGlhKSBQdHkgTHRkMRMw
EQYDVQQLEwpTbWFydFNwYWNlMTMwMQYJKoZIhvcNAQkBFiRzb2Z0d2FyZS5hcGFj
QHNjaG5laWRlci1lbGVjdHJpYy5jb20xGDAWBgNVBAMTD1N5c3RlbSBTb2Z0d2Fy
ZTAeFw0xNzA1MjYwNDE1MDVaFw0yNzA1MjQwNDE1MDVaMIHNMQswCQYDVQQGEwJB
VTEYMBYGA1UECBMPU291dGggQXVzdHJhbGlhMREwDwYDVQQHEwhBZGVsYWlkZTEv
MC0GA1UEChMmU2NobmVpZGVyIEVsZWN0cmljIChBdXN0cmFsaWEpIFB0eSBMdGQx
EzARBgNVBAsTClNtYXJ0U3BhY2UxFjAUBgNVBAMTDUtpcHBlciBDbGllbnQxMzAx
BgkqhkiG9w0BCQEWJHNvZnR3YXJlLmFwYWNAc2NobmVpZGVyLWVsZWN0cmljLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYQMrHS1yYGqoHN5zm1
QziTdBdhoJVoeYVaWXzWAbQxvj0W4Tx5gSmHs/0CZdyDfLeUyZQOwAwLA5bonYz5
w8lT3d3chXSUQvKvP2s91cZosVAUkpbneFj2Lyjlx+m+8ZJyrSk+8cXhudmue8aC
ANWC3mtF3LAM8EbLjx7lTVABVFoC055Zk/ZjVau59Fx5T1xQbHo5UAPT/jpXrQxN
eEvM4odw675HCHUKYsZCgSL8EeASrLZAHlcYG9a2FcKkwtQqtVfO4KXq61y2ghc4
gJ17x/2b1e7a09jWP+tE35mhq1pp1Y2Sl7yIl7NVUy8sMN2tWskBdT6Tk/gbJw95
7HECAwEAAaOCAZ0wggGZMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMCwG
CWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAOBgNV
HQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud
DgQWBBTa1C5p4uZGrEoZWUHrBpPLd6KFWDCB/AYDVR0jBIH0MIHxgBT6qfWlDKnI
IVU+XuN0tN/9qzFkiKGB1aSB0jCBzzELMAkGA1UEBhMCQVUxGDAWBgNVBAgTD1Nv
dXRoIEF1c3RyYWxpYTERMA8GA1UEBxMIQWRlbGFpZGUxLzAtBgNVBAoTJlNjaG5l
aWRlciBFbGVjdHJpYyAoQXVzdHJhbGlhKSBQdHkgTHRkMRMwEQYDVQQLEwpTbWFy
dFNwYWNlMTMwMQYJKoZIhvcNAQkBFiRzb2Z0d2FyZS5hcGFjQHNjaG5laWRlci1l
bGVjdHJpYy5jb20xGDAWBgNVBAMTD1N5c3RlbSBTb2Z0d2FyZYIBADANBgkqhkiG
9w0BAQsFAAOCAQEASt1YxbazKk33PsrxVlne2lEnPmfe715Ua3cWm6VWpqFVHvKh
8u0LV7qSWP/hlMPQOO3zHEfT/RytO8Tlx3+aLxaMIrR1q8v8Oc2z5YWX9SjabSHZ
jxf3C+gMLuHgsiBJLT8oO3E6WhYDaqPhc0L8kGGOpuaUEe4NoXSZDleKIaz3/l8J
x6UAbY5wIRaGfAhHelJrRgXHvj1AbCAeaGpv2FgYgQau4bA6MJu3dzlSxm5/VzBt
2zPI7+lo1dP+hmBRZdw0gwvs0Ii4P6dzzJswO3pe5PqpzOFcK7n5wyxYSpT0TW5/
YgAwuDZxVDLBNK12mQ+L6ahJNQVjhFrioX2bQQ==
-----END CERTIFICATE-----
subject=C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = Kipper Client, emailAddress = [email protected]
issuer=C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
issuer=C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
---
---
Acceptable client certificate CA names
C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = Kipper Client, emailAddress = [email protected]
C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, emailAddress = [email protected], CN = System Software
C = AU, ST = South Australia, L = Adelaide, O = Schneider Electric (Australia) Pty Ltd, OU = SmartSpace, CN = CGate Server, emailAddress = [email protected]
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1SA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3956 bytes and written 326 bytes
Verification error: unsupported certificate purpose
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 695A4A76B66C9E89F40D24F078FFE72B2C9B87D8710E346F44530C796170DFCA
Session-ID-ctx:
Master-Key: 38906F1776BE0CE432B420115EF960D04667ECEDAEEF5D8585F41A8A5D71082B973B86F07887B54A46F0102CF0558191
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1767524982
Timeout : 7200 (sec)
Verify return code: 26 (unsupported certificate purpose)
Extended master secret: no
---​

There seem to be a few interesting peices there but a few things jump out.
* there are a lot of warnings\errors. I'm assuming they are ignored by the toolkit client, but not sure.
* It does look like it is presenting TLSv1.2 which I would have thought it should be a good thing based on all the other issues in this forum with TLS1.0 being used.
* Testing the command against tls1, tls1_1, tls1_3 just results in errors which I think is a good thing that means it really is using TLSv1.2
* Looking at the actual cert data it looks like it is Valid To: May 23, 2027, while that's not a problem now does that not mean that this version of cgate will not work at all at that point?


So im at a loss as to what the actual error is. Based on the CGate logs its clearly something during the TLS negotiation but it looks like it should be fine, and like I said, im pretty certain that this CGate instance has worked perfectly fine remotely in the past...