As a security protocol based on modern cryptographic public key algorithms, TLS/SSL can ensure the security of transmission in the computer communication network. EMQ X has built-in support for TLS/SSL including one-way/two-ways authentication, the X.509 certificate, load balance SSL and many other security certifications. You can enable SSL/TLS for all protocols supported by EMQ X, and can also configure HTTP API provided by EMQ X to use TLS.
In the previous article, we've introduced how to enable SSL/TLS one-way security connection for the EMQ X. This article will introduce how to enable SSL/TLS two-way security connection for MQTT in EMQ X.
The process of communication in the TLS/SSL protocol consists of two parts. The first part is the handshake protocol. The purpose of this handshake protocol is to identify the identity of another party and establish a safe communication channel. After a handshake, both parties will negotiate the next password suite and session key. The second part is the record protocol. Record is highly similar to other data transmission protocols. It carries content type, version, length, load, etc, and the difference is that the information carried by this protocol is encrypted.
The following picture describes the process of the TLS/SSL handshake protocol. From "hello" of the client until "finished" of the broker. If you are interested in this, you can view more detailed material. Even if you do not know this process, you can also enable this function in EMQ X.
The two-way certification is that a certificate is required for service and client during the connection authentication. Both parties need to perform authentication for ensuring that both sides involved in communication are trusted. Both parties share their public certificates, and then perform verification and confirmation based on the certificate. For some application scenarios that required high security, we need to enable two-way SSL/TLS authentication.
In the two-way certification, we generally use the way self-signed to generate the certificate of the server and client, so this article will take the self-signed certificate as an example.
Generally speaking, we need a digital certificate to ensure the strong certification of TLS communication. The use of digital certificates is a three-party protocol. In addition to the communicating parties, there is a trusted third party to issue the certificate. Sometimes, this trusted third party is a CA. Communicating with CA is usually done by issuing certificates in advance. So, we need a CA’s certificate and an EMQ X’s certificate these two certificates at least, and the EMQ X’s certificate is issued by CA and uses the CA’s certificate for verification.
We assume that your system has installed OpenSSL. Using the toolkit included with OpenSSL can generate the certificate we needed.
First, we need a self-signed CA certificate. If you want to generate this certificate, you need a private key to sign it. You can execute the following command to generate this private key:
openssl genrsa -out ca.key 2048
This command will generate a key with a length of 2048 and will be stored in
ca.key. If you have this key, you can use it to generate the root certificate of EMQ X:
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.pem
The root certificate is the starting point of an entire chain of trust. If the issuer of each level of a certificate and the issuer of the root certificate is trusted, this certificate is trusted. We can use it to issue the certificate for EMQ X.
EMQ X also needs its private key to ensure control for its certificates. The process of generating this private key is similar to the above:
openssl genrsa -out emqx.key 2048
BROKER_ADDRESSto the real IP or DNS address of EMQ X broker such as IP.1 = 127.0.0.1 or DNS.1 = broker.xxx.com
[req] default_bits = 2048 distinguished_name = req_distinguished_name req_extensions = req_ext x509_extensions = v3_req prompt = no [req_distinguished_name] countryName = CN stateOrProvinceName = Zhejiang localityName = Hangzhou organizationName = EMQX commonName = CA [req_ext] subjectAltName = @alt_names [v3_req] subjectAltName = @alt_names [alt_names] IP.1 = BROKER_ADDRESS DNS.1 = BROKER_ADDRESS
Then, use this key and configuration to issue a certificate request:
openssl req -new -key ./emqx.key -config openssl.cnf -out emqx.csr
Then use the root certificate to issue the certificate of EMQ X:
openssl x509 -req -in ./emqx.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out emqx.pem -days 3650 -sha256 -extensions v3_req -extfile openssl.cnf
Two-way connection authentication also needs to create the certificate of client. First, we need to create client key:
openssl genrsa -out client.key 2048
Using the generated client key to create a client request file:
openssl req -new -key client.key -out client.csr -subj "/C=CN/ST=Zhejiang/L=Hangzhou/O=EMQX/CN=client"
Finally, we use the previously generated CA certificate to sign the client and generate a client certificate:
openssl x509 -req -days 3650 -in client.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out client.pem
After preparing the server and client certificate, we can enable TLS/SSL two-way authentication in the EMQ X.
In the EMQ X, the default listening port of
mqtt:ssl is 8883.
Copy the file
ca.pem generated by OpenSSL tool into the directory
etc/certs/ of EMQ X, and refer the following configuration to modify
## listener.ssl.$name is the IP address and port that the MQTT/SSL ## Value: IP:Port | Port listener.ssl.external = 8883 ## Path to the file containing the user's private PEM-encoded key. ## Value: File listener.ssl.external.keyfile = etc/certs/emqx.key ## NOTE: If emqx.pem is a certificate chain, please make sure the first certificate is the certificate for the server, but not a CA certificate. ## Path to a file containing the user certificate. ## Value: File listener.ssl.external.certfile = etc/certs/emqx.pem ## Note: ca.pem is to hold the server's intermediate and root CA certificates. Other trusted CAs can be appended for client certificate validation. ## Path to the file containing PEM-encoded CA certificates. The CA certificates ## Value: File listener.ssl.external.cacertfile = etc/certs/ca.pem ## A server only does x509-path validation in mode verify_peer, ## as it then sends a certificate request to the client (this ## message is not sent if the verify option is verify_none). ## ## Value: verify_peer | verify_none listener.ssl.external.verify = verify_peer
The requirement of MQTT X version: v1.3.2 or higher version
MQTT clientin the MQTT X (
127.0.0.1in the Host input box need to be replaced by the real IP of EMQ X broker)
At this time, you need to select
Self signed in the column
Certificate and carry the file
ca.pem generated in the self-signed certificate and the client certificate
client.pem and the client key
Connect, after the connection succeeds, if you can normally perform MQTT publish/subscribe operation, the configuration of SSL two-way connection authentication succeeds.
Finally, open the Dashboard of EMQ X. On the Listeners page, you can see that there is an
mqtt:ssl connection on port 8883.
So far, we successfully finished the SSL/TLS configuration of the EMQ X Broker and the test of a two-way authentication connection.
The message retention function of [EMQ X MQTT Broker](https://emqx.io) is implemented by the `emqx_retainer` plugin, which is enabled by default. By modifying the configuration of the` emqx_retainer` plugin, you can adjust the EMQ X Broker's retention message Location, restrict the number of retained messages and maximum payload length, and adjust the expiration time of retained messages.
In March, the focus of our work was on finalising 4.3 release as well as the design of EMQ X Broker 5.0
[MQTT X](https://mqttx.app) is a cross-platform MQTT 5.0 desktop test client provided by the world's leading open source IoT middleware provider [EMQ](https://emqx.io) , which supports macOS, Linux, Windows. The user interface of **MQTT X** simplifies the operation logic of the page with the pattern of chatting software. Users can quickly create multiple simultaneous-online MQTT clients to test the connection/publish/subscribe functions of MQTT/TCP, MQTT/TLS and other MQTT protocol features.