MQTTS: MQTT über TLS für Energie-IoT

MQTTS bedeutet MQTT über Transport Layer Security (TLS). Es ist keine eigene MQTT-Version. Die MQTT-Pakete bleiben gleich; TLS umhüllt sie. Prüft der Client das Zertifikat, verschlüsselt TLS die Verbindung, erkennt Manipulationen und weist nach, welchen Broker der Client erreicht hat.

An einem Energiestandort sind drei Dinge getrennt zu prüfen: Das Gateway erreicht den richtigen Broker. Es darf nur in seine eigenen Topics veröffentlichen. Die Plattform speichert den richtigen Wert mit richtiger Einheit und Zeitmarke. Eine grüne Anzeige „Verbunden“ belegt nur die erste Hälfte der ersten Prüfung.

Verwechseln Sie MQTTS nicht mit MQTT-SN, das früher MQTT-S hieß. MQTT-SN ist ein eigenes Protokoll für Sensornetze und Übertragungswege ohne TCP/IP (MQTT-Spezifikationen).

MQTT und MQTTS im Überblick

Die MQTT-5.0-Spezifikation nennt die bei IANA registrierten TCP-Ports 8883 für MQTT über TLS und 1883 für unverschlüsseltes MQTT. Die Dienstnamen lauten secure-mqtt und mqtt. Der Port ist eine Konvention. Sicherheit entsteht durch TLS-Handshake und Zertifikatsprüfung; auch ein Listener auf Port 8883 kann falsch konfiguriert sein.

MQTT 5 definiert außerdem erweiterte Authentifizierung mit dem AUTH-Paket. Ob sie den Server nachweist, hängt vom Verfahren ab: Ein Challenge-Response-Verfahren wie SCRAM kann das, ein bloßes Token nicht. Nur wenige Broker implementieren dies. In fast jeder Installation beruht die Brokeridentität deshalb auf dem TLS-Zertifikat.

TLS-Versionen

Verwenden Sie TLS 1.2 oder 1.3. RFC 8996 hat TLS 1.0 und 1.1 im Jahr 2021 außer Gebrauch gesetzt. Mosquitto lässt TLS 1.3 und 1.2 standardmäßig zu (mosquitto.conf); AWS IoT Core akzeptiert dieselben Versionen. Ein auf TLS 1.0 festgelegter Client scheitert beim Handshake mit einer Protokollversionsmeldung. Das deutet meist auf alte Firmware statt auf ein fehlerhaftes Zertifikat.

Wo TLS endet

TLS schützt eine Verbindungsetappe: vom Client bis zu dem System, das TLS beendet. Beendet ein Cloud-Load-Balancer TLS und leitet unverschlüsseltes TCP an den Broker weiter, bleibt dieser innere Abschnitt ohne Verschlüsselung, sofern er nicht erneut verschlüsselt wird. Der Broker sieht auch das Clientzertifikat nicht mehr; zertifikatsbasierte ACLs funktionieren dann nicht. Klären Sie den TLS-Endpunkt, bevor Sie die Identität auf Clientzertifikate stützen. Muss der Inhalt über den Broker hinaus vertraulich bleiben, verschlüsseln Sie die Nutzdaten auf Anwendungsebene mit eigenen Schlüsseln. TLS auf jeder einzelnen Verbindungsetappe ist keine Ende-zu-Ende-Verschlüsselung.

Vier Sicherheitsprüfungen

1. Vertrauenskette und Brokeridentität

Der Client benötigt einen Vertrauensanker, meist das CA-Zertifikat, das das Brokerzertifikat signiert hat. Er prüft die Kette, die in RFC 5280 definierten Daten notBefore und notAfter sowie den Namen. RFC 9525 beschreibt den Vergleich der konfigurierten Referenzidentität, normalerweise des eingegebenen DNS-Namens, mit den Subject Alternative Names im Zertifikat.

Konfigurieren Sie den vollständigen Domainnamen des Brokers statt der IP-Adresse, zu der er an einem bestimmten Tag aufgelöst wurde. Ein Zertifikat für broker.example.net passt nicht zu 203.0.113.40. Senden Sie Server Name Indication (SNI), wenn der Dienst mehrere Namen unter einer Adresse betreibt. AWS IoT Core benötigt SNI für eigene Domains und konfigurierbare Endpunkte.

Vertrauen Sie der ausstellenden CA, statt das einzelne Brokerzertifikat fest zu hinterlegen. Eine solche Bindung an das Endzertifikat unterbricht die Gateway-Verbindung bei jeder Erneuerung.

2. Clientidentität

Geben Sie jedem Gateway eine eigene Identität: Clientzertifikat und privaten Schlüssel oder einen eigenen Benutzernamen mit Passwort. Verwenden Sie ein Zertifikat nie für eine ganze Flotte. Sein Widerruf für einen Standort würde sonst alle Standorte trennen.

In Mosquitto sind TLS-Listener und Pflicht zum Clientzertifikat getrennte Einstellungen. require_certificate true weist Clients ohne gültiges Zertifikat ab. use_identity_as_username true übernimmt den CN des Zertifikats als MQTT-Benutzernamen, den die ACL nutzen kann (mosquitto.conf):

listener 8883
cafile   /etc/mosquitto/ca/site-ca.crt
certfile /etc/mosquitto/certs/broker.example.net.crt
keyfile  /etc/mosquitto/certs/broker.example.net.key
require_certificate true
use_identity_as_username true
acl_file /etc/mosquitto/acl

Ab Mosquitto 2.0 werden bei konfiguriertem Listener anonyme Clients abgewiesen, sofern allow_anonymous true nicht ausdrücklich gesetzt ist.

3. Topic-Berechtigung

Authentifizierung klärt, wer der Client ist. Autorisierung klärt, wo er veröffentlichen und was er abonnieren darf. Geben Sie jedem Gateway nur seinen eigenen Topic-Zweig. Mit dem obigen Listener wird der CN des Gateway-Zertifikats in einem ACL-Muster zu %u:

pattern write sites/%u/telemetry/#
pattern read  sites/%u/commands/#

Gateway gw-0417 darf nun unter sites/gw-0417/telemetry/ veröffentlichen und sein eigenes Befehlstopic lesen. Es darf weder für einen anderen Standort noch in sein eigenes Befehlstopic schreiben. Das Dynamic-Security-Plugin von Mosquitto drückt dieselben Regeln als Rollen mit getrennten Rechten für Veröffentlichen, Empfangen und Abonnieren aus.

Testen Sie eine erlaubte und eine verweigerte Veröffentlichung. Die Protokollversion bestimmt, wie eine Verweigerung sichtbar wird. MQTT 3.1.1, Abschnitt 3.3.5, bietet dem Broker keine Möglichkeit, sie zu melden: Er muss entweder normal quittieren oder die Verbindung schließen. Wählt der Broker die normale Quittierung, kann ein 3.1.1-Client eine verweigerte QoS-1-Veröffentlichung für erfolgreich halten. Schließt der Broker stattdessen die Verbindung, sieht der Client einen Verbindungsabbruch ohne Ablehnungsgrund für die Veröffentlichung. MQTT 5 sendet im PUBACK den Reason Code 0x87 („Not authorized“). Bei 3.1.1 weisen Sie die Verweigerung mit einem zweiten Client nach, der das Zieltopic abonniert hat.

4. Annahme durch die Anwendung

Senden Sie einen bekannten Messwert und suchen Sie ihn in der empfangenden Anwendung: im Historian, auf der Energieplattform oder in der Kundendatenbank. Vergleichen Sie Quelle, Zeitmarke, Wert und Einheit. Ein Brokerprotokoll belegt nur, dass der Broker die Nachricht erhalten hat.

Ein Beispiel mit fiktiven Namen: Gateway gw-0417 liest am Hauptzähler um 14:03:00 UTC eine Leistung von 412,6 kW und veröffentlicht unter sites/gw-0417/telemetry/main-meter:

{
  "device": "main-meter",
  "quantity": "active_power",
  "value": 412.6,
  "unit": "kW",
  "ts": "2026-09-22T14:03:00Z",
  "id": "gw-0417-main-meter-20260922T140300Z"
}

Der Plattformdatensatz muss dasselbe Gerät, 412,6 kW und 14:03:00Z zeigen. Zeigt er 14:03:07, hat die Plattform die Eintreffzeit statt der Quellzeit gespeichert. Zeigt er 0,4126, wurde bei der Einheitenzuordnung durch 1.000 geteilt. Beide Fehler bleiben am Broker unsichtbar.

Prüfung über die Kommandozeile

Zwei Werkzeuge decken die meisten Fehler bei der Inbetriebnahme ab. Führen Sie sie auf einem Laptop im selben Netzsegment wie das Gateway aus.

Prüfen Sie Zertifikatskette und Hostname mit OpenSSL:

openssl s_client -connect broker.example.net:8883 \
  -servername broker.example.net \
  -verify_hostname broker.example.net \
  -CAfile site-ca.crt -verify_return_error -brief < /dev/null

Bei Erfolg erscheinen die ausgehandelte Version (TLSv1.2 oder TLSv1.3) und eine erfolgreiche Prüfung. Wiederholen Sie mit -verify_hostname wrong.example.net und einer anderen CA-Datei. Beides muss scheitern. Gelingt es, findet die Prüfung nicht statt.

Veröffentlichen Sie danach mit den Zugangsdaten des Gateways und mosquitto_pub:

mosquitto_pub -h broker.example.net -p 8883 -V mqttv5 -d \
  --cafile site-ca.crt --cert gw-0417.crt --key gw-0417.key \
  -i gw-0417 -q 1 \
  -t sites/gw-0417/telemetry/main-meter -f reading.json

Die Ausgabe mit -d zeigt CONNACK und den Reason Code des PUBACK. Ändern Sie das Topic in sites/gw-0999/telemetry/main-meter und senden Sie erneut. Bei MQTT 5 sollte Reason Code 135 (0x87) erscheinen. Halten Sie private Schlüssel aus Tickets, Chats und Bildschirmfotos heraus.

Firewalls, Port 443 und WebSockets

Ausgehendes TCP auf Port 8883 ist in Kundennetzen oft gesperrt; eine Freigabe kann Wochen dauern. Zwei Alternativen nutzen Port 443:

• MQTT über WebSockets mit TLS (wss://). Abschnitt 6 der MQTT-5-Spezifikation definiert die WebSocket-Übertragung mit dem Subprotokollnamen mqtt. Mosquitto unterstützt sie mit protocol websockets auf einem Listener. AWS IoT Core stellt sie unter wss://<endpoint>/mqtt auf Port 443 bereit.
• MQTT auf Port 443 mit ALPN. AWS IoT Core akzeptiert gewöhnliches MQTT mit einem X.509-Clientzertifikat auf Port 443, wenn der Client im TLS ClientHello den ALPN-Protokollnamen x-amzn-mqtt-ca sendet (AWS-Protokolltabelle).

Beides setzt Unterstützung durch den Broker voraus. Ein Standortproxy, der TLS aufbricht und untersucht, unterbricht zudem gegenseitiges TLS: Der Proxy kann das Clientzertifikat des Gateways nicht vorlegen. Fordern Sie für den Hostnamen des Brokers eine Proxy-Ausnahme an.

Zertifikatslaufzeit und Gateway-Uhr

Der Ablauf von Zertifikaten ist nach der Übergabe eine häufige Ursache für MQTTS-Ausfälle. Er tritt Monate später ein, wenn das Inbetriebnahmeteam nicht mehr zusieht.

Die Laufzeiten öffentlich vertrauenswürdiger TLS-Serverzertifikate werden kürzer. Nach dem Beschluss SC081v3 des CA/Browser Forum sank die Höchstlaufzeit am 15. März 2026 auf 200 Tage. Am 15. März 2027 sinkt sie auf 100 Tage und am 15. März 2029 auf 47 Tage. Ein Cloud-Broker mit öffentlichem Zertifikat wird es deshalb mehrmals jährlich erneuern. Ein Gateway, das der ausstellenden Stamm-CA vertraut, bemerkt das nicht. Ein Gateway mit Bindung an das Endzertifikat fällt bei jeder Erneuerung aus. Private CAs fallen nicht unter diese Regeln; ihre Laufzeiten legt das Projekt fest. Dokumentieren Sie, wer Brokerzertifikat und jedes Gateway-Zertifikat erneuert und wann die erste Erneuerung fällig ist.

Der Client vergleicht notBefore und notAfter mit seiner eigenen Uhr. Startet ein Gateway nach langem Stromausfall ohne batteriegepufferte Uhr etwa mit dem 1. Januar 1970, weist es ein gültiges Zertifikat als „noch nicht gültig“ zurück. Das EpiSensor Gateway stellt seine Uhr über NTP, normalerweise UDP 123. Lassen Sie diese Verbindung durch die Standortfirewall zu und prüfen Sie die Gateway-Zeit, bevor Sie einen Handshake-Fehler untersuchen.

QoS und Zustellung

MQTT Quality of Service gilt jeweils für eine Sender-Empfänger-Strecke. Publisher zu Broker und Broker zu Subscriber sind getrennte Vorgänge mit eigenen Quittungen.

Bei QoS 1 sendet der Broker PUBACK, sobald er die Verantwortung für die Nachricht übernommen hat. Laut MQTT-5-Spezifikation muss er die weitere Zustellung davor nicht abgeschlossen haben. Lesen Sie den Reason Code, bevor Sie einen Erfolg protokollieren: 0x00 bedeutet Erfolg. 0x10 („No matching subscribers“) bedeutet, dass der Broker eine Nachricht angenommen hat, die niemand abonniert hatte. 0x87 („Not authorized“) und 0x97 („Quota exceeded“) sind Ablehnungen. Selbst 0x00 sagt nichts darüber, was die Plattform danach tat.

Prüfen Sie die Zielgrenzen in der Plattformdokumentation. AWS IoT Core unterstützt QoS 0 und 1, aber nicht QoS 2. AWS weist außerdem darauf hin, dass eine MQTT-Verbindung nur wenige Minuten bestehen kann (Verbindungsgrenzen); der Client muss sich sauber wieder verbinden.

Andere MQTT-Funktionen lösen andere Probleme:

• Eine retained message hält die jüngste Nachricht eines Topics für den nächsten Subscriber bereit. Sie bildet keine Historie.
• Eine persistente Sitzung (Clean Start aus, mit Session-Expiry-Intervall) hält Abonnements und wartende QoS-1- und QoS-2-Nachrichten für einen zeitweise getrennten Subscriber. Der Broker begrenzt die Warteschlange. Sie puffert keine Daten, die das Gateway nie senden konnte.
• Keep Alive legt fest, wie oft der Client ein Paket senden muss. Nach dem 1,5-Fachen des Intervalls ohne Verkehr schließt der Broker die Verbindung. Bei 60 s wird eine ausgefallene Verbindung binnen 90 s erkannt.
• Eine Will-Nachricht veröffentlicht der Broker, wenn der Client ohne sauberes DISCONNECT verschwindet. Nutzen Sie sie, um das Gateway auf einem Statustopic als offline zu markieren.

Schreiben Sie die Quellzeit in die Nutzdaten. Nachgesendete Messwerte landen dann zur richtigen Zeit und wirken nicht wie aktuelle Daten.

Doppelte Client-IDs

Der Broker lässt je Client-ID nur eine aktive Verbindung zu. Meldet sich ein zweiter Client mit derselben ID an, trennt der Broker den ersten. MQTT 5 sendet Reason Code 0x8E („Session taken over“). Verbinden sich beide Clients automatisch wieder, verdrängen sie einander alle paar Sekunden. Im Brokerprotokoll erscheint ein ständiger Verbindungs- und Trennungszyklus für dieselbe ID, oft von zwei Adressen. Häufige Ursache ist ein geklontes Gateway-Image oder ein Testlaptop mit Gateway-Zugangsdaten. Binden Sie die Client-ID an die Zertifikatsidentität; so kann die ACL die Kopie sperren.

MQTTS in EpiSensor Edge

EpiSensor Edge betreibt auf dem Gateway einen Node-RED-Flow-Editor. Ein Flow liest Felddaten, formt sie zum vereinbarten Topic und Nutzdatenformat und veröffentlicht sie über einen MQTT-Broker-Node. Aktivieren Sie an diesem Node TLS und wählen Sie eine TLS-Konfiguration. Laden Sie dort das CA-Zertifikat und, wenn der Broker es fordert, Clientzertifikat und Schlüssel. Aktivieren Sie „Serverzertifikat überprüfen“ und tragen Sie den Servernamen ein, falls der Broker SNI benötigt.

Von Edge verwaltete Integrationen behandeln Ausfälle mit einer persistierenden Wiederholungswarteschlange auf dem Datenträger. Schlägt eine Zustellung fehl, schreibt Edge sie in die Warteschlange, prüft jede Minute die Erreichbarkeit des Ziels und sendet sie mit den ursprünglichen Zeitmarken nach. Die Warteschlange hat keine Altersgrenze und wächst bei langem Ausfall weiter; bemessen Sie den Gateway-Speicher für die längste geplante Unterbrechung. Ein Batch, der bei Stromverlust noch im Arbeitsspeicher liegt, kann verloren gehen. Bei der Wiederholung kann ein Batch zweimal ankommen, wenn der Broker ihn bereits erhalten hatte, bevor Edge den Abschluss erfasste. Ein MQTT-out-Node, den Sie in einem eigenen Flow hinzufügen, liegt außerhalb dieser Warteschlange. Testen Sie sein Verhalten über einen Gateway-Neustart, bevor Sie sich darauf verlassen.

Eine typische Plattformanbindung sendet zugeordnete Messwerte über TCP 8883 an den Broker der Plattform, authentifiziert mit einem Clientzertifikat je Gateway. Jede Plattform benötigt eigene Brokerangaben, einen Topic-Vertrag und eine Abnahmeprüfung. Edge mit Ihrer Plattform verbinden beschreibt die verfügbaren Ausgabepfade. An einem Standort mit mehreren Herstellern behandelt die Interoperabilitätsanleitung den Datenvertrag, den MQTT-Unterstützung allein offenlässt.

Checkliste zur Inbetriebnahme

Gehen Sie diese Schritte der Reihe nach durch. Keiner erfordert einen realen Steuerbefehl.

1. Dokumentieren Sie Broker-FQDN, Port, MQTT-Version, Client-ID, Authentifizierungsverfahren, Topic-Struktur, Nutzdatenformat, QoS und Retain-Einstellungen.
2. Prüfen Sie Gateway-Uhr, DNS-Auflösung und ausgehende Firewallregel für Hostname und Port des Brokers.
3. Prüfen Sie Zertifikatskette, Namen und Ablaufdaten sowie, ob der Client-Schlüssel zum Zertifikat passt.
4. Aktivieren Sie die Zertifikatsprüfung am Gateway. Weisen Sie nach, dass falscher Hostname und nicht vertrauenswürdige CA abgelehnt werden.
5. Stellen Sie sicher, dass kein weiteres Gerät Client-ID oder Zugangsdaten des Gateways nutzt.
6. Veröffentlichen Sie auf einem erlaubten Topic und versuchen Sie danach eine verweigerte Veröffentlichung.
7. Senden Sie einen bekannten Messwert und vergleichen Sie Quelle, Zeitmarke, Wert und Einheit auf der empfangenden Plattform.
8. Beobachten Sie mindestens drei Meldeintervalle. Ein einzelner Wert könnte retained oder veraltet sein.
9. Trennen Sie das WAN für eine bekannte Dauer. Prüfen Sie nach der Wiederverbindung auf der Plattform auf Lücken, Duplikate und Zeitmarken.
10. Halten Sie Zertifikatsablaufdaten und Zuständigkeiten für die Erneuerung fest. Testen Sie ein neues Zertifikat, bevor Sie das alte entfernen.

Für die Messung selbst behandelt die Anleitung zu Sensordaten Quellzeit, Qualität und Lücken. Die SCADA-Anleitung trennt Protokollquittung und Gerätezustand.

Befehle und Steuerung

Ein Befehlstopic braucht mehr Regeln als ein Telemetrietopic. Geben Sie jedem Befehl ein Ablaufdatum, damit eine durch einen Ausfall verzögerte Nachricht verworfen und nicht später ausgeführt wird. Geben Sie dem Controller ein eigenes Befehlstopic mit ausschließlich Leserecht. Gestalten Sie den Befehl idempotent, da QoS 1 ihn zweimal zustellen kann. Bestätigen Sie die Wirkung durch Rücklesen des Gerätezustands und bei entsprechendem Risiko durch eine unabhängige Messung.

Setzen Sie auf Befehlstopics kein Retain. Der Broker sendet einen retained Befehl jedem neuen Subscriber; ein Controller könnte nach dem Neustart einen alten Sollwert ausführen. Sicherheitsverriegelungen bleiben im lokalen Controller. Die Anleitung zur BMS- und SCADA-Integration zeigt Edge daneben. Testen Sie die Verbindung nicht mit einer realen Schalthandlung.

Fehlersuche nach Schicht

Beginnen Sie bei der untersten Schicht, die das Symptom erklären kann. Beheben Sie einen Fehler nie, indem Sie die Zertifikatsprüfung abschalten oder eine Topic-ACL erweitern.

Protokollieren Sie jeden Test mit Zeit, Gateway- und Brokeridentität, Flow-Revision, Topic (Standortnamen unkenntlich gemacht), erwartetem und beobachtetem Ergebnis.