MQTT Security Fundamentals: X509 Client Certificate Authentication


Welcome to the sixth part of the MQTT Security Fundamentals series. The topic for today’s MQTT Monday blog post is X509 client certificates. You will learn how X509 client certificates can be used with MQTT for an additional layer of security and you will learn about the challenges when using this approach. We looked at the basics of TLS and MQTT in the last blog post, so we recommend to read it first if you are not familiar with TLS.

Recap of TLS and X509 certificates

We have learned in the last blog post that 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 also contains 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. So essentially this allows to authenticate the client before a secure connection is established.

Which added security can be gained?

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

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

These advantages make it clear, that it’s a great idea to use X509 client certificates for added security when using 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 (like database lookups or webservice calls) are used on the broker side. Since the authentication takes place in the TLS handshake, the authentication is done before a connection is established.

The hard problem: Provisioning and revocation

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

Provisioning process

The hard question when using client certificates is “How to securely deploy X509 client certificates to my MQTT clients?”. So 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 e.g. as part of your device firmware update process, then using X509 client certificates can be a good option. If the MQTT clients are not in your control (e.g. if your MQTT client is a mobile device you don’t know beforehand), then you may be out of luck, since provisioning can be very hard.

So before using client certificates, make sure you have a solid and secure certificate provisioning process.

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

Certificate Revocation Lists (CRL)

If a client certificate can’t be trusted anymore (e.g. if it was leaked), then it’s important to invalidate the client certificate. In case the certificate was leaked and malicious clients are using the certificate, then the server needs a way to identify the invalid certificate and prohibit clients connecting with that certificate. One option is to use Certificate Revocation Lists (CRLs). CRLs are simply said a list of all invalid certificates. CRLs are a good way if you have only a few certificates deployed to MQTT clients but can be big headache if you are dealing with thousands or hundreds of thousands of certificates.


Another possibility to revoke invalid certificates is Online Certificate Status Protocol (OCSP). OCSP uses a service for asking for revocation information for specific client certificates. If you plan to use OCSP, you need an OCSP responder, which is essentially a HTTP server which responds to revocation-check requests. This has an significant advantage, if you have a huge amount of certificates which are revoked, since you don’t have to distribute the CRLs to the MQTT brokers. OCSP responders can be tricky to setup, though.

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

Using X509 certificates for application level authentication and authorization

When using 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. You can e.g. perform authorization based on the X509 certificate. The following code snippet shows how to add permission based on certificate details:

You can find a full example plugin on Github.

Should I use X509 client certificates with MQTT?

Yes, you should use X509 client certificates with MQTT if you have a strategy for dealing with the challenges in certificate lifecycle management discussed above. We have seen that the barrier to implement X509 client certificates can be quite high, based on the fact that the certificate lifecycle management can be tricky. If you are not scared to setup a infrastructure for dealing and provisioning with X509 client certificates, the added security is worth using X509 client certificates. In addition to application-based authentication, client certificate authentication gives another layer of security and it can save a lot of ressources on the broker side if you are dealing with many clients which are trying to use your MQTT service since the clients get disconnected before any MQTT communication ever 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 to get notified as soon as we publish the next post, you can subscribe to our newsletter or RSS feed. You think we have missed some important information? Please tell us, we are always open to questions and suggestions.


  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 *