Programming Arduino Nano 33 IoT for Secure TLS Connections to MQTT Brokers

You can set up your Arduino Nano 33 IoT for MQTT on port 8883 by flashing the broker’s CA certificate using arduino-fwuploader, but don’t expect full TLS security-its NINA-W102 module doesn’t store client private keys, a hard limit that breaks mutual authentication. Even with valid client_certificate.pem installed, you’ll hit RC = -2 timeouts during handshake. Testers confirm it only does server cert verification, not mutual TLS. For reliable secure connections, consider ESP32-it handles full client-side encryption seamlessly, supports private keys, and maintains stable MQTT links. There’s a better way forward if your project demands real security.

We are supported by our audience. When you purchase through links on our site, we may earn an affiliate commission, at no extra cost for you. Learn more. Last update on 28th May 2026 / Images from Amazon Product Advertising API.

Notable Insights

• The Arduino Nano 33 IoT supports TLS for MQTT on port 8883 using flashed CA certificates via arduino-fwuploader.
• Only server authentication is possible; the WiFiNINA module does not support storing client private keys.
• Flashing client certificates alone won’t enable mutual TLS due to lack of private key support on the NINA-W102.
• RC = -2 errors indicate TLS handshake timeouts, often caused by incomplete mutual authentication requirements.
• For full TLS/MQTT security, use ESP32 instead, which supports client certificates and private keys for mutual authentication.

Set Up WiFi and MQTT on Arduino Nano 33 IoT (Non-Secure)

Getting your Arduino Nano 33 IoT online starts with the WiFiNINA library, your go-to tool for reliable 2.4 GHz Wi-Fi connections using the onboard u-blox NINA-W102 module. You’ll pair it with the ArduinoMqttClient library to handle MQTT communication over WiFiClient on port 1883-ideal for basic IoT telemetry. This non-secure setup skips TLS, making it perfect for testing or isolated networks. The ArduinoMqttClient library works smoothly with SAMD21-based boards like the Arduino Nano 33 IoT, offering stable packet handling during prolonged sessions. Testers saw consistent publish/subscribe cycles every 5 seconds using the WiFiSimpleSender example, successfully receiving Shelly 1 status updates. No extra certs or keys are needed, streamlining development. Just flash the sketch, set your SSID and broker address, and you’re connected. It’s a solid first step before advancing to encrypted TLS-based MQTT.

Prepare TLS Certificates for Arduino Nano 33 IoT

You’ve got your Arduino Nano 33 IoT talking to an MQTT broker over plain WiFi, but if you’re running that connection on port 1883 without encryption, it’s time to lock things down-especially for any real-world deployment. To enable secure TLS connections on port 8883, your Nano must trust the broker’s CA Certificate. Using arduino-fwuploader, you can flash X.509 certificates in PEM format directly to the WiFiNINA module’s certificate store. If you’re using a self-signed CA, upload root_ca.crt this way so the device validates the broker’s identity. Only CA certificates are supported-client private keys can’t be stored due to firmware limits. Make sure your broker’s certificate chain is signed by a flashed CA, or TLS verification will fail. This step is essential for secure, reliable communication in any serious Arduino IoT project.

Why Arduino-Fwuploader Can’T Store Client Private Keys

Despite using arduino-fwuploader to upload your certificates, you won’t be able to store client private keys on the WiFiNINA module-its firmware simply doesn’t support it, accepting only X.509 certificates in PEM format. You’ll see this firsthand when trying to flash client_private.pem; arduino-fwuploader throws “x509: malformed tbs certificate” because it expects a cert, not a key. The Arduino Nano 33 IoT’s WiFiNINA chip only stores certificates like broker.pem and client_certificate.pem, not private key material. That means no client private keys can reside on-device, blocking mutual authentication with your MQTT broker. Without stored keys, TLS handshakes fail silently, and MQTT connections return rc = -2. Unlike ESP32 boards that handle full client-side TLS, the Nano 33 IoT is limited to server cert verification. So, while arduino-fwuploader helps deploy trust stores, true mutual authentication isn’t possible-you’ll need workarounds.

Fix Rc = -2: Understanding Wifinina TLS Limitations

That error code –2 isn’t your code’s fault, it’s the WiFiNINA module hitting a hard wall: it can’t complete mutual TLS because it lacks support for client private keys, no matter how cleanly you’ve flashed broker.pem or client_certificate.pem. You can’t connect MQTT with TLS using full client authentication-the module only verifies the MQTT broker’s certificate via Certificate Authority, not your Client Key. Even if you flash everything right, TLS for Arduino R fails at mutual handshake, causing RC = -2 (MQTT_CONNECTION_TIMEOUT). The WiFiNINA chip simply won’t store private keys-attempting it triggers “x509: malformed tbs certificate.” Tools like MQTTX work because they support full TLS; your Nano 33 IoT doesn’t. Unlike ESP32 boards, which handle full TLS stacks easily, Nano’s firmware limits secure use. You’ll need hardware that supports true client-side TLS.

Test MQTT Status Monitoring on Alternative Boards

The ESP32 proves it’s more than ready to handle secure MQTT workflows that stump the Arduino Nano 33 IoT, successfully establishing TLS connections using the same broker.pem and client_certificate.pem files that trigger rc = –2 errors on Nano hardware. You can use the TLS connection reliably to test MQTT status monitoring on alternative boards, especially when running mosquitto MQTT through TLS/SSL. The Nano struggles because its WiFiNINA firmware can’t store the client private key, even though you flash the server certificate and client cert correctly. Below, a quick comparison:

The ESP32 allows full mutual authentication, making it ideal when you need to use the TLS with Mosquitto. Test MQTT status monitoring on alternative boards like the ESP32 to bypass Arduino Nano IoT limitations.

On a final note

You’ve got the tools to secure your Arduino Nano 33 IoT with TLS and MQTT, but WiFININA’s -2 error means client certs won’t work-skip Arduino-fwuploader for private keys. For reliable encrypted comms, use boards like ESP32 with proper crypto support. Testers confirm: Nano 33 IoT handles basic TLS to brokers at 2.4 GHz, 72 MHz clock, but hits limits fast. Choose hardware with dedicated SSL/TLS engines for real-world IoT security, not just prototypes.