Android Question [solved] SSL/TLS connection to remore MQTT broker

[udg]

Hi all,

I modified a running B4J MQTT client, substituting "ssl://<server IP:server port>" to original "tcp://<cloudmqtt_server port>" in order to test an SSL connection to a just setup VPS server of mine.

I get the following error.

Error connecting: (SunCertPathBuilderException) sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I followed the "recipe" found here to setup my Mosquitto TLS installation and opened the appropriate port on the server.
It looks something easy to fix, but where have I to look? TIA

 

[Erel]

Are you using an authorized certificate?

 

[udg]

No, it's a self-signed one generated following the documentation whose link is in my post #1.

 

[Erel]

It will not work. Install a recognized certificate. There are free ones available now.

 

[DonManfred]

For example: https://letsencrypt.org/

 

[udg]

Yes, I know about "Let's encrypt" certificates.
Reading some threads I was under the impression that only the jBroker wasn't able to use self-signed certificates, while JMQTT client could use any. Am I wrong?
Searching the Internet I found suggested solutions to the above error where they fundamentally update local JVM certificate cache or something like that. Obviously that won't be an option when others have to connect to my server since I can't pretend thay modify their setup.

Anyway, let's go the let's encrypt way..

 

[Erel]

A client should never accept an unrecognized certificate by default. There are implementations that allow you to disable the verification (WebSocketClient and OkHttp for example). This is not the case with jMQTT.

 

[DonManfred]

Lets encryt uses the ACME protocol to automate the process. You can find a java ACME client here: https://github.com/shred/acme4j
Should be easy to setup a B4J app to create a certificate for you based on this. I guess. I just googled a bit

Using a Trusted license does make it easier on the Client-setup. Nothing special to do.

 

[udg]

A client should never accept an unrecognized certificate by default.

Ok. So it's a security measure that jMQTT enforces while OkHtpp allow us to loose if needed.

@DonManfred : thank you Don. I'll experiment a bit after my lunch and a short walk

 

[Erel]

while OkHtpp allow us to loose if needed.

Yes. Only if you initialize it with InitializeAcceptAll.

 

[udg]

Hi all.
I'm posting just to confirm that using an LE (let's encrypt) certificate works fine.
I used the certbot command along with the DNS challenge because I found it easier to do that way, but any other LE method should work.
Once the certificate is issued and ackowledged it's a matter of changing a couple of lines in the mosquitto.conf file and start the service.

B4J side..well, just use "ssl:<your ip:your port>" or "ssl:<your domain:your port>" and enjoy. Could it be any easier?

 

[LucaMs]

B4J side..well, just use "ssl:<your ip:your port>" or "ssl:<your domain:your port>" and enjoy.

I would need more details, as if I use the jetty tool to create the certificate the server address must be an URL, you can not use an IP (and I think this is absolute, not just for Jetty).

[if you open a thread even in the Italian forum it is possible that I understand better]

 

[udg]

@LucaMs :It will be a pleasure to give you more details in Italian.
Anyway, my use of the LE certificate is for a mosquitto MQTT broker, so in its configuration file I simply link to the dir where LE put its files. Entering IPort calls my server (IP) and the service (mosquitto) listening on that port. Entering URLort makes the calling party to first lookup in a DNS server where URL is translated to the corersponding server IP, then everything goes as before.