MQTT Security Fundamentals: X509 Client Certificate Authentication

mqttsecurityfundamentals_part6

Welcome to part six of MQTT Security Fundamentals. The topic of today’s MQTT Monday is X509 client certificates. Learn how to add an additional layer of security to MQTT with X509 client certificates and find out the challenges of using this approach. We looked at the basics of TLS and MQTT in last week’s post. 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:

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 this and this blog post.

We hope you enjoyed part six of the MQTT Security Fundamentals. If you want us to notify you as soon as we publish the next post, subscribe to our newsletter or RSS feed. As always, please feel free to use the comments area. We are happy to answer questions and receive suggestions.

3 comments

  1. Dan Simo says:

    X509 Client Certificate Authentication in C?? not in java

    1. Hi Mohammed,

      I’m not exactly sure what you mean with that comment. X509 client certificate authentication works with C and with Java (in fact it should work with any programming language). The X509 client certificate authentication happens on the transport layer. If you want to use the certificate information in the HiveMQ plugin system, you need to program in Java, though.

      Hope this helps,
      Dominik from the HiveMQ Team

  2. Liam says:

    One of the other possible solutions to using X509 certificates
    and solving the revocation list is to use a JWT token with expiration.

    This means that an MQTT client gets a token which is verified
    by the broker on a middleware level or Authentication endpoint.

    Although this is not supported by MQTT as standard
    and has to be a custom implementation.

    And should allow a much lighter easier and faster Authentication
    given that the broker support an Authentication Plugins.

Leave a Reply

Your email address will not be published. Required fields are marked *