Client Certificates
Learn how to secure MQTT connections with client certificates via mTLS.
Last updated
Was this helpful?
Learn how to secure MQTT connections with client certificates via mTLS.
Last updated
Was this helpful?
Mutual Transport Layer Security (mTLS) with client certificates provides enhanced security for MQTT connections to Connectware by eliminating the need for traditional username/password authentication. This approach uses X.509 client certificates for public-key authentication, reducing security risks during the authentication process.
Connectware uses a truststore file (cybus_ca.crt
) to determine which Certificate Authorities (CAs) it trusts for mTLS authentication.
To access MQTT using mTLS with Connectware, the following steps are required:
Prepare Connectware for mTLS by configuring the necessary settings.
Create Certificate Signing Requests (CSR) and obtain signed client certificates using a custom CA certificate chain.
Create a Connectware user with role-based permissions and assign the appropriate permissions to the client.
Learn More About
Connectware provides the following authentication methods for the message broker:
Default authentication: Utilizes username and password credentials. This method is compatible with:
Unencrypted connections over port 1883
Encrypted connections over port 8883 (TLS)
Alternative authentication: Certificate-based mutual TLS authentication (mTLS)
Once mTLS is enabled, the following changes take effect:
All MQTTS connections on port 8883 must present valid client certificates.
Connectware will extract the certificate's Common Name (CN) for user identification.
The extracted CN must match an existing Connectware user configured for certificate-based authentication (grant type).
A connection will only be established if both the certificate is validated and the associated user is successfully authenticated.
We recommend implementing your own Public Key Infrastructure (PKI) to issue and manage client certificates for Connectware authentication.
Prerequisites
Access to your organization's Certificate Authority (CA) infrastructure
The ability to sign certificate requests with your CA or Intermediate CA
Basic understanding of OpenSSL commands
Procedure
To generate the CSR, proceed as follows:
Generate a private key for your device:
Open the openssl-client-cert.conf
file and modify the following settings:
Create the CSR using your configuration and key:
You can also create both the private key and the CSR at the same time via -keyout
:
Verify your CSR:
The important fields to verify include:
A manual or automated process for signing certificates with a company Root CA or Intermediate CA is up to the customer.
In this tutorial, we assume the availability of a custom CA key-pair or a corresponding Intermediate CA key-pair eligible to sign certificate requests.
Create a CSR for the device that you want to connect to Connectware.
Sign the CSR with your custom CA:
This produces the signed certificate valid 100 days with the following output:
Inspect the signed certificate to verify its details. The output should confirm that the issuer matches your custom CA and that the subject corresponds to the device or machine identity you provided.
Result: Once properly configured, your custom-signed client certificates will function with Connectware without requiring container restarts.
To allow Connectware to authenticate clients using this certificate, the custom CA certificate (or full certificate chain) must be trusted by Connectware.
Add your CA chain to the Connectware truststore (cybus_ca.crt). You can retrieve this file from your Connectware instance and then add your custom CA:
To verify the trust chain locally before deploying:
Expected output:
After generating client certificates, you must configure Connectware to recognize and authorize connections using these certificates:
For certificate authentication to work, the Common Name (CN) in your client certificate must exactly match a username in Connectware that has been configured with the certificate grant type.
Create a user in Connectware with the same name as the CN in your client certificate:
Assign appropriate access roles to this certificate-authenticated user. For testing, you can use the connectware-admin
role. For production environments, follow the principle of least privilege with more restricted roles.
To find the correct connectware-admin
role ID for your environment, use the following GET request:
Result: Once properly configured, clients connecting via mTLS with a certificate containing CN=device001
will authenticate successfully, provided the certificate was signed by a CA in the trusted cybus_ca.crt chain.
Learn More About
To confirm that mTLS is configured correctly for Connectware, do the following:
In the Edit User dialog, enable Advanced Mode.
Enable Certificate and click Update.
Download the certificate files from the Connectware pod using kubectl. The following commands will extract the cybus_ca.crt
, cybus_client.crt
, and cybus_client.key
files from the /connectware_certs
directory in the system-control-server pod to your current local directory.
Use the cybus_client
key pair with CN=admin
.
Connect to an MQTT client on port 8883 using the CA file (cybus_ca.crt
) and the cybus_client
key pair.
Use an MQTT client like mosquitto_sub
to check for successful connection.
Successful connection
TLS handshake failure
Backend authorization failure
To revoke all client certificates issued by a particular custom CA, simply remove the custom CA entries from the cybus_ca.crt
file.
This will block further access from any certificate issued by that CA without needing to restart Connectware.
Apply the configuration by .
Download the openssl-client-cert.conf
sample file from .
Example: For testing purposes, you can use an example root CA configuration to generate a new self-signed root CA. Download the openssl-root-ca-example.conf
sample file from .
In the , select User > User Management, and select the admin user.
In the , select User > User Management, and select the admin user.
To extract the cybus_client.*
files, use the , which uses docker cp
to copy files from a running container.