TLS Certificates for Server Authentication

AUTOSOL does not provide this information for use as a source of security advice or best practices. The use of these examples is done at your own discretion and risk and with agreement that you will be solely responsible for any damage to your computer system or loss of data that results from such activities.

Steps for Creating Certificates for Server Authentication

For this step, the server (the broker) authenticates to the client with a certificate before the TLS connection is established. The client does not authenticate to the broker with a certificate, but may do so through other means (password, etc.).

The outputs for this process are:

ca.key file - to be kept private to (this) system that generated it.
ca.pem file - public certificate authority (self signed) certificate, to be distributed.
server.key file - to be kept private to where the MQTT broker (the TLS server) resides.
server.pem file - public server certificate, to be distributed to the MQTT broker.

One or more server certificates can be created, one for each MQTT broker. The server certificate contains the IP or hostname of that server. During TLS session establishment, the TLS client (eACM-MQTT, Bridge, Edge Manager, etc.) will compare the IP or hostname that it is connecting to with the CN (Common Name) presented by the server certificate. If there is a match, the TLS client will attempt to connect to the server. If not, the TLS client will drop the connection and regard it as unverified and untrusted. You may choose to break this rule by unchecking the “Verify Certificate” box (not recommended).

Leaving the “Verify Certificate” box unchecked may expose your TLS client to Man-in-the-Middle attacks. You have an encrypted connection, but have not proven to whom you are connected.

The inputs for this process are:

Hostname or IP of your MQTT broker’s server, to be used in the CN of the server certificate
Password for ca.key (optional)
Password for server.key (optional)

The exact steps in this process can be varied according to your needs. What follows is an example.

Create the key pair (ca.key) used by your certificate authority. To protect it with a password (you will be prompted):

openssl genrsa -aes256 -out ca.key 2048

To create ca.key without a password:

openssl genrsa -out ca.key 2048

Create the self signed certificate authority certificate (ca.pem). If you used a password when creating ca.key, you will be prompted for it.

openssl req -new -x509 -days 3650 -extensions v3_ca -key ca.key -out ca.pem -subj "/C=US/ST=Texas/O=THIS_COMPANY INC/CN=John Smith/emailAddress=name@company.com" --outform PEM

Create the key pair (server.key) used by your broker.

It is important to note that this step can (and probably should) take place where broker is installed and kept private there.

To protect it with a password (you will be prompted):

To create server.key without a password:

Create the certificate signing request for the server (the broker), server.csr. If you created ca.key on a different machine, you will need to copy server.csr to that machine.

If you protected server.key with a password, you will be prompted.

In this example, you will need to substitute 255.255.255.255 with the IP or hostname of your broker’s server for TLS verification to work correctly.

The server certificate’s CN field should match the hostname or IP of the MQTT broker.

Create the server certificate (server.pem). The step must take place where you have your ca.key. The server.csr and ca.pem files are also required. If you used a password when creating your ca.key, you will be prompted for it.