Skip to main content


Eclipse Community Forums

      Home
Home » Eclipse Projects » Kura » Is the kura cloud communication to kapua secured with TLS?
Is the kura cloud communication to kapua secured with TLS? [message #1808074] Mon, 17 June 2019 02:56 Go to next message
Eclipse UserFriend
I was looking at the mqttDataTransport tab in the kura cloud configuration page and it has a few fields with ssl options. I'm not familiar with the security layer in kura, so i have a few dumb questions:

1) When kura connects to kapua through the cloud service is all the back and forth communication secure by default?

2) Is TLSv1 used by default and is it v1.0, or something higher like v1.1?
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808083 is a reply to message #1808074] Mon, 17 June 2019 05:36 Go to previous messageGo to next message
Eclipse UserFriend
Hi,
to connect to Kapua you have two options with Mqtt: select a mqtt endpoint that communicates without encryption or select an mqtts endpoint that communicates over an ssl channel.
So, to answer to your question, it depends on the user configuration if the communication will be secured or not.

The TLS protocol version can be changed as well in the "SSL Configuration" in the "Settings" page.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808097 is a reply to message #1808083] Mon, 17 June 2019 08:36 Go to previous messageGo to next message
Eclipse UserFriend
Hi.

When i try mqtts://someip:1883/ i get:

org.eclipse.kura.KuraConnectException: "Connection failed. Cannot connect"
	at org.eclipse.kura.core.data.transport.mqtt.MqttDataTransport.connect(MqttDataTransport.java:337)
	at org.eclipse.kura.core.data.DataServiceImpl$2.run(DataServiceImpl.java:605)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: MqttException (0) - javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
	at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:38)
	at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:736)
	... 1 more
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:994)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at org.eclipse.paho.client.mqttv3.internal.SSLNetworkModule.start(SSLNetworkModule.java:149)
	at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:722)
	... 1 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
	at sun.security.ssl.InputRecord.read(InputRecord.java:505)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
	... 6 more


And i get this on both of my kura 4.1.0 devices. Normal connection without security (mqtt://someip:1883/) works normally. I tried configuring the "SSL Default Protocol" field to "TLSv1.2". I also tried to leave it empty, but i always get the same error when trying to securely connect to the broker.

What could i be missing?
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808104 is a reply to message #1808097] Mon, 17 June 2019 09:28 Go to previous messageGo to next message
Eclipse UserFriend
Usually mqtts is associated with port 8883.
Then it depends on the local broker the mqtts setup.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808107 is a reply to message #1808104] Mon, 17 June 2019 10:02 Go to previous messageGo to next message
Eclipse UserFriend
I changed the port to 8883 (which is also active, when i looked at the kapua broker). But i get the same error. I changed nothing in the configuration other than the url, and it is working fine if i change back into unsecure connection. Both of my devices work fine with the unsecure connection, but as soon as i change "mqtt://someip:1883/" into "mqtts://someip:8883/" it throws the error i posted above.
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808122 is a reply to message #1808107] Mon, 17 June 2019 14:30 Go to previous messageGo to next message
Eclipse UserFriend
Hi,
I don't know why you are getting that error from Kapua. It seems that the broker drops the connection.

Maybe ask the Kapua team if they have any idea.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808134 is a reply to message #1808122] Tue, 18 June 2019 01:00 Go to previous messageGo to next message
Eclipse UserFriend
Ok, i will, but a few more questions before that.

When i look at the kapua broker log, it says that the cause for the dropped connection is:

Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common


So i assume that i need to list some common cipher suites between kapua and kura, however i have no idea what those might be. Maybe you could give me some examples that worked for you?

I currently have it setup like:

SSL Default Protocol
TLSv1.2
SSL Hostname Verification
Rely on SSL Manager Service configuration
SSL Default Cipher Suites
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

I used the cipher suites above from the kura tests i found here:

https://github.com/eclipse/kura/blob/571d47a12076248cd0110ca31adadb2f2a913543/kura/test/org.eclipse.kura.core.ssl.test/src/test/java/org/eclipse/kura/core/ssl/SSLSocketFactoryWrapperTest.java

[Updated on: Tue, 18 June 2019 01:44] by Moderator

Re: Is the kura cloud communication to kapua secured with TLS? [message #1808144 is a reply to message #1808134] Tue, 18 June 2019 03:59 Go to previous messageGo to next message
Eclipse UserFriend
If you don't have specific needs for cipher suites, you don't need to specify them.

Kura relies on the suites provided by the JVM. As long as the JVM is updated, there is no problem in terms of security.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808161 is a reply to message #1808144] Tue, 18 June 2019 06:41 Go to previous messageGo to next message
Eclipse UserFriend
Thank you for the answers, i wrote to kapua forum about this issue. Hopefully i will get to the root cause of this.
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808675 is a reply to message #1808122] Fri, 28 June 2019 09:12 Go to previous messageGo to next message
Eclipse UserFriend
Since the kapua forum seems to be a bit dead (did not get a response), i figured i would host my own broker with tls and see if the kura gateways would connect to it. Alas i'm now getting other errors with no successful connection. This is what i did.

1) Created a broker private key m2mqtt_srv.key
2) Created a broker certificate m2mqtt_srv.crt
3) Created a self signed CA certificate m2mqtt_ca.crt
4) Hosted a mosquitto mqtt broker on port 8883 with the tlsv1.0, tlsv1.1, tls1.2 enabled and the previously created certificates and keys.
5) I tested out the mosquitto broker secure connection with this command:
mosquitto_pub -h 192.168.125.110 -t test/device --cafile m2mqtt_ca.crt -m "hello" -p 8883

It worked and the message was published.
6) In kura device ui i went to the Settings -> Server SSL Certificate tab
a) In "Storage Alias" field i wrote in my name from the "Topic Context Account-Name" field
b) In the "Certificate" field i pasted my self signed certificate m2mqtt_ca.crt:
-----BEGIN CERTIFICATE-----
MIIEBTCCAu2gAwIBAgIUc2g7zOgAD9/Dd/78YJPFDXvxxaswDQYJKoZIhvcNAQEL
BQAwgZExCzAJBgNVBAYTAkxUMREwDwYDVQQIDAhLbGFpcGVkYTERMA8GA1UEBwwI
S2xhaXBlZGExDjAMBgNVBAoMBUlhbXVzMRIwEAYDVQQLDAlJYW11cyBkZXYxGDAW
BgNVBAMMDzE5Mi4xNjguMTI1LjExMDEeMBwGCSqGSIb3DQEJARYPaWFtdXNAaWFt
.........
uSZ6onL5TjThSRYdOiY6s4cAg11gk6x3McLkDPRZCtemHzJKs3I5Yb/+b2rYdHrn
49W6/jx2mN/xd/s5WiR2vxcCbWZ0IRZKTLRakPDMueqyVTxi8cb1o6ujOMI5xTfU
lKZeJbObAlBZ0Z7ai43f9mIm6IzqL4L3sQ==
-----END CERTIFICATE-----

c) Clicked "apply"
7) Tried to connect to the mosquitto broker with the kura gateway and got an error:
2019-06-28T11:43:07,960 [qtp1096499602-108] WARN  o.e.k.w.s.GwtNetworkServiceImpl - Error connecting
org.eclipse.kura.KuraConnectException: "Connection failed. Cannot connect"
	at org.eclipse.kura.core.data.transport.mqtt.MqttDataTransport.connect(MqttDataTransport.java:337)
	at org.eclipse.kura.core.data.DataServiceImpl.connect(DataServiceImpl.java:489)
	at org.eclipse.kura.web.server.GwtStatusServiceImpl.connectDataService(GwtStatusServiceImpl.java:103)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:587)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:333)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:303)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373)
	at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
	at org.eclipse.kura.web.server.OsgiRemoteServiceServlet.service(OsgiRemoteServiceServlet.java:41)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl$LegacyServlet.service(HttpServiceRuntimeImpl.java:1223)
	at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:148)
	at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:62)
	at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:131)
	at org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.service(ProxyServlet.java:74)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:284)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.Server.handle(Server.java:503)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:748)
Caused by: MqttException (0) - javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
	at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:38)
	at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:736)
	... 1 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at org.eclipse.paho.client.mqttv3.internal.SSLNetworkModule.start(SSLNetworkModule.java:149)
	at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:722)
	... 1 more
Caused by: java.security.cert.CertificateException: No subject alternative names present
	at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145)
	at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:200)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
	... 10 more


8) I tried the above on 3 different kura devices, 2 docker container and one natively installed (all of them at version 4.1.0)

9) Then i tried to host a openssl server to check what is going on with the handshake:
openssl s_server -accept 8883 -cert m2mqtt_srv.crt -key m2mqtt_srv.key -verify 10 -CAfile m2mqtt_ca.crt


10) I first tried to again test with the mosquitto publisher:
mosquitto_pub -h 192.168.125.110 -t kiosks/device --cafile m2mqtt_ca.crt -m "hello" -p 8883

and in the openssl server i get:
-----BEGIN SSL SESSION PARAMETERS-----
MFoCAQECAgMDBALAMAQABDDvZ4d/rpld8bGXum1pAJLfTsjXKmcp+3eIo62xoNwp
xeVIDbidTL0/qI015m3i7VmhBgIEXRYQd6IEAgIcIKQGBAQBAAAArQMCAQE=
-----END SSL SESSION PARAMETERS-----
Shared ciphers:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Supported Elliptic Groups: X25519:P-256:X448:P-521:P-384
Shared Elliptic groups: X25519:P-256:X448:P-521:P-384
---
No server certificate CA names sent
CIPHER is ECDHE-RSA-AES256-GCM-SHA384
Secure Renegotiation IS supported


11) I then try the same with the kura gateway and in the openssl server i get:
ERROR
139965834281408:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1528:SSL alert number 46
shutting down SSL
CONNECTION CLOSED


12) Both the mosquitto publisher and the kura gateway use the same CA certificate

I'm currently running out of ideas as to what might be wrong with my setup. Can anyone spot any errors that i made?

[Updated on: Fri, 28 June 2019 09:13] by Moderator

Re: Is the kura cloud communication to kapua secured with TLS? [message #1808712 is a reply to message #1808675] Sat, 29 June 2019 07:24 Go to previous messageGo to next message
Eclipse UserFriend
Hi,
I believe the kura exception says clearly why it is not connecting: "No subject alternative names present"
To force connection you can disable the hostname verification feature in SSL config. Otherwise, please review your certificates.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808742 is a reply to message #1808712] Mon, 01 July 2019 01:03 Go to previous messageGo to next message
Eclipse UserFriend
Hi,

I tried turning off the hostname verification as you suggested, but i'm still left with this error:

WARN  o.e.k.w.s.GwtNetworkServiceImpl - Illegal client state
java.lang.IllegalStateException: Invalid client configuration
	at org.eclipse.kura.core.data.transport.mqtt.MqttDataTransport.setupMqttSession(MqttDataTransport.java:878)
	at org.eclipse.kura.core.data.transport.mqtt.MqttDataTransport.connect(MqttDataTransport.java:291)
	at org.eclipse.kura.core.data.DataServiceImpl.connect(DataServiceImpl.java:489)
	at org.eclipse.kura.web.server.GwtStatusServiceImpl.connectDataService(GwtStatusServiceImpl.java:103)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:587)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:333)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:303)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373)
	at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
	at org.eclipse.kura.web.server.OsgiRemoteServiceServlet.service(OsgiRemoteServiceServlet.java:41)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl$LegacyServlet.service(HttpServiceRuntimeImpl.java:1223)
	at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:148)
	at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:62)
	at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:131)
	at org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.service(ProxyServlet.java:74)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:284)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.Server.handle(Server.java:503)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:748)


Just to check that everything in the settings are ok, i switched back to 1883 unsecured connection on the same broker and kura connects fine then. You then suggested to check the certificate, so i did:

openssl verify -CAfile m2mqtt_ca.crt m2mqtt_srv.crt


It returns: 

m2mqtt_srv.crt: OK


I also tried again with the other mosquitto publisher posting to the secured 8883 connection and it works fine with the same certificate. I also wrote a python publisher that uses paho library and it also connects and posts to 8883 with the same certificate.

This is how my configuration looks:

https://i.imgur.com/Y5qKu2B.png
https://i.imgur.com/roM9mMc.png
https://i.imgur.com/ALwYIyO.png

Any ideas why it would throw 
Illegal client state
java.lang.IllegalStateException: Invalid client configuration
. Connection on the 1883 unsecured works with the same settings on this kura device, so the only thing different is the url, but i tried the 8883 port with the mosquitto and python publishers and it works fine with them.

[Updated on: Mon, 01 July 2019 03:06] by Moderator

Re: Is the kura cloud communication to kapua secured with TLS? [message #1808746 is a reply to message #1808742] Mon, 01 July 2019 03:24 Go to previous messageGo to next message
Eclipse UserFriend
Hi,
it seems that there is some configuration issue: https://github.com/eclipse/kura/blob/develop/kura/org.eclipse.kura.core/src/main/java/org/eclipse/kura/core/data/transport/mqtt/MqttDataTransport.java#L878

Maybe have a look at why that happens. Or just restart configuring it from scratch.
In most cases (apart for the hostname verification) you don't need to change the general SSL configuration or the specific cloud service one.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808779 is a reply to message #1808746] Mon, 01 July 2019 09:24 Go to previous messageGo to next message
Eclipse UserFriend
Thank you for the tips. I managed to connect kura to the broker with a new certificate. This time i enabled avahi on my dev machine (that runs the mosquitto broker) and kura gateway so that i could use hostnames instead of ip's for the certificates. This seemed to have helped (not 100% sure though).

In the process i did seem to encounter 2 potential issues with kura. I attached a remote debugger to the kura instance and:

1) If i did not set the ssl protocol in the kura interface, it would be passed as an empty string in the properties map and the connection would fail with the "Invalid client configuration" error. In the kura ui, it says that it would default to TLSv1 if not specified, but that did not seem to happen to me.

2) Even when i set both options for hostname verification in "SSL Configuration" panel and "MQTTDataTransport" panel to value "false", it still ended up as "true" in the "MqttConnectOptions" object.

https://github.com/eclipse/kura/blob/develop/kura/org.eclipse.kura.core/src/main/java/org/eclipse/kura/core/data/transport/mqtt/MqttDataTransport.java#L811

Here in the "SSLSocketFactoryImpl" object it is set as "hostnameVerification=false", but in the "MqttConnectOptions" it set as "httpsHostnameVerificationEnabled=true".

When i was using ip for hostname verification and it was not connecting, in the debugger i toggled the "httpsHostnameVerificationEnabled=true" to "httpsHostnameVerificationEnabled=false" and then it connected.

P.S Is there a way to launch the debug kura instance in the docker container?
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808781 is a reply to message #1808779] Mon, 01 July 2019 09:57 Go to previous messageGo to next message
Eclipse UserFriend
Hello,
thank you for the feedback.
I believe you can open corresponding issues in the Kura repository in GitHub, trying to provide as much detail as possible to allow developers to recreate the issues.

Regarding the docker image, it's not possible for what I know.

Best regards,
Matteo
Re: Is the kura cloud communication to kapua secured with TLS? [message #1808983 is a reply to message #1808781] Fri, 05 July 2019 09:00 Go to previous messageGo to next message
Eclipse UserFriend
Hi.

Ok, i will try to find some time for that.

As for the docker container debugging, it seems that the only differences between the default run and debug run kura scripts are these lines:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/var/log/kura-gc.log \
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M \
-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \


If i add these to the /usr/local/bin/start-kura in the docker container, i wonder if that would be enough for a debug mode?
Re: Is the kura cloud communication to kapua secured with TLS? [message #1809056 is a reply to message #1808983] Mon, 08 July 2019 03:29 Go to previous message
Eclipse UserFriend
Yes, it should work.
Previous Topic: Issue installing Kura Eclipse on raspi3
Next Topic:H2db-server connection problem
Goto Forum:
  


Current Time: Mon Jun 23 15:42:31 EDT 2025

Powered by FUDForum. Page generated in 0.09226 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly