Hey everyone, we are trying to configure the MQTT Broker in SSL and here is the setup:
The broker is install in domain A on a Windows Server OS. The field unit will connect to that broker using a certificate signed from a CA in domain A.
We have another tool that need to connect to the broker that is installed in domain B using a certificate signed from a CA in domain B.
Using MQTT Explorer I am not able to get the server in domain B to connect to the broker.
I get an error like invalid certificate.
We tried to use a PFX made of a certificate signed with CA in domain B.
Requesting a cert with exportable key from the CA, the using OpenSSL, export key and cert then create the PFX.
On the broker side (domain A) we configured the CApath option but as we are on Windows, there is no rehash command so I had to find the hash using OpenSSL and rename the Root and sub file with that hash.
I do not want to into the technical side of things for now but is it doable? Having MQTT Explorer connecting to a broker in another domain using both different CA?
Thanks
Hi mathdesj,
thanks for your question. Let me sort out some basics about TLS/SSL connection configuration options in the Mosquitto broker. In general the config options for TLS/SSL split into different groups:
- Server Certificate: The config options to specify the server certificate. These are certfile and keyfile. Use these options to specify, which Server CERT to use. And both options have to be specified. The Server CERT will be used by the connecting clients to validate the servers identity. More precise they allow the client to make sure he is really connected to the real server and not to some malicious server of a hacker stealing his credentials.
- Client Certificates: These options are either cafile or capath. User one of these options to specify which way the Server should validate the client certificates. The option will only be effective, if require_certificate true is specified. Client certificates are used by the broker to validate the identity of the client. These options have no effect on the server CERT.
- General options: All other TLS/SSL options may effect the general handshake or CERTs.
The following description is about Server certificate as my understanding is you have a problem with the server certificate. For client certificate validation it should work to simply put both signing CAs into the capath of the broker (and create the required hash links).
In general: Any TLS/SSL server may have only a single certificate on a single listen port. There is no way to specify multiple different TLS/SSL certs for a single listen port. Using mechanisms like SNI it is possible to host multiple different webservers with different domain names on the same physical server and port.
In the Mosquitto Broker you can specify a single Server CERT for on listener only as the Mosquitto broker does not have a concept of virtual hostnames. Most times it’s best to use a server CERT, which roots back to a well known root CERT, which is available on each client (e.g. letsencrypt CERT). If you want to use a CERT signed by your own authority you need to configure the matching CA to be used in the client.
As you want to connect with different groups of clients, which cannot be configured to use the same CA for the connection you have different options you may use:
- You may use a server CERT, which is signed by the root CERT from domain A (or an intermediate CERT signed by the root CERT from domain A and cross signed by the root CERT (or an intermediate CERT) of domain B. This way the clients in domain A are able to validate the server CERT using the CA from domain A and clients in domain B may validate the CERT using the CA from domain B.
- You may define two different listen ports in the mosquitto.conf and specifiy the matching server CERT and key for each port. So you would end up with a port 1883 for clients from domain A and a port 1884 for clients from domain B.
- You may use a reverse proxy in front of the Mosquitto broker (e.g. haproxy) to perform the the TLS/SSL termination. As these reverse proxy support SNI you might then use two different hostnames to address the same broker using different server certs. Clients from domain A would address the broker as mqtt.domain-a and clients would address the broker as mqtt.domain-b. both domain names would resolve to the same IP and end up in the reverse proxy. But in this case you need to make sure your client implementation does support SNI in the TLS/SSL connection handshake. Most SSL implementation today do.
Hope this helps.