X509 Client Certificate Authentication - MQTT Security Fundamentals

Welcome to our MQTT Security Fundamentals series. In this blog, we will discuss how to add an additional layer of security to MQTT with X509 client certificates and find out the challenges of using this approach. In one of our previous posts, we looked at the basics of TLS and MQTT. If you’re not familiar with TLS, we recommend that you read that post first.

Recap of TLS and X509 Certificates

Previously, we talked about how MQTT can use TLS for transport encryption. In order to use TLS, the server needs a public/private key pair. When the TLS handshake takes place, clients need to validate the X509 certificate of the server (which includes the public key of the server) before a secure connection can be established.

What are X509 Client Certificates?

While it is sufficient that the server has a private / public key pair to establish a secure connection, clients can also have a unique public / private key pair which can be used in the TLS handshake. The client sends its certificate (which includes the public key of the client) as part of the TLS handshake after the server certificate is validated. The server is then able to verify the identity of the client and can abort the handshake if the verification of the client certificate fails. Essentially, this process authenticates the client before a secure connection is established.

What Added Security is Gained?

In contrast to using server certificates only, use of client certificates has the following advantages:

Verification of the identity of the MQTT clients.
Authentication of the MQTT clients at the transport level.
Lock out invalid MQTT clients before MQTT CONNECT messages are sent.

These advantages make it clear that X509 client certificates are a great idea for added security with MQTT. Only valid clients are allowed to establish a (secure) connection. This can save resources on the broker side, especially if costly MQTT authentication mechanisms such as database lookups or webservice calls are used on the broker side. Since the authentication takes place with the TLS handshake, authentication is done before a connection is established.

The Hard Problem: Provisioning and Revocation

While X509 client certificates give an additional layer of security, the extra security comes at a cost. MQTT client provisioning is more complex with client certificates and a certificate revocation mechanism is needed.

Provisioning Process

A difficult question with client certificates is:

“How do I securely deploy X509 client certificates to my MQTT clients?”

If you plan to use client certificates, it’s very important to define a provisioning process. If you can control all your MQTT clients and can provide the certificate (for example, as part of your device firmware update process), then X509 client certificates can be a good option. If the MQTT clients are not in your control (for example, the MQTT client is a mobile device that is unknown before connecting), then provisioning may be difficult or not possible at all.

Before you use client certificates, make sure you have a solid and secure certificate provisioning process.

If you deal with many MQTT clients, you also need to make sure that you have a way to manage the lifecycle of the client certificates. If you have already deployed a PKI (Public-Key-Infrastructure), this management should not be a problem. If you don’t have a PKI, managing thousands of client certificates can be difficult.

Certificate Revocation Lists (CRL)

If a client certificate can’t be trusted anymore (for example, if it was leaked), it’s important to invalidate the client certificate immediately. To prevent malicious clients from using the leaked certificate, the server needs a way to identify invalid certificates and prohibit clients that attempt to connect with them. One option is to use Certificate Revocation Lists (CRLs). CRLs are simply a list of all invalid certificates. If you only have a few certificates deployed to MQTT clients, CRLs are a good solution. If you deal with thousands or even millions of certificates, CRLs can be big headache.

OCSP

Another way to revoke invalid certificates is the Online Certificate Status Protocol (OCSP). OCSP uses a service to ask for revocation information on specific client certificates. If you plan to use OCSP, you need an OCSP responder, which is essentially a HTTP server that responds to revocation-check requests. If you have a huge number of revoked certificates, this method has the significant advantage that you don’t need to distribute the CRLs to the MQTT brokers. However, the setup of OCSP responders can be tricky.

If you want to learn more about OCSP, we recommend starting with the Wikipedia page about OCSP.

Using X509 Certificates for Application level Authentication and Authorization

When you use HiveMQ as your MQTT broker, you can also use X509 client certificates for application-level authentication and authorization. While the client is permitted to establish a (secure) connection, you may want to use the client certificate for additional application logic. For example, it is possible to perform authorization based on the X509 certificate.

The following code snippet shows you how to add permission that is based on the certificate details:

@Override
    public List<MqttTopicPermission> getPermissionsForClient(final ClientData clientData) {

        final List<MqttTopicPermission> permissions = new ArrayList<MqttTopicPermission>();

        final X509Certificate certificate = (X509Certificate) clientData.getCertificate().get();

        if ("dc-square".equals(certificate.getIssuerDN().getName())) {
            log.info("Issuer was dc-square, client is allowed to use all topics with all permissions");
            permissions.add(new MqttTopicPermission("#", MqttTopicPermission.ALLOWED_QOS.ALL));
        }

        return permissions;
    }

You can find a full example plugin on Github.

Should I Use X509 Client Certificates with MQTT?

Yes, if you have a strategy to handle the challenges of certificate lifecycle management discussed above, you should use X509 client certificates with MQTT.

Because certificate lifecycle management can be tricky, the barrier to implementing X509 client certificates can be quite high. If you’re not worried about setting up an infrastructure for managing and provisioning with X509 client certificates, the added security is well worth the effort. In addition to application-based authentication, client-certificate authentication adds another layer of security. If many clients try to use your MQTT service, this type of authentication can save a lot of resources on the broker side since clients get disconnected before any MQTT communication takes place. Keep in mind that X509 client certificates are typically used if you control the whole MQTT system, from broker to clients. If you can’t control the provisioning of MQTT clients, it’s better to rely on other authentication mechanisms as described in our blogs discussing Authentication and Advanced Authentication.

Do watch our webinar discussing IoT security issues and how MQTT can actually mitigate security vulnerabilities in IoT and IIoT infrastructures.

Additional Reading

We hope you are enjoying our MQTT Security Fundamentals. Subscribe to our newsletter or RSS feed to get updates from HiveMQ.

HiveMQ Team

The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.