MQTT TLS with username / password auth

Ewon Support Basic and Java
#1

How can you configure the eWON MQTT client to use SSL/TLS encryption with username / password auth?

I can connect to this endpoint with standard MQTT clients like mqtt.js, and the eWON works fine without SSL. When I enable SSL, the eWON connects, but then the MQTT Publish fails.

Here’s the BASIC code I’m using:

Mqtt “Open”, “ewon”, “clarity.jcore.io”
Mqtt “SetParam”, “port”, “8883”
Mqtt “SetParam”, “username”, “customer1/username1”
Mqtt “SetParam”, “password”, “password”
Mqtt “SetParam”, “TLSVersion”, “1.2”
Mqtt “Connect”

Tset 1,5
Ontimer 1,“goto MqttPublish”
End
MqttPublish:
Mqtt “Publish”,“data”,“message”,0,0
End

#2

Hi @jason_mcl,

Do you see any errors in the logs regarding the publish request? Do you need to use any certificates for your setup? Here is an example over on our tech forum that uses signed certifiacts to post to an mqtt server on AWS. https://techforum.ewon.biz/thread-474.html?highlight=MQTT

Regards,
Deryck

#4

Hi Deryck,

I do see a message in the IDE error log saying the MQTT publish failed, but that’s all the info I can see. Is there a more detailed log I could look at somewhere?

The AWS use case is different from mine, because AWS uses client certificates to authenticate the client to the server. My use case uses normal MQTT username and password authentication to authenticate the client to the server. Both use cases use the server’s certificate in the same way (to authenticate the server to the client).

To connect to my endpoint using a standard MQTT client, you just put in a mqtts:// host URL along with the username and password. The client then fetches and validates the server’s certificate using a standard SSL handshake, and performs MQTT authentication via the CONNECT message. How do I get this to work on the eWON?

Thanks!!

#5

Hi Jason,

To start it might help to enable verbose logging so we can see more details about the errors.
can you add the following line.
MQTT "setparam", "log", "1"

It also looks like you could be setting the tls version wrong. the values supported in that field are are tlsv1, tlsv1.1 or tlsv1.2. tlsv1.2 is the default setting so you should be ok with removing that line.

Deryck

#6

Hi Deryck,

Thanks for the tips about the logging and TLS version setting. Unfortunately turning on logging didn’t change the output. I still just get a "Operation Failed: Mqtt “Publish”…

I have verified that with all the recommended settings (port 8883, TLSVersion tlsv1.2), the eWON still connects to the endpoint without using SSL. In other words, if I run an MQTT broker without SSL and bind it to port 8883, the eWON will connect to it and communicate without using SSL.

What actually tells the eWON MQTT client to use SSL? It seems like turning on some of the client certificate settings makes it use SSL, but we don’t use client certs in this case.

Thanks!

#7

Hi @jason_mcl,

The verbose logging is going to be in the real time logs is this where you were looking?

Checking with a colleague he pointed out that it is required to add the tls certificates. and add them with this call: MQTT "setparam", "cafile", "/usr/certs/ca.crt" In this example the certificate is stored in the usr directory in a certs folder. This is due in part because the ewon does not contain any certificates itself.

Check the realtime logs i suspect you will see OpenSSL Error: error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate

Regards,
Deryck

#8

OK thanks, that makes sense.

How can I upload the CA certificate to /usr/certs/ca.crt? I spent 30 minutes Googling and haven’t found anything other than writing a custom program to transfer the file. But surely each person who needs to upload a file to an eWON doesn’t need to write a custom program to do so, right?

Thanks for your help!

#9

Hi Deryck,

OK, I figured out how to FTP files onto the device, so never mind that part. And I also found the real time log, thanks for the tip about looking for that.

I concatenated together the trust root and CA certificates, stored them on the device at /usr/certs/ca.crt, and added the MQTT “setparam”, “cafile”, “/usr/certs/ca.crt” line. That does finally prevent it from using plain MQTT with no SSL. However, it never completes an SSL handshake with the endpoint, and it doesn’t log any reason why not.

So my questions now are:

  • Am I doing the right thing by concatenating the root and CA certificates into ca.crt?
  • Are there any other parameters I need to be setting?
  • Is there any other way to get an error message out of the unit?

BTW I’m using a standard MQTT client to verify that the MQTTS endpoint has valid certs and is working right.

Thanks!

#10

Hi @jason_mcl,

Apologies for just getting back to you I will need to look into this. What are you using for the certificates? Could you share it with me?

Regards,
Deryck

#11

No problem, the attached file has the root and CA certificates that match with mqtts://clarity.jcore.io. The username and password in my example are fake, but you should be able to at least get through a SSL handshake even without valid MQTT credentials.

#13

Hi Jason,

Thank your for your patience with this issue, tls is fairly complex.

To start I think you only need to CA certificate on the flexy and if the root certificate is needed it would need to be in a separate file. I’m not exactly sure what you would need to root Certificate for your application at this point. Try removing the root certificate from the file and try just using the CA. This might be all you need to get the communication working. If not I would like to see what you are getting for logs on the MQTT server to see if that can provide more information. Along with a back up of the device, with support files. This can be taken from ebuddy.

We might also need to determine if your server needs the flexy to use client certificate authorization.

A third option might be to create your own self signed certificates and add the certificates to the appropriate devices. One on the server and the other on the Client (flexy).

Deryck

#14

Hi Deryck,

Yea TLS is complex and has a lot of steps, so thanks for your help.

I tried putting just the CA certificate in ca.crt, and got the same result… the only log messages are saying that the publish failed. Is there another debug flag we need to be turning on to get the SSL error? I know from debugging into the broker itself that the eWON is not successfully completing a SSL handshake.

The broker doesn’t require client certificate authentication–it just requires the client to go through a normal SSL handshake, and then it uses the username and password from the MQTT CONNECT message to authenticate the client.

I could look into supporting SSL client certificates in our broker. Early on a lot of devices didn’t support client certificates, but I think some customers may want to use them going forward.

I imagine the answer is no, but it’s worth asking just to make sure… is there any way to get something like an SSH shell and run standard open source stuff on the eWON, either by cross compiling a native executable or by using a python or node.js runtime on the box?

Thanks!

#15

Hi Deryck,

I finally got the SSL handshake working. Putting the root certificate and CA certificate together in one file, and passing that to MQTT “SETPARAM”, “cafile”, was what did the trick.

Thanks for your help with this!

#16

Hi @jason_mcl,

Glad to hear it is working!

Was this any different from how you were previously passing the CA? Previously you mentioned you were using: MQTT “setparam”, “cafile”, “/usr/certs/ca.crt”

We don’t have an option to run python or node.js natively but we do have support for Java. With a J2se runtime available. The took kit is designed around JVM version 1.4. More info is available here: https://developer.ewon.biz/content/java-0

Regards,
Deryck

#17

I had actually tried providing the concatenated root and CA cert via MQTT "setparam" "cafile", but it didn’t work that time for some reason. Not sure why it worked this time.

I finally got it working after bringing up Wireshark and looking at the SSL error codes that the eWON was sending to the server. It would be pretty helpful to have those error codes and messages passed up thru the scripting runtime.

Thanks again for your help.

#18

Thanks for the follow up. I had originally though it was the Root being included that might have been causing issue. If that is still included I am not sure, perhaps there was an issue with the formatting. I have seen issues before when keys were copied where line endings changed the file.

I agree these should be in the logs. I had though these were in the real time logs once verbose logging was enabled. I’ll forward this feedback so we hopefully see this added in a future release. If you run into other issues you should be able to see similar errors from the server side showing the SSL connection failing and why. Though this can very depending on the MQTT server used.

Regards,
Deryck

#20

Hi Deryck,

So far we’re having success connecting eWONs when we provide that root + CA certificate. I’m concerned that we’re creating a time bomb by doing that. Our site certificates get updated ever 3 months, and there’s no guarantee that the CA will always sign our site certificates with the same CA certificate. If our CA ever updates their CA certificate, all of our eWONs will drop offline at the same time until their CA certificates can be replaced.

Why does the eWON require us to provide a CA certificate when we’re using a publicly trusted CA? Is it because the eWON MQTT implementation doesn’t activate SSL unless a certificate is provided in the MQTT parameters? Or is it because the eWON doesn’t ship with SSL trusted roots installed?

It would be great to get a long term fix in place for this. Thanks as always for your help!!

#21

You might be able to fetch the certificates in the basic script rather then read it locally. I am not sure how the certificate would have to be hosted and if this could be introducing a risk for the certificates. I am reaching out to a colleague to see if he has any suggestion.

Regards,
Deryck

#23

Topic closed due to inactivity.