We want to use RabbitMQ over TLS for our mqtt messaging, so we did some testing and managed to get it working over port 8883 using this configuration guide and we need to connect on a url that starts with the protocol identifier mqtts://.

Our config looks more or less like this:

[{rabbit,        [
                  {ssl_options, [{cacertfile, "/path/to/tls/ca/cacert.pem"},
                                 {certfile,   "/path/to/tls/server/cert.pem"},
                                 {keyfile,    "/path/to/tls/server/key.pem"},
                                 {verify,     verify_peer},
                                 {fail_if_no_peer_cert, true}]}
 {rabbitmq_mqtt, [
                  {ssl_listeners,    [8883]}
                  {tcp_listeners,    []}

We disabled tcp_listeners completely by passing an empty array (otherwise the default value will be an array like [1883] (with default port 1883) and then connecting insecure directly over tcp will still be possible (read also this answer on stackoverflow for more details).

Now I ran into the following document on mqtts (mqtt-s) claiming that mqtts does not mean mqtt secure, but that it actually stands for MQTT sensory networks:

Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion.

Now I tried to read more on this topic, but the more I read the more confusing it gets. Some docs claim mqtt over tls should simply be done by only addressing another port and this will give "secure-mqtt":

Port 8883 is standardized for a secured MQTT connection. The standardized name at IANA is “secure-mqtt” and port 8883 is exclusively reserved for MQTT over TLS.*

Other docs claim we can connect using using different protocols among which there is tls://:

The URL can be on the following protocols: 'mqtt', 'mqtts', 'tcp', 'tls', 'ws', 'wss'. The URL can also be an object as returned by URL.parse(), in that case the two objects are merged, i.e. you can pass a single object with both the URL and the connect options.

My questions:

  • What is the preferred way of connecting a MQTT client to a broker if you want to force this client to use MQTT over TLS?
  • Is it true that mqtts:// does not mean secure MQTT (MQTT over SSL/TLS)? Or does it mean this only in case we use RabbitMQ as our MQTT broker? Or is this document above outdated and is mqtts a totally valid identifier to connect securely to the mqtt protocol (like http becomes https for the http protocol and ws becomes wss for the web sockets protocol).

We tried to connect to our RabbitMQ broker using mqtt:// on port 8883 but this definitely does not work.
It seems the only way to establish a secure connection to our broker seems to be by using the mqtts:// identifier.

  • Does this RabbitMQ setup guarantee us that clients can and will only connect over a secure (encrypted) connection?


Some testing shows that the MQTT service works also well when addressing port 8883 while using the tls:// identifier in our requests.

  • Excellent questions Wilt. Lets hope someone knows. I will reach out to someone who might. Sep 9, 2016 at 13:08
  • @JulianKnight Thanks! It seems there is not (yet) so much information available on MQTT over TLS
    – Wilt
    Sep 9, 2016 at 17:20
  • True sadly. IoT is still the wild west I'm afraid. In the meantime, you will need to keep your MQTT traffic off the Internet by segregating the network or using VPN tunnels. I reached out to Nick O'Leary from IBM to see if he wouldn't mind popping in to comment but I don't know if he is available at the moment. Nick is an MQTT expert. Also, do you have to use RabitMQ? Other brokers work well with TLS including Mosquitto and HiveMQ. Sep 9, 2016 at 18:32
  • @JulianKnight Good point, but we use RabbitMQ as a broker because it allows us to seamlessly interoperate between AMQP (over websockets) and MQTT messaging services (protocol mixing). This possibility makes RabbitMQ to a preferred service for our application. It is a strength of RabbitMQ which they also point out in their MQTT documentation.
    – Wilt
    Sep 9, 2016 at 20:33
  • OK, I get that though I think Hive is similar. Anyway it looks like you are right with using port 8883 & TLS. I guess you could always block 1883 using the machine firewall, that would fix it. Sep 9, 2016 at 23:00

1 Answer 1


You can also use ssl:// as the identifier in your connection request but you need to set protocol as TLS[specific versions if you are intended to block few, TLSV1, TLSV1_1, TLSV1_2 etc].

We used java clients which worked for us. If you are using GUI clients like MQTTBox, they use mqtts:// for TLS. I dont know if it works as you already aware what mqtts is!!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .