MQTT Security and Certificate Types Explained
Understand MQTT TLS, certificates, authentication, and the different ways an MQTT client can securely connect to a broker.
Connecting to an MQTT broker can look complicated when you see options such as TLS, CA Certificate, Client Certificate, Client Key, Username, and Password.
The good news is that each one has a specific purpose.
This guide explains the most common MQTT connection and security types in simple language, while keeping the technical details accurate.
The Three Questions Behind a Secure MQTT Connection
When a device or application connects to an MQTT broker, there are three different security questions:
- Is the connection encrypted?
- Am I really connected to the correct broker?
- Is this client allowed to connect?
Different MQTT configurations answer these questions in different ways.
For example:
TLS
↓
Encrypts the communication
and can verify the broker
Username + Password
↓
Authenticates the MQTT user
Client Certificate + Client Key
↓
Authenticates the client itself
These mechanisms can be used individually or together.
1. MQTT Without TLS
The simplest MQTT connection does not use TLS.
For example:
Host: 192.168.1.100
Port: 1883
TLS: Disabled
Username: katman
Password: katman
The connection looks like this:
MQTT Client
│
│ MQTT
│ Username + Password
▼
MQTT Broker
The broker may allow anonymous connections, or it may require a username and password.
Username and password without TLS
If the broker requires authentication, the client sends its MQTT credentials as part of the MQTT connection.
However, the connection itself is not encrypted.
This means someone who can observe the network traffic may be able to see sensitive information, including the credentials.
Therefore, username/password authentication does not replace encryption.
When is this useful?
An unencrypted MQTT connection can be reasonable for:
- Local testing
- Isolated networks
- Development environments
- Situations where another security layer already protects the network
For connections across an untrusted network, TLS is generally preferred.
2. TLS: Encrypting the MQTT Connection
TLS adds encryption to the connection.
Instead of:
Client ───────── MQTT ─────────> Broker
you get:
Client ═══════ encrypted ═══════> Broker
The commonly used MQTT TLS port is:
8883
although a broker can use another port.
TLS provides an encrypted connection and can also allow the client to verify the identity of the server.
This is important because encryption alone is not enough.
You also want to know:
"Am I really connecting to the MQTT broker I intended to connect to?"
That is where certificates come in.
3. What Is a Certificate?
A digital certificate is similar to a digital identity document.
It contains information about an identity and is digitally signed by a trusted authority.
For example, a server certificate can say:
This certificate belongs to this server.
A client certificate can similarly identify a client.
Certificates are normally used together with a Certificate Authority, commonly called a CA.
4. What Is a Certificate Authority (CA)?
A Certificate Authority (CA) is an entity that signs certificates.
Think of it like an authority that says:
"I trust this certificate."
For example:
CA
│
┌────────┴────────┐
│ │
▼ ▼
Server Certificate Client Certificate
In a public Internet application, certificates are often signed by well-known public Certificate Authorities.
For private MQTT installations, it is very common to create your own private CA.
For example, an industrial company might have:
Company MQTT CA
│
├── Broker Certificate
│
├── PLC Certificate
│
├── Gateway Certificate
│
└── Engineering PC Certificate
The CA certificate can be distributed to clients that need to trust this private MQTT infrastructure.
5. Server Certificate
The MQTT broker has its own certificate.
For example:
server.crt
The broker also has a private key:
server.key
Together they allow the broker to prove its identity during the TLS handshake.
The simplified process looks like this:
MQTT Client
│
│ "Who are you?"
▼
MQTT Broker
│
│ Server Certificate
▼
MQTT Client
│
│ "I trust the CA that signed this certificate."
▼
Secure TLS connection
The server's private key stays on the broker.
The server private key should never be given to MQTT clients.
6. What Is the Server CA Certificate?
In an MQTT client such as Katman MQTT Client, you may see a field called:
Server Certificate / CA
This is usually the CA certificate that the client uses to verify the broker's certificate.
For example:
ca.crt
The important distinction is:
CA certificate
↓
Used by the client to TRUST the server certificate
It is not the server's private key.
It is also not normally the same thing as the broker's server certificate.
A simplified certificate relationship looks like:
CA Certificate
│
│ signs
▼
Server Certificate
│
│ presented by
▼
MQTT Broker
The client has the CA certificate and uses it to verify the broker.
7. TLS + Username and Password
This is one of the most common MQTT security configurations.
The client uses:
TLS: Enabled
Server CA: ca.crt
Client Certificate: Not required
Client Key: Not required
Username: katman
Password: katman
The connection looks like:
TLS encryption
╔══════════════════════════╗
║ ║
Client ║ ║ Broker
║ MQTT username/pass ║
║ ║
╚══════════════════════════╝
There are now two different security mechanisms:
TLS
Protects the network connection and allows the client to verify the broker.
Username and password
Authenticates the MQTT user to the broker.
These mechanisms complement each other.
The password is transmitted through the encrypted TLS connection rather than being exposed as plain network traffic.
8. Mutual TLS (mTLS)
There is another option called mutual TLS, or mTLS.
Normal TLS usually authenticates the server to the client.
With mTLS, both sides authenticate each other.
Normal TLS:
Client ────────> Broker
verifies
server
mTLS:
Client ────────> Broker
verifies
server
Client <──────── Broker
verifies
client
This means the MQTT broker also requires the client to present a certificate.
9. Client Certificate
A client certificate might look like:
client.crt
It identifies the MQTT client.
The broker can verify that the certificate was signed by a CA that it trusts.
For example:
MQTT CA
│
│ signs
▼
Client Certificate
│
▼
MQTT Client
The client certificate by itself is not enough.
It is used together with the corresponding private key.
10. Client Private Key
The client also has a private key:
client.key
The private key proves that the client actually possesses the private key corresponding to the certificate.
Think of it this way:
client.crt
+
client.key
↓
Client identity
The certificate can be shared with the broker.
The private key must remain protected.
Never publish or commit a client private key to a public Git repository.
11. TLS + Client Certificate + Client Key
A pure mTLS connection can look like:
TLS: Enabled
Server CA: ca.crt
Client Certificate: client.crt
Client Key: client.key
Username: Not required
Password: Not required
The connection works approximately like this:
MQTT Broker
│
Server Certificate
│
▼
MQTT Client ──────── TLS handshake
│
│ Client Certificate
│ Client Key
▼
MQTT Broker verifies client
The broker checks that the client's certificate is trusted and that the client possesses the corresponding private key.
This is mutual TLS.
12. mTLS + Username and Password
You can also use both certificate authentication and MQTT username/password.
For example:
TLS: Enabled
Server CA: ca.crt
Client Certificate: client.crt
Client Key: client.key
Username: katman
Password: katman
This creates multiple authentication layers.
MQTT Broker
▲
│
Username + Password
│
▲
Client Certificate
│
▲
TLS connection
│
▲
MQTT Client
In this configuration:
- TLS encrypts the connection.
- The server certificate identifies the broker.
- The client certificate identifies the client.
- The client private key proves possession of the certificate's private key.
- Username/password provides an additional MQTT authentication mechanism.
Whether a broker requires both mechanisms depends on its configuration.
13. Understanding the Certificate Fields in Katman
When configuring a TLS connection in Katman MQTT Client, you may see three certificate-related fields:
Server CA
Example:
ca.crt
Used to verify the MQTT broker's certificate.
Client Certificate
Example:
client.crt
Used when the broker requires the client to authenticate using a certificate.
Client Key
Example:
client.key
The private key corresponding to the client certificate.
Which certificates do I need?
The following table summarizes the common configurations.
| Connection | Server CA | Client Certificate | Client Key | Username / Password |
|---|---|---|---|---|
| MQTT without TLS | No | No | No | Optional |
| TLS, server authentication | Yes | No | No | Optional |
| TLS + username/password | Yes | No | No | Yes |
| mTLS | Yes | Yes | Yes | Optional |
| mTLS + username/password | Yes | Yes | Yes | Yes |
The key point is that you do not normally need all three certificate files for every TLS connection.
14. What Happens When TLS Is Disabled?
When TLS is disabled:
TLS: Disabled
The certificate fields are not used.
The client can simply connect using:
Host
Port
Username
Password
For example:
Host: 192.168.1.100
Port: 1883
Username: katman
Password: katman
Whether username/password is required is determined by the MQTT broker configuration.
MQTT itself does not automatically require a username and password.
A broker can be configured to:
- Allow anonymous connections
- Require username/password
- Require certificate authentication
- Use other authentication mechanisms depending on the broker and deployment
15. Why Does TLS Usually Use Two Different Ports?
A common MQTT setup uses:
1883 → MQTT without TLS
8883 → MQTT with TLS
These are conventions, not strict requirements.
A broker can use other ports.
For example, you could have:
1883 → MQTT
8883 → TLS + username/password
8884 → mTLS + username/password
The port itself does not determine the security level.
The broker configuration listening on that port determines what authentication and encryption are required.
16. Certificate Verification and Hostnames
There is another important part of TLS: the server certificate must match the server you are connecting to.
For example, suppose the broker certificate was issued for:
mqtt.example.com
and you connect to:
mqtt.example.com
The certificate can match the hostname.
But if you connect to:
192.168.1.100
the certificate needs to contain that IP address in its Subject Alternative Name (SAN) if the client is performing IP-address verification.
This is why a certificate can be valid and trusted but still fail hostname verification.
For production deployments, certificates should be created with the correct DNS names and/or IP addresses that clients will actually use.
17. Self-Signed Certificates vs. CA-Signed Certificates
You may also encounter the term self-signed certificate.
A self-signed certificate is signed by itself rather than by a separate CA.
This can work for private testing, but the client needs a way to explicitly trust that certificate.
A private CA is often more convenient for larger private MQTT deployments because one CA can sign many certificates:
Private MQTT CA
│
├── Broker 1
├── Broker 2
├── Gateway 1
├── PLC 1
└── Engineering PC
If the CA is trusted, clients can verify certificates issued by that CA.
18. What Should You Use?
There is no single configuration that is correct for every MQTT deployment.
The appropriate configuration depends on your environment.
Local development
A simple MQTT connection may be sufficient:
MQTT
Port 1883
Username/password if required
TLS-protected MQTT
For a connection where network encryption and broker verification are required:
TLS
Server CA
Username/password
Certificate-based device authentication
For environments where individual devices need their own cryptographic identity:
TLS
Server CA
Client Certificate
Client Key
Stronger multi-layer authentication
You can combine certificate authentication with MQTT credentials:
TLS
Server CA
Client Certificate
Client Key
Username/password
This is particularly useful when an MQTT deployment needs both certificate-based device identity and an MQTT authentication layer.
19. A Simple Mental Model
If all of the terminology becomes confusing, remember these four questions:
Is the connection encrypted?
TLS
TLS → protects the communication
Can I verify the broker?
Server CA
Server CA → helps the client trust the broker
Can the broker verify my client?
Client Certificate + Client Key
Client Certificate + Client Key → identifies/authenticates the client
Does the broker require an MQTT account?
Username + Password
Username + Password → authenticates the MQTT user
Put together:
┌─────────────────────┐
│ MQTT Broker │
└──────────┬──────────┘
│
Server Certificate
│
▼
┌──────────────┐ TLS encryption ┌──────────────┐
│ MQTT Client │ ═══════════════════════════ │ Broker │
└──────┬───────┘ └──────────────┘
│
├── Server CA
│ └─ "I trust this broker."
│
├── Client Certificate
│ └─ "This is my identity."
│
├── Client Key
│ └─ "I own this certificate."
│
└── Username + Password
└─ "I am an authorized MQTT user."
Quick Reference
| Feature | Purpose |
|---|---|
| TLS | Encrypts the connection |
| Server Certificate | Identifies the MQTT broker |
| Server CA | Allows the client to verify/trust the broker certificate |
| Client Certificate | Identifies the MQTT client |
| Client Key | Proves possession of the client certificate's private key |
| Username | MQTT user identity |
| Password | MQTT user authentication |
| mTLS | TLS where both server and client authenticate each other |
The Most Important Thing to Remember
TLS and authentication are related, but they are not the same thing.
TLS primarily protects the communication and authenticates the server.
Username/password and client certificates are authentication mechanisms.
They can be used separately or together depending on how the MQTT broker is configured.
For example:
MQTT
↓
No encryption
MQTT + Username/Password
↓
Authentication, but no TLS encryption
MQTT + TLS + Server CA
↓
Encrypted connection + broker verification
MQTT + TLS + Server CA + Username/Password
↓
Encrypted connection + broker verification + MQTT authentication
MQTT + TLS + Server CA + Client Certificate + Client Key
↓
Encrypted connection + mutual certificate authentication
MQTT + TLS + Server CA + Client Certificate + Client Key
+ Username/Password
↓
Encrypted connection + mutual certificate authentication
+ MQTT username/password authentication
Understanding these combinations makes the TLS options in Katman MQTT Client much easier to configure correctly.