MQTT mTLS: Mutual TLS mit X.509-Client-Zertifikaten erklärt

MQTT mTLS (Mutual TLS) authentifiziert beide Seiten einer Verbindung mit Zertifikaten: Der Broker weist dem Gerät seine Identität nach, und das Gerät weist dem Broker seine Identität mit einem eigenen X.509-Client-Zertifikat nach. Dieser Artikel erklärt, wie das funktioniert, zeigt ein vollständiges Mosquitto-Setup mit OpenSSL und hilft Ihnen bei der Entscheidung, ob mTLS seinen Betriebsaufwand wert ist oder ob Benutzername und Passwort über TLS für Ihre Flotte die bessere Wahl sind.

Server-TLS vs. Mutual TLS

Beim gewöhnlichen MQTT über TLS präsentiert nur der Broker ein Zertifikat. Der Client prüft es, der Tunnel wird verschlüsselt, und dann authentifiziert sich der Client innerhalb dieses Tunnels mit den Feldern für Benutzername und Passwort im MQTT-CONNECT-Paket. So arbeiten die meisten Cloud-Broker, und das wird in unserem Leitfaden zur MQTT-TLS-Konfiguration ausführlich erklärt.

Bei Mutual TLS sendet der Broker während des Handshakes zusätzlich einen CertificateRequest. Der Client antwortet mit seinem eigenen Zertifikat und signiert einen Teil des Handshakes mit dem zugehörigen privaten Schlüssel. Der Broker prüft, ob das Client-Zertifikat zu einer vertrauenswürdigen CA führt, innerhalb seines Gültigkeitszeitraums liegt und nicht widerrufen wurde. Schlägt eine Prüfung fehl, wird die TCP-Verbindung geschlossen, bevor auch nur ein MQTT-Paket verarbeitet wird.

Warum Teams sich für MQTT mTLS entscheiden

Das stärkste Argument für mTLS: Das Geräte-Geheimnis verlässt das Gerät nie. Ein Passwort wird bei jedem Verbindungsaufbau übertragen, sodass ein kompromittierter Broker, ein falsch konfiguriertes Log oder ein Debugging-Proxy es abgreifen kann. Ein privater Schlüssel erzeugt nur Signaturen. Liegt der Schlüssel in einem Secure Element wie einem ATECC608 oder einem TPM, kann ihn nicht einmal die Firmware auslesen, was das Klonen eines Geräts deutlich erschwert.

Weitere Vorteile:

• An Hardware gebundene Identität: Sie können Zertifikate im Werk ausstellen und den Common Name des Zertifikats an die Seriennummer koppeln.
• Frühe Abweisung: Nicht authentifizierte Clients werden verworfen, bevor der Broker MQTT parst, was die Angriffsfläche verringert.
• Standard-Tooling: X.509 wird von jeder TLS-Bibliothek, jedem Load Balancer und jedem Security-Team verstanden.

Die versteckten Kosten: der Zertifikats-Lebenszyklus

mTLS verlagert die Komplexität von der Benutzerdatenbank des Brokers in eine Public-Key-Infrastruktur. Bevor Sie es einführen, sollten Sie diese Aufgaben ehrlich einschätzen:

1. Eine CA betreiben: den Root-Schlüssel offline halten, für die Ausstellung eine Zwischen-CA nutzen und beide schützen.
2. Provisioning: auf jedem Gerät einen Schlüssel erzeugen (idealerweise auf dem Gerät selbst), einen CSR erstellen, ihn signieren und das Zertifikat installieren.
3. Erneuern: Zertifikate laufen ab. Geräte brauchen einen Weg, ein neues Zertifikat zu erhalten, bevor das alte erlischt, selbst wenn sie ein Jahr lang im Regal lagen.
4. Widerrufen: Wird ein Gerät gestohlen oder außer Betrieb genommen, muss der Broker sein Zertifikat ablehnen. Mosquitto unterstützt eine CRL-Datei; viele Teams setzen stattdessen auf kurze Zertifikatslaufzeiten.
5. Die CA rotieren: Irgendwann muss die ausstellende CA selbst ersetzt werden. Das bedeutet, einen neuen Vertrauensanker an den Broker und neue Zertifikate an jedes Gerät zu verteilen.

Geht dabei etwas schief, entstehen Ausfälle, die wie rätselhafte Handshake-Fehler in einem Teil der Flotte aussehen. Für die meisten kleinen und mittleren Projekte bieten eindeutige Zugangsdaten pro Gerät über TLS, regelmäßig rotiert, ein besseres Verhältnis von Sicherheit zu Aufwand. Unsere Leitfäden zur MQTT-Authentifizierung mit Benutzername und Passwort und zur Rotation von MQTT-Zugangsdaten zeigen, wie das gut gelingt.

MQTT mTLS auf Mosquitto einrichten

Das folgende Labor-Setup nutzt Eclipse Mosquitto, das die Authentifizierung per Client-Zertifikat nativ unterstützt. Führen Sie es auf einem Rechner aus, den Sie kontrollieren.

Schritt 1: Eine private CA erstellen

mkdir -p ~/mqtt-pki && cd ~/mqtt-pki

# CA-Schlüssel und selbstsigniertes CA-Zertifikat (10 Jahre)
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/CN=Lab MQTT Root CA" -out ca.crt

Schritt 2: Das Broker-Zertifikat ausstellen

Das Broker-Zertifikat braucht einen Subject Alternative Name, der zum Hostnamen passt, den die Clients verwenden.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=mqtt.lab.local" -out server.csr

cat > server.ext <<'EOF'
subjectAltName = DNS:mqtt.lab.local
extendedKeyUsage = serverAuth
EOF

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 825 -sha256 -extfile server.ext -out server.crt

Schritt 3: Ein Gerätezertifikat ausstellen

Verwenden Sie die Geräte-ID als Common Name. In der Produktion würde der Schlüssel auf dem Gerät erzeugt, und nur der CSR würde es verlassen.

openssl genrsa -out sensor-001.key 2048
openssl req -new -key sensor-001.key -subj "/CN=sensor-001" -out sensor-001.csr

cat > client.ext <<'EOF'
extendedKeyUsage = clientAuth
EOF

openssl x509 -req -in sensor-001.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 365 -sha256 -extfile client.ext -out sensor-001.crt

Schritt 4: Den Broker konfigurieren

# /etc/mosquitto/conf.d/mtls.conf
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

# Ein von cafile signiertes Client-Zertifikat verlangen
require_certificate true

# Den CN des Zertifikats als MQTT-Benutzernamen verwenden (für ACLs)
use_identity_as_username true

# Optional: widerrufene Zertifikate ablehnen
# crlfile /etc/mosquitto/certs/ca.crl

Kopieren Sie die Dateien nach /etc/mosquitto/certs/, machen Sie den Schlüssel für den mosquitto-Benutzer lesbar und starten Sie den Dienst neu. Mit use_identity_as_username wird der CN sensor-001 zum Benutzernamen, sodass Sie ACL-Regeln pro Gerät schreiben können.

Schritt 5: Mit dem Client-Zertifikat verbinden

mosquitto_sub -h mqtt.lab.local -p 8883 --cafile ca.crt \
  --cert sensor-001.crt --key sensor-001.key \
  -i sensor-001 -t "lab/sensor-001/#" -v

Dieselben drei Dateien funktionieren auch im Code. In Python mit paho-mqtt 2.x:

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="sensor-001")
client.tls_set(ca_certs="ca.crt", certfile="sensor-001.crt", keyfile="sensor-001.key")
client.connect("mqtt.lab.local", 8883)
client.publish("lab/sensor-001/temp", "21.4", qos=1)
client.loop(2)
client.disconnect()

Wenn Sie sich ohne --cert und --key verbinden, schlägt der Handshake sofort fehl. So bestätigen Sie schnell, dass require_certificate aktiv ist. Labor-Setups wie dieses nutzen eine selbstsignierte Root; unser Leitfaden zu selbstsignierten Zertifikaten für MQTT behandelt die Fallstricke.

Häufige mTLS-Fehler

• „certificate required“ oder ein Handshake-Alert vom Broker: Der Client hat kein Zertifikat gesendet. Prüfen Sie die Pfade zu Zertifikat und Schlüssel.
• „unknown ca“: Das Client-Zertifikat wurde von einer CA signiert, die nicht in der cafile des Brokers steht.
• „unsupported certificate purpose“: Dem Zertifikat fehlt die Extended Key Usage clientAuth.
• Schlüssel passt nicht: Die Schlüsseldatei gehört nicht zum Zertifikat. Vergleichen Sie openssl x509 -noout -modulus -in sensor-001.crt | openssl md5 mit demselben Befehl für den Schlüssel.
• Abgelaufenes Zertifikat: Prüfen Sie die Daten mit openssl x509 -noout -dates -in sensor-001.crt und kontrollieren Sie die Uhr des Geräts.

Wann mTLS sinnvoll ist und wann Zugangsdaten genügen

mTLS passt gut, wenn Sie den Broker selbst kontrollieren, eine hardwaregestützte Identität brauchen, in einem regulierten Umfeld arbeiten, das zertifikatsbasierte Geräteidentität vorschreibt, oder bereits eine PKI betreiben. Für Prototypen, kleine Flotten und Teams ohne Verantwortlichen für die Zertifikatserneuerung ist es meist überdimensioniert.

In der Industrieautomation ist das Zertifikatsmodell vielen Teams bereits vertraut: OPC UA authentifiziert Anwendungen mit X.509-Instanzzertifikaten, und Sicherheitskonzepte nach IEC 62443 legen Wert auf eindeutige, belastbare Geräteidentitäten. Wer im Werk ohnehin eine PKI für OPC UA betreibt, kann sie häufig auch für MQTT-Gateways nutzen. Ein Mittelständler ohne eigene PKI fährt dagegen mit Zugangsdaten pro Gerät über TLS oft besser.

ConnectMQ verfolgt den Ansatz „Zugangsdaten über TLS“: Der Broker präsentiert ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat, und jeder Client authentifiziert sich mit Benutzername, Passwort und Client ID, die im Portal generiert werden. Client IDs sind an die ausgestellten Zugangsdaten gebunden, und wiederholte fehlgeschlagene Logins führen zu IP-Sperren. ConnectMQ bietet keine Authentifizierung per Client-Zertifikat an. Wenn mTLS eine harte Anforderung ist, brauchen Sie einen Broker, den Sie selbst konfigurieren, etwa Mosquitto wie oben gezeigt. Für die Mehrheit der Projekte beseitigt ein verwalteter MQTT-Broker mit starken Zugangsdaten pro Gerät jedoch weit mehr Betriebsrisiko, als mTLS hinzufügt. Das Gesamtbild behandeln unsere Best Practices für MQTT-Sicherheit.

Starten Sie mit ConnectMQ

Wenn Zugangsdaten über TLS zu Ihrem Bedrohungsmodell passen, bietet Ihnen ConnectMQ einen abgesicherten Broker, ohne dass Sie eine PKI betreiben müssen. Registrieren Sie sich unter app.connectmq.com, wählen Sie den kostenlosen Serverless-Plan ohne Kreditkarte, erstellen Sie einen Broker und verbinden Sie sich auf Port 8883 mit den generierten Zugangsdaten. Sie können zunächst auf dem öffentlichen MQTT-Broker unter broker.connectmq.com mit Testdaten prototypen und beim Go-live auf private Zugangsdaten umsteigen.

Häufig gestellte Fragen

Ist mTLS sicherer als Benutzername und Passwort über TLS?

Es entfernt das gemeinsame Geheimnis aus der Übertragung und harmoniert gut mit hardwaregestützter Schlüsselspeicherung, daher widersteht es dem Diebstahl von Zugangsdaten besser. Der Preis dafür ist ein Zertifikats-Lebenszyklus, den Sie zuverlässig betreiben müssen.

Kann ich mTLS und Benutzername plus Passwort zusammen verwenden?

Ja. Mosquitto kann zum Beispiel ein Client-Zertifikat verlangen und trotzdem MQTT-Benutzername und -Passwort prüfen, was zwei unabhängige Faktoren ergibt.

Unterstützt ConnectMQ die Authentifizierung per Client-Zertifikat?

Nein. ConnectMQ authentifiziert Clients mit generiertem Benutzernamen, Passwort und Client ID, die über TLS übertragen werden. Nutzen Sie einen selbst betriebenen Broker, wenn Sie ausdrücklich mTLS benötigen.

Wie lange sollten Gerätezertifikate gültig sein?

Darauf gibt es keine pauschale Antwort. Kürzere Laufzeiten verringern die Abhängigkeit vom Widerruf, erfordern aber eine zuverlässige automatische Erneuerung; wählen Sie den kürzesten Zeitraum, den Ihr Erneuerungsprozess bewältigt, ohne dass Zertifikate im Feld ablaufen.