MQTT connection to PubSub+ cloud

Ivan Pajuelo

I have a working Solace instance running in Docker and I can connect using MQTT.
Recently I configured a cloud service and I get NOT_AUTHORIZED when I try to connect to the MQTT service.
The host, username and password are OK. I tried with wrong ones and then I get different errors (BAD_USER_NAME_OR_PASSWORD and "Name or service not known").
I'm using mqtt-cli as a client.
The question is I checked all the pages in the cloud administration portal and I didn't find anything that prevents the user to connect.

Any suggestions?

amackenzie

I am glad you got this working, however, the reason it's working isn't exactly as you have stated.

All Solace Cloud instances are configured for secure ports via the appropriate ports. In this case, MQTT is configured for secure transport on port 8883 for SSL and 8443 for WSS (secure web sockets). There is no connectivity for unsecured transport on 1883. That is the reason you are getting NOT_AUTHORIZED on port 1883. It's not available.

The secure transport is signed by a server cert from a public CA (you can see it in the CA section of your Cloud service). On the client, mqtt-cli in your case, the cert is recognized as the Java installation on your client has these common public certs in the Java security trust store. This can be changed to use your own certs but by default, it just works.

To be clear, this is transport security NOT client authentication. Even when you are using SSL/TLS on 8883, it's still basic authentication for the client. Client certificate authentication is supported (as you have seen in your example) but it's not needed to get secure transport from client to server.

for example, I was successful installing mqtt-cli and connecting to Solace Cloud via this command line:
mqtt test -h <my-cloud-hostname> -p 8883 -s --user solace-cloud-client --password <mypassword>

No other configuration or certs were needed.

I hope this clears up the difference between transport security and client cert authentication.

Ivan Pajuelo

I found the problem but is not documented.
I can connect if I use the port 8883 through ssl (but without using any TLS certificate).
It seems like all MQTT connections to cloud are done using SSL. Now I'm going to configure a TLS connection to confirm TLS connections also work with port 8883.

mqtt test -h ******.messaging.solace.cloud -p 8883 -s -u solace-cloud-client -pw ********

amackenzie

In the connect tab on the service there are specifics for each protocol. Indeed port 8883 is used for ssl/tls. A certificate is used but you don't need to specify it with the mqtt-cli because it's a Java application and the cert being used is from a trusted CA with root certs already in your Java installation.

Ivan Pajuelo

Well.
I configured a TLS connection adding a CA to the broker, creating a client and uploading its certificate.
Then I can establish a TLS connection with the broker using the same port.
So, Solace cloud is using the same port for basic authentication and for TLS.
I don't know why solace cloud is returning NON_AUTHORIZED when I use port 1883 for basic authentication.
In on premise version I can connect with basic authentication using the port 1883 without problems.

Anyway there is no problem for me to use ssl always. In fact, all my connections will use TLS.

amackenzie

I am glad you got this working, however, the reason it's working isn't exactly as you have stated.

All Solace Cloud instances are configured for secure ports via the appropriate ports. In this case, MQTT is configured for secure transport on port 8883 for SSL and 8443 for WSS (secure web sockets). There is no connectivity for unsecured transport on 1883. That is the reason you are getting NOT_AUTHORIZED on port 1883. It's not available.

The secure transport is signed by a server cert from a public CA (you can see it in the CA section of your Cloud service). On the client, mqtt-cli in your case, the cert is recognized as the Java installation on your client has these common public certs in the Java security trust store. This can be changed to use your own certs but by default, it just works.

To be clear, this is transport security NOT client authentication. Even when you are using SSL/TLS on 8883, it's still basic authentication for the client. Client certificate authentication is supported (as you have seen in your example) but it's not needed to get secure transport from client to server.

for example, I was successful installing mqtt-cli and connecting to Solace Cloud via this command line:
mqtt test -h <my-cloud-hostname> -p 8883 -s --user solace-cloud-client --password <mypassword>

No other configuration or certs were needed.

I hope this clears up the difference between transport security and client cert authentication.

Ivan Pajuelo

I just used the port shown in the connect page

As you said, you can use port 8883 for basic authentication with no client cert authentication. I already did it before enabling cert authentication.
I only point out that the links on the service/connect page may lead to confusion.