Java Runtime Environment: Shipped with docker image
openHAB version: 4.0.4
Issue of the topic: Sudenly I’ve notice my HTTPs thing is not updating. In logs I can see there is problem with SSL connection: failed: javax.net.ssl.SSLHandshakeException: Received fatal alert: h
andshake_failure. It is public service and the certificate is valid. Also the call from local station, or even with curl or wget from docker image itself is working just fine.
Please post configurations (if applicable):
HTTP thing configuration:
Hello,
exactly same problem with same solaxcloud from Nov 23th 12h00.
Probably solax changed something since at this date I had no update both on debian or openhab.
Nevertheless CURL command from debian still work properly … strange.
May-be playing with thing configuration ?
I will post again if I find something
Bye
I could not find a solution with http binding, so I switched to a exec:command with curl and then parsed the output. Not a clean solution but it works and should be more insensitive to updates
thank you for your reply. Unfortunatelly I didn’t have time to go through the issue. It looks like the things configuration stopped working in the same time also on my site.
I’ll assume there is maybe smth wrong with the cipherset suit and/or some headers are now required.
I was able to track down the problem. I start digging into solaxcloud TLS session and I figure it out where is the problem on solax site.
The resolution is clear when you compar the output of given commands:
There is specifig cipherset suit for given connection with is different for “www” service and “non-www” service. Solax just messed up the DNS vs cipherset suit strings per service - dunno if by mistace or by purpose (acctually both make sence).
To fix it up on site of OpenHab just define solax thinks without “www” and it will start just working like a charm. There is than no need to use custom script.
Solax already changed the situation and now even the connection without “www” is not working. It looks like the solaxcloud enhanced its onw TLS security connection and allowing only secure TLS ciphers to be negotiated. The cipher set suite string which will allow TLS connection is: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 .
So the real question is how to increase the ability of OpenHab HTTP think to use more secure TLS ciphers?
Cipher suites are part of the underlying java installation. As far as I understand TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 should be part of it.
What does a network trace of protocol negotiation show ? You should be able to see which ciphers and algorithms are available on client and server site. You also should be able to see an error message in the negotiation part of the network trace.
So for normal installs that install Java based on the methods listed on OpenHab for recommended version it seems we should be ok. Not sure about docker install.
Confirmed for Both windows version of Java install and Linux version on Debian 12 (bookworm)
Yes it appears you are missing all of the AES_256 cyphers
Where are you located ?
Is this the official openhab docker image or is it something you created custom?
Due to local laws and export restrictions the containers use Java with a limited cryptographic strength policy. Some openHAB functionality may depend on unlimited strength which can be enabled by configuring the environment variable CRYPTO_POLICY=unlimited
Before enabling this make sure this is allowed by local laws and you agree with the applicable license and terms (see OpenJDK (Cryptographic Cautions)).
The following functionality depends on the unlimited cryptographic strength policy:
Thank you for pointing me for given detail - I was totaly unaware of such restriction. I’ve recreated the docker image with setup the env CRYPTO_POLICY=unlimited and it looks like it solved the problem.
Solution I’ve posted above worked for only for limited time where solax didn’t alight their services accordingly.
Funny is that http biding is not mention among the ones which depends on cryptographis strenght policy.
