by Ponlakshmi
One of the most important step in secure MQTT Broker implementation is making the communication layer secure between the MQTT Clients and the MQTT Server. Like all other secure communication, MQTT as well rely on SSL/TLS Certificate for securing the connection. The TLS / SSL Certificate association to the communication is both applicable to the TCP and the Websocket connection. The secure MQTT communication is represented by MQTTS for TCP and wss for the Websocket.
Our MQTT Broker (CrystalMQ) has multiple security layers built into it. In addition to the support for the MQTT TLS communication, multiple MQTT Authentication, Authorization of MQTT Topics at group and client level and secure IOT data storage to the backend database and queues were integrated into the product. As the framework has been built in a way that customers can build IoT Applications around it, we take MQTT Server Security seriously and have practiced it as a standard from design.
SSL certificates are files that has digital data of encryption key to encrypt data for security. Hence, You can use the certificates to make sure the data encryption in the tunnel cannot be tampered with. There is a need of a key for decoding the data at the other end. MQTT Broker provides an option to enable SSL/TLS mode of encrypted data transfer for enhanced security in the Communication layer. The Broker works with all standard SSL/TLS Certificates and can also run with self-signed certificates.
Certification Authority (CA) is an entity that stores all the public keys and verify them for all the third parties. There are many authorized digital certificate providers including digicert, verisign, GeoTrust, etc. These certification authorities provide the Root Certificate. These root certificates are provided using a unique domain name and the corresponding business details, including your location details. These certificates are time bound. The third party applications like Web Browser validate these certificates when the certificate is associated to the http server of the domain and provide warning if the certificate is not valid or expired. For the Self-Signed certificates, the Root Certificate is created by a company or a developer. The procedure to create the server-side and client-side certificates is the same for the CA cert and the self-signed.
The CA based certificate is recommended for the production environment. However in the MQTTs required the communication is more between the MQTT clients and the server. As the most of the MQTT deployment will be mostly private and isolated communication, you will be using the certificate handshake between the client and the server, there may not be much of difference between the certificates. However, if you have browser based WSS communication, you should consider signing up for a CA Certificate.
We have used the openssl and the ubuntu environment to demonstrate the creation of the TLS certificates. Refer here for the details of openssl installation on your Ubuntu.
The root certificate creation is applicable only for the self signed certificate and you will get this from the CA if you are purchasing one. The first step is creating the private key file. The following command helps in creating the private key file.
openssl genrsa -out root.key 2048
If you want to have your key file secure using a password, you can add -des3 argument to the command, so that the command prompts allows you to enter the password in a secure way. Make sure you keep the password secure and safe.
openssl genrsa -des3 -out root.key 2048
We have completed the creation of the key file - root.key in the current folder. Our next step is to generate Certificate signing request file using above generated RSA private Key. Besides that, it contains encrypted personal details of the Host (ie). country, state, organization, common Name, email address, and public key.
openssl req -new -x509 -key root.key -out root.csr
The above command execution will prompt for the following details.
Country Name :
State or Province Name :
Locality Name :
Organization Name :
Organizational Unit Name :
Common Name (e.g. server FQDN or YOUR name):
Email Address :
A challenge password :(optional)
An optional company name :(optional)
You have successfully created the CSR file for the signing process. You can use the two files (root.key and the root.csr) to sign and create the certificate.
openssl x509 -req -days 365 -sha1 -extensions v3_ca -signkey root.key -in root.csr -out root.crt
The above command creates the X509 based root certificate which is considered as CA Root Certificate The above command generates a root certificate root.crt which is valid for 365 days.
You have to create the server key file to start with the server side certificate generation. The server side certificate needs the root certificate to be provided as one of the parameter for generation.
openssl genrsa -out server.key 2048
Create a Server csr file that holds the complete server details of the host. This is the similar process to the root.csr creation. This command as well prompt for the company details. Please provide them similar to the data provided for the root certificate.
openssl req -new -out server.csr -key server.key
The next step is to create the Server certificate. The root certificate which you have created or the one acquired from the CA needs to be provided.
openssl x509 -req -in server.csr -CA root.crt -CAkeyroot.key -CAcreateserial -out server.crt
The procedure followed for the server certificate can be used to create the client certificates. Please use appropriate naming for the files and the appropriate data for the CSR files.
The above certificates are also valid for 365 days. Same Certificate Authority should be used for generating both the client and Server certificate.
The root certificate, server certificate, and server private key needs to be placed on the server side and the root certificate, client certificate and the client private key needs to be placed in the client side.
We can either have a common client certificate or an individual certificate for each client. You can issue a certificate to client using your own root.key and root.crt. MQTT Broker/MQTT Server verify the common name and the client IP during the connection process. If both are same, then only broker allows the client to connect otherwise reject the client’s connection request.
Follow the steps to deploy and run the MQTT Broker in a secure environment.
Follow the steps to deploy and run the MQTT Clients in a secure environment.
The SSL Certificate makefile can be used to generate the self singed certificate and deploy it on the MQTT Broker. While running the script, make sure the necessary information is provided during the prompt. CrystalMQ is designed for Enterprise grade MQTT security for secure communication on the on premise and the hosted MQTT Server instances.
Set up a Trusted IoT Environment!
Begin by deploying a Secure MQTT Broker at the core of your system