TLS and authentication

MQTT packets carry no encryption of their own. Security comes from TLS on the transport plus authentication and authorization in the broker. MQTT 5.0 §5 (Security) describes this setup as guidance.

Threats and countermeasures

Threat	Countermeasure
Eavesdropping on or tampering with messages on the network	TLS encryption
Connecting to an impostor broker	Server certificate verification (trusted CA and host name)
Unauthorized clients connecting	Client certificates, user name and password, enhanced authentication
Connected clients using topics outside their scope	Topic permissions (ACLs) in the broker

TLS

With MQTT over TLS, the client completes a TLS handshake on the TCP connection before any MQTT packet flows. The standard port is 8883 (§4.2).

The client verifies the server certificate in this order:

1. The certificate chain leads to a certificate authority (CA) that the client trusts.
2. The subjectAltName of the certificate contains the host name or IP address the client connected to.
3. The certificate is within its validity period and allows server use (serverAuth in extendedKeyUsage).

If any check fails, the handshake doesn’t complete and the client never sends MQTT CONNECT. The client reports a TLS error, and the broker logs a TLS alert. TLS problems lists the actual messages.

Client authentication

Client certificates (mutual TLS)

The broker also requires a certificate from the client. The client certificate must come from a CA the broker trusts and include clientAuth in its extendedKeyUsage. Mosquitto requires it with require_certificate true, and use_identity_as_username true turns the certificate’s CN into the user name, so you can grant topic permissions per certificate.

User name and password

The client puts a User Name and a Password in CONNECT (§3.1.3.5, §3.1.3.6). They travel in clear text, so use them only over TLS.

Enhanced authentication

MQTT 5.0 supports challenge/response authentication with the AUTH packet and the Authentication Method and Authentication Data properties (§4.12). Mechanisms such as SCRAM are possible, but which ones a broker supports, and under what names, varies by broker.

Authorization

The broker decides which topics an authenticated client can publish and subscribe to. The MQTT standard doesn’t define a format for these rules.

The Mosquitto acl_file looks like this:

# Rules for anonymous clients (before any user line)
topic read opcua/uadp/data/#

# Rules for one user
user pdcomm-edge
topic write opcua/#

An MQTT 5.0 broker answers a denied publication with PUBACK reason code 0x87 (Not authorized). A broker can also accept a subscription and then withhold every message the client isn’t allowed to read.

Security and the PDComm simulator

The MQTT connection of the PDComm simulator uses plain TCP and has no fields for a user name, password or certificate. Where you need security, set it up like this:

1. Run a local broker on the simulator host or on a protected network, and open its plain listener on the loopback address only.
2. Let the local broker bridge to the remote broker over TLS. The bridge’s client certificate authenticates on the remote side.

The Connect through a TLS broker tutorial builds this setup step by step.

Caution

Make private key files readable only by the account that runs the broker (chmod 600). The tutorial CA is for testing; in production, use certificates issued under your organization’s PKI policy.