MQTT GUIDE
2 min readMQTT Client Certificate Authentication (X.509)
Client certificate authentication uses mutual TLS (mTLS): as well as the broker proving its identity, the client presents an X.509 certificate during the TLS handshake. The broker trusts it if it chains to a trusted CA and identifies the client from the certificate — so no password is ever sent.
Passwords can leak, be reused, or be hard to rotate across a big fleet. Client certificate authentication avoids them entirely: the client proves who it is with an X.509 certificate during the TLS handshake. It’s one of the authentication methods, and the strongest of the common ones.
How mutual TLS works
Ordinary (one-way) TLS has only the broker present a certificate. Mutual TLS adds a second step: the broker asks the client for its certificate too. The client sends its X.509 certificate, the broker checks it chains to a trusted CA, and identifies the client from a field in the certificate — typically the common name (CN). No password is ever exchanged.
Client certificates in TBMQ
TBMQ supports X.509 client certificate authentication over a mutual-TLS listener. It matches the certificate’s common name (CN) against stored credentials, either by exact value or a regular expression, so you can map a whole family of device certificates to one credential rule. See the X.509 authentication guide and MQTT over TLS for the underlying transport.
Frequently asked questions
What is mutual TLS (mTLS)?
A TLS handshake where both sides present a certificate. The broker proves its identity as usual, and the client also presents an X.509 certificate, so the handshake authenticates both ends at once instead of just encrypting the channel.
How does the broker identify a client from its certificate?
It verifies the certificate chains to a trusted certificate authority (CA), then reads an identifier from the certificate — commonly the common name (CN) — and matches it against its stored client credentials.
Is a password needed with client certificates?
No. The certificate is the credential. Because identity is established during the TLS handshake, no username or password is sent, which removes the risk of leaked or reused passwords.
What happens if the certificate is untrusted or expired?
The TLS handshake fails before any MQTT packet is exchanged, so the connection never reaches the broker’s MQTT layer. Expired, revoked, or untrusted-CA certificates are all rejected at the handshake.
When should I use client certificates over passwords?
When you provision devices with unique identities and want strong, per-device authentication without managing passwords — common in larger or higher-security fleets. It pairs naturally with a device-provisioning process that issues each device a certificate.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.