Protocol is disabled or cipher suites are inappropriate

runtimeInfo:
version: 3.0.2
buildString: Release Build
locale: da-DK
systemInfo:
configFolder: /etc/openhab
userdataFolder: /var/lib/openhab
logFolder: /var/log/openhab
javaVersion: 11.0.11
javaVendor: Azul Systems, Inc.
javaVendorVersion: Zulu11.48+21-CA
osName: Linux
osVersion: 5.10.17-v7+
osArchitecture: arm
availableProcessors: 4
freeMemory: 117982496
totalMemory: 194838528

on at totally now installed image and add the binding IHC / ELKO Controller with correct username/pw and host Ip i get this error:
18:27:03.430 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ā€˜ihc:controller:8687d16ba5ā€™ changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Enyone know what to do?

same problem: IHC/ELKO binding "Offline Communication Error" in version 3.0.2
no further info yet

Same issue here:

IHC controller supports only TLS 1.0, which seems to be disabled in Zulu 11.48+21-CA. Not sure if TLS v1.0 can be enabled, but some other/earlier Java builds it was possible.

https://docs.azul.com/zulu/release-notes/april-2021.html

Whatā€™s New

TLS 1.0 and 1.1 is turned off

TLS 1.0 and 1.1 is turned off in the PSU builds in this release. This change affects the following Azul Zulu versions:

  • 16.30 (CA and SA)
  • 15.32.15 (CA), 15.32.16 (SA)
  • 13.40.15 (CA), 13.40.16 (SA)
  • 11.48.21 (CA), 11.48.22 (SA)
  • 8.54.0.21 (CA), 8.54.0.22 (SA)
  • 7.46.0.11 (CA), 7.46.0.12 (SA)

This may cause incompatibility issues if your application uses TLS 1.0/1.1.

1 Like

How and where do I verify these settings?

Thanks,
Bjarne

  • first: on command line check which version you have installed: java -version
  • according to IHC/ELKO binding "Offline Communication Error" in version 3.0.2 - #4 by lonly77 you can try to edit java.security file which you need to find
  • try to find the file either with the locate command: locate java.security or with dpkg -S java.security
    ( it may show more than just one file )
    ( take a backup of the original file before editing it )

I did see the post. That post referred to a Ubuntu installation. Mineā€™s an openHABian install. I tried with your suggestions, but no such luck:

openhabian@openhabian:~ $  locate java.security
-bash: locate: command not found
openhabian@openhabian:~ $ dpkg -S java.security
dpkg-query: no path found matching pattern *java.security*

Bjarne

When I run the command dpkg -S java.security, I get the exact same error: dpkg-query: no path found matching pattern *java.security*

Itā€™s not exact the same error.
The first error says that the command locate is not installed.
The second says that no path/file with that matching name is found.

Ok. Letā€™s try something else:

  • do: ls -l /usr/bin/java
  • that should be a link pointing to: /etc/alternatives/java
  • again do: ls -l /etc/alternatives/java
  • it should point to somewhere like: /usr/lib/jvm/zulu11/bin/java
  • go to: cd /usr/lib/jvm/zulu11/conf/security
  • there you should find the file java.security

Does that work ?

At least in official Zulu 11 docker container, java.security file is located to

/usr/lib/jvm/zulu11-ca-amd64/conf/security/java.security
pali@docker-server2:~$ docker pull azul/zulu-openjdk:11
11: Pulling from azul/zulu-openjdk
6e0aa5e7af40: Pull complete
d47239a868b3: Pull complete
49cbb10cca85: Pull complete
cc2eeee7c4d1: Pull complete
Digest: sha256:18e5b8b00bdb202137cf43f01c6a1db4344d0d391c0f6fc8b9389c2fbba1cbb8
Status: Downloaded newer image for azul/zulu-openjdk:11
docker.io/azul/zulu-openjdk:11

pali@docker-server2:~$ docker run -it azul/zulu-openjdk:11 /bin/bash

root@79a45c1f6bd4:/# java -version
openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

root@79a45c1f6bd4:/# find / -name java.security
/usr/lib/jvm/zulu11-ca-amd64/conf/security/java.security

root@79a45c1f6bd4:/# cat /usr/lib/jvm/zulu11-ca-amd64/conf/security/java.security

...

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    include jdk.disabled.namedCurves    
... 

Hi there,

Not quite. Hereā€™s what I got:

openhabian@openhabian:~ $ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Apr  1 12:50 /usr/bin/java -> /etc/alternatives/java
openhabian@openhabian:~ $ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 60 Apr  1 12:50 /etc/alternatives/java -> /opt/jdk/zulu11.45.27-ca-jdk11.0.10-linux_aarch32hf/bin/java
openhabian@openhabian:~ $ cd /opt/jdk/zulu11.45.27-ca-jdk11.0.10-linux_aarch32hf/bin/java
-bash: cd: /opt/jdk/zulu11.45.27-ca-jdk11.0.10-linux_aarch32hf/bin/java: Not a directory

The last step is not exaclty as what I did you need to cd into the directory one level higher than the bin directory; then conf/security:

cd /opt/jdk/zulu11.45.27-ca-jdk11.0.10-linux_aarch32hf/conf/security

Actually paying close attention to what you are actually writing make a huge difference :wink: Thanks.

Here my config:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    include jdk.disabled.namedCurves

Unfortunately, not seeing tls1 on the ā€œnaughtyā€ list means that my issue is not tls related.

I just re-added the IHC binding on my 3.0.1 install and I still get this error:

Error occured during XML data parsing

Any suggestions as to what the underlying issue may be?

Thanks!
Bjarne

Your issue is not related to TLS (what this topic is about) but XML parsing. Binding is communication fine with controller, but receive XML response or event which parsing fails for some reason. You could enable trace level logs to the IHC binding to see what data cause the issue.

Good point. Hereā€™s what I found in the openhab.log:

2021-05-07 00:06:03.747 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [hostname='192.168.0.12', username='oh3'].
2021-05-07 00:06:03.748 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Opening connection
2021-05-07 00:06:03.749 [DEBUG] [c.internal.ws.http.IhcConnectionPool] - Initialize SSL context
2021-05-07 00:06:03.750 [DEBUG] [ws.services.IhcAuthenticationService] - Authenticate
2021-05-07 00:06:03.753 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.0.12/ws/AuthenticationService, connectionPool=8163288, clientId=22188159 requestId=0, timeout=10000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <authenticate1 xmlns="utcs">
   <password>C7QxVP4o@Kz&Vq5!</password>
   <username>oh3</username>
   <application>treeview</application>
  </authenticate1>
 </soapenv:Body>
</soapenv:Envelope>
2021-05-07 00:06:03.878 [TRACE] [c.internal.ws.http.IhcConnectionPool] - Trusting server cert: C=DK, O=Lauritz Knudsen, CN=LK IHC Controller
2021-05-07 00:06:04.929 [TRACE] [c.internal.ws.http.IhcConnectionPool] - HostnameVerifier: arg0 = 192.168.0.12, arg1 = Session(1620338763866|TLS_RSA_WITH_AES_256_CBC_SHA)
2021-05-07 00:06:05.144 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Received response (connectionPool=8163288, clientId=22188159 requestId=0, in PT1.389581S, headers=[content-type: text/xml; charset="utf-8", date: Thu, 06-May-2021 21:07:37 GMT, keep-alive: timeout=900, max=1000, connection: Keep-Alive, content-length: 1872, server: Rogatkin's JWS based on Acme.Serve/$Revision: 1.39 $, mime-version: 1.0, set-cookie: JSESSIONID=-1620335257995-35950-760]): <?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>

<faultstring>Undefined: &amp;Vq5!&lt;/password&gt;
   &lt;username&gt;oh3&lt;/username&gt;
   &lt;application&gt;treeview&lt;/application&gt;
  &lt;/authenticate1&gt;
 &lt;/soapenv:Body&gt;
&lt;/soapenv:Envelope&gt;; @10:22</faultstring>

<detail>com.wingfoot.soap.SOAPException: Undefined: &amp;Vq5!&lt;/password&gt;
   &lt;username&gt;oh3&lt;/username&gt;
   &lt;application&gt;treeview&lt;/application&gt;
  &lt;/authenticate1&gt;
 &lt;/soapenv:Body&gt;
&lt;/soapenv:Envelope&gt;; @10:22
   at _ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE (/utcs/lib/libgcj.so.5)
   at _ZN4java4lang9Throwable16fillInStackTraceEv (/utcs/lib/libgcj.so.5)
   at _ZN4java4lang9ThrowableC1EPNS0_6StringE (/utcs/lib/libgcj.so.5)
   at _ZN4java4lang9ExceptionC1EPNS0_6StringE (/utcs/lib/libgcj.so.5)
   at 0x10290c30 (Unknown Source)
   at 0x1028c7f8 (Unknown Source)
   at 0x1028d1d8 (Unknown Source)
   at 0x10286db4 (Unknown Source)
   at 0x1028d454 (Unknown Source)
   at 0x1029a95c (Unknown Source)
   at 0x10297284 (Unknown Source)
   at 0x10256954 (Unknown Source)
   at 0x10185cf0 (Unknown Source)
   at 0x10185e30 (Unknown Source)
   at 0x1019c258 (Unknown Source)
   at 0x1019cb14 (Unknown Source)
   at 0x1019da6c (Unknown Source)
   at _ZN4java4lang6Thread3runEv (/utcs/lib/libgcj.so.5)
   at _Z13_Jv_ThreadRunPN4java4lang6ThreadE (/utcs/lib/libgcj.so.5)
   at 0x0fc7df24 (Unknown Source)
   at GC_start_routine (/utcs/lib/libgcj.so.5)
   at 0x0f8f43a0 (Unknown Source)
   at __clone (/lib/libc.so.6)
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

2021-05-07 00:06:05.148 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Can't open connection to controller Error occured during XML data parsing

Iā€™m not quite sure what to make of it.

Bjarne

Oops, you problem seems to be related to & character in your password. " < > & characters are reserved in XML and if they present in data, they should be escaped. At the moment IHC binding doesnā€™t do any escaping for username or the password (itā€™s definitely a bug), so you should avoid those characters at the moment.

2 Likes

Stupid me.

I used a password generator to generate a complex password including special characters. I didnā€™t consider that that might be an issue.

Thanks a bunch!

Bjarne

After I changed my password to something not containing special characters, everything worked as a charm!!

Thanks a bunch!

Bjarne

1 Like

Hi,

I have simillar problem.

I my case OH 2.5.12 stoped sending emails.

==> /logs/openhab.log <==

2021-05-28 17:04:55.887 [ERROR] [rg.openhab.action.mail.internal.Mail] - Could not send e-mail to 'lakowa@XXXX.PL'.
org.apache.commons.mail.EmailException: Sending the email to the following server failed : smtp.SERVER.PL:587
	at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1421) ~[commons-email-1.4.jar:1.4]
	at org.apache.commons.mail.Email.send(Email.java:1448) ~[commons-email-1.4.jar:1.4]
	at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:161) [bundleFile:?]
	at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:93) [bundleFile:?]
	at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:71) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor187.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1175) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1150) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1136) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1081) [bundleFile:?]
	at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:991) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:954) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:235) [bundleFile:?]
	at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:458) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:239) [bundleFile:?]
	at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) [bundleFile:?]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:201) [bundleFile:?]
	at org.eclipse.smarthome.model.script.runtime.internal.engine.ScriptImpl.execute(ScriptImpl.java:81) [bundleFile:?]
	at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.lambda$2(RuleEngineImpl.java:313) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: javax.mail.MessagingException: Could not convert socket to TLS
	at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1907) ~[bundleFile:1.4.7]
	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:666) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:317) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:176) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:125) ~[bundleFile:1.4.7]
	at javax.mail.Transport.send0(Transport.java:194) ~[bundleFile:1.4.7]
	at javax.mail.Transport.send(Transport.java:124) ~[bundleFile:1.4.7]
	at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1411) ~[commons-email-1.4.jar:1.4]
	... 30 more

Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
	at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:170) ~[?:?]
	at sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98) ~[?:?]
	at sun.security.ssl.TransportContext.kickstart(TransportContext.java:221) ~[?:?]
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:433) ~[?:?]
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:411) ~[?:?]
	at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:549) ~[bundleFile:1.4.7]
	at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:486) ~[bundleFile:1.4.7]
	at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1902) ~[bundleFile:1.4.7]
	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:666) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:317) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:176) ~[bundleFile:1.4.7]
	at javax.mail.Service.connect(Service.java:125) ~[bundleFile:1.4.7]
	at javax.mail.Transport.send0(Transport.java:194) ~[bundleFile:1.4.7]
	at javax.mail.Transport.send(Transport.java:124) ~[bundleFile:1.4.7]
	at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1411) ~[commons-email-1.4.jar:1.4]
	... 30 more

I use OH from docker. ZULU JAVA VERSION 11.

root@atom:/openhab# java -version
openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

I compile SSLPoke to check if the java can connect to my SMTP server. (Use SSL Poke to test Java SSL connection - matthewdavis111)

root@atom:/openhab# java SSLPoke smtp.SERVER.PL 465
Successfully connected

On port 465 I have configured SSL on EXIM, on port 587 I have TLS.

From the same docker I can connect to TLS 587/tcp with openssl.

root@atom:/openhab# openssl s_client -connect smtp.SERVER.PL:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mail.SERVER.PL
verify return:1
---
Certificate chain
 0 s:CN = mail.SERVER.PL
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[CUT]
-----END CERTIFICATE-----
subject=CN = mail.SERVER.PL

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5758 bytes and written 474 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B13341060C4B6669DB5E56A8E8F822729F2294CC13FE4A7D06046EBBB85AF0DF
    Session-ID-ctx:
    Master-Key: 157EAD1CB69FC19CC40D6C85722BBCD3F967398D35B48C4B68D18171B3FF58F0F98A78810F65E5BD74DFA300AEB87EF3
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1622214706
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
250 HELP

The same is on SSL ā†’ 465/tcp port.

I build docker image today, and I think it has some relation with java zulu.

Iā€™m wondering if the line:

Server Temp Key: ECDH, P-256, 256 bits

Can it be a problem with zulu java? Any idea?

OH2.5 isnā€™t supported on Java 11. Stuff may or may not work.