Tasmota MQTT TLS encrypts everything your device sends and receives, including the broker password, so you can safely connect plugs and relays to a broker on the internet. This guide explains which Tasmota builds actually include TLS, how the two TLS-related options work, and how to connect an ESP32 running Tasmota to a broker on port 8883 with proper certificate validation.
Why Plain MQTT Is Not Enough
On port 1883, MQTT travels as plain text. The CONNECT packet carries the username and password in clear, and every cmnd/.../POWER message can be read or replayed by anyone on the path. Inside a well-managed home network that risk is small. Once the broker is in the cloud, the path crosses your ISP and the public internet, and plain text is no longer acceptable.
TLS solves three problems at once: it encrypts the session, it proves to the device that it is talking to the real broker, and it protects the credentials. The MQTT security best practices guide covers the wider picture; this article focuses on getting Tasmota itself to do it.
Which Tasmota Builds Support MQTT TLS?
This is where most people get stuck. TLS needs memory and code space, so it is not compiled into every binary.
| Platform | Build | MQTT TLS |
|---|---|---|
| ESP32 | tasmota32 and its variants |
Included |
| ESP32 | tasmota32-zbbridge |
Included |
| ESP8266 | tasmota, tasmota-lite, tasmota-sensors and other standard builds |
Not included |
| ESP8266 | Self-compiled with USE_MQTT_TLS |
Possible, but tight on memory |
If your device is an ESP8266 plug, you have two options: compile your own build with #define USE_MQTT_TLS in user_config_override.h, or accept plain MQTT on a trusted local broker and keep the cloud side elsewhere. On ESP8266 the TLS handshake uses a large share of the available RAM, so features such as a big rules engine or many sensors may not fit alongside it. For new projects, choose ESP32 hardware.
To check what you are running, open the web UI and look at the footer or Information page, which shows the version and build name, for example 14.2.0(release-tasmota32).
Version matters for Let's Encrypt
Tasmota validates the broker's certificate against a small list of built-in root certificates rather than a full CA bundle. The Let's Encrypt root, ISRG Root X1, was added in Tasmota 13.4.1.2. Brokers such as broker.connectmq.com use Let's Encrypt certificates, so make sure the device runs a recent release; upgrade first if it is older.
The Two TLS Options Explained
Tasmota controls TLS with two SetOption commands:
SetOption103-1enables TLS for the MQTT connection,0disables it. It only has an effect on builds compiled with TLS.SetOption132- chooses how the server certificate is validated.0(the default) checks it against the built-in certificate authorities.1switches to fingerprint validation.
Leave SetOption132 at 0 for any broker with a publicly trusted certificate. Fingerprint validation pins one specific certificate, and Let's Encrypt certificates are renewed every few months, so a pinned fingerprint will break on the next renewal unless you keep updating it.
Step 1: Test Tasmota MQTT TLS on the Public Broker
The public MQTT test broker at broker.connectmq.com accepts anonymous TLS connections on port 8883 with any unique client ID. Pick a random prefix such as q8v3mz and enter this in the Tasmota console:
Backlog SetOption103 1; SetOption132 0; MqttHost broker.connectmq.com; MqttPort 8883; MqttClient tasmota-q8v3mz; MqttUser 0; MqttPassword 0; Topic relay1; FullTopic connectmq/demo/q8v3mz/%prefix%/%topic%/
The device restarts. Watch the console: a successful connection logs a message that TLS is connected followed by MQT: Connected. The first handshake can take a second or two on an ESP32; that is normal.
Verify from a computer:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i watch-q8v3mz -t 'connectmq/demo/q8v3mz/#' -v
You should see tele/relay1/LWT Online and the INFO and STATE messages. Send a command over TLS:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i send-q8v3mz -t 'connectmq/demo/q8v3mz/cmnd/relay1/POWER' -m 'TOGGLE'
Remember that the public area is readable by everyone even over TLS. TLS protects the transport, not access to the topic. Do not leave a device that controls anything important on public topics.
Step 2: Connect to Your Private Broker with Credentials
For production, create a private broker. In ConnectMQ you pick a plan, create a broker, and receive a username, password and client ID. The client ID is bound to those credentials, so enter it exactly:
Backlog SetOption103 1; MqttHost broker.connectmq.com; MqttPort 8883; MqttClient YOUR_CLIENT_ID; MqttUser YOUR_USERNAME; MqttPassword YOUR_PASSWORD; Topic relay1; FullTopic home/%prefix%/%topic%/
Use the host shown for your broker in the portal if it differs. After the restart, open the portal's live topic explorer; home/tele/relay1/LWT with the retained value Online confirms that the device is connected through TLS with its own identity.
You can confirm the active settings at any time with Status 6, which prints the MQTT host, port, client and user (the password is never shown).
Step 3: Harden the Device
TLS on the MQTT link is only one layer. A few extra settings close the obvious gaps:
- Set a web admin password with
WebPassword <strong password>, otherwise anyone on your Wi-Fi can open the UI and read the MQTT settings. - Disable the web server entirely with
WebServer 0on devices you only control via MQTT. Re-enable it from MQTT later if needed. - Use one credential set per device. If a plug is lost or compromised, you revoke one set without touching the others.
- Keep firmware current. TLS root lists and security fixes arrive with new releases. Tasmota can upgrade over MQTT with
Upgrade 1. - Do not disable validation. Fingerprints of all
FFor other "accept anything" workarounds remove the authentication half of TLS.
Troubleshooting Tasmota MQTT TLS
| Symptom | Likely cause | What to do |
|---|---|---|
SetOption103 has no effect |
Build without TLS | Flash a tasmota32 build or self-compile with USE_MQTT_TLS |
| TLS handshake fails, certificate error | Firmware older than 13.4.1.2 lacks ISRG Root X1 | Upgrade Tasmota |
| TLS fails right after boot, works later | Clock not yet set | Ensure NTP works; certificate checks need the correct time |
| Connects on 1883 but not 8883 | Port blocked on guest Wi-Fi or by a firewall | Test from another network |
| Device reboots during handshake (ESP8266) | Out of memory | Remove drivers, use ESP32 |
rc 5 not authorised |
Credential or client ID mismatch | Re-copy the values from the portal |
If you are building custom firmware instead of using Tasmota, the same TLS principles apply in Arduino code; see the ESP32 MQTT tutorial for a WiFiClientSecure example. The general Tasmota configuration flow, including topics and full topics, is in the Tasmota MQTT setup guide. The official reference for every option lives in the Tasmota TLS documentation.
A Cloud Broker That Speaks TLS by Default
A self-hosted broker with TLS means buying or renewing certificates, configuring listeners and patching the server. A fully managed MQTT service like ConnectMQ offers TLS on 8883 and secure WebSocket on 8084 with a Let's Encrypt certificate already in place, plus IP blocking after repeated failed logins. That lets a few ESP32 relays at home or across several sites share one secure broker. For the bigger picture of where these devices fit, see the IoT automation guide.
Secure Your Tasmota Devices with ConnectMQ
Create a free Serverless broker at app.connectmq.com, no credit card required. Paste the generated credentials into the console command above, turn on SetOption103, and your Tasmota devices are connected over TLS in minutes.
Frequently Asked Questions
Does Tasmota support MQTT over TLS?
Yes, on ESP32 tasmota32 builds out of the box. Standard ESP8266 builds do not include TLS; you need a custom build with USE_MQTT_TLS.
What does SetOption103 do in Tasmota?
SetOption103 1 enables TLS for the MQTT connection on builds that include TLS support. Combine it with MqttPort 8883.
Should I use fingerprint validation or CA validation?
Use CA validation (SetOption132 0) for brokers with publicly trusted certificates such as Let's Encrypt. Fingerprints break whenever the certificate is renewed.
Why does my Tasmota TLS connection fail with an old firmware?
Older releases do not include the ISRG Root X1 certificate used by Let's Encrypt, so validation fails. Upgrading to Tasmota 13.4.1.2 or later fixes it.
