Che cos’è MQTTS? MQTT su TLS per l’IoT energetico

MQTTS è la forma breve per MQTT trasportato tramite Transport Layer Security (TLS). Non è una versione MQTT distinta. I pacchetti MQTT non cambiano: TLS li avvolge. Quando il client verifica il certificato, TLS cifra la connessione, rileva le manomissioni e dimostra quale broker è stato raggiunto.

In un sito energetico, controlla separatamente tre cose. Il gateway ha raggiunto il broker giusto. Può pubblicare solo sui propri topic. La piattaforma ha memorizzato il valore, l'unità e il timestamp giusti. Un indicatore verde «connesso» mostra soltanto la prima metà della prima verifica.

Non confondere MQTTS con MQTT-SN, che in passato si chiamava MQTT-S. MQTT-SN è un protocollo distinto per reti di sensori e trasporti non TCP/IP (specifiche MQTT).

MQTT e MQTTS in breve

La specifica MQTT 5.0 indica che le porte TCP 8883 e 1883 sono registrate presso IANA rispettivamente per MQTT su TLS e MQTT in chiaro. I nomi dei servizi IANA sono secure-mqtt e mqtt. La porta è una convenzione. La sicurezza dipende dall'handshake e dalla verifica del certificato; anche un listener su 8883 può essere configurato male.

MQTT 5 definisce anche l'autenticazione avanzata tramite il pacchetto AUTH. La capacità di dimostrare l'identità del server dipende dal metodo: un metodo challenge-response come SCRAM può farlo, un semplice token no. Pochi broker lo implementano, quindi nella quasi totalità delle installazioni l'identità del broker deriva dal certificato TLS.

Versioni TLS

Usa TLS 1.2 o 1.3. RFC 8996 ha deprecato TLS 1.0 e 1.1 nel 2021. Mosquitto consente TLS 1.3 e 1.2 per impostazione predefinita (mosquitto.conf) e AWS IoT Core accetta le stesse due versioni. Un client fermo a TLS 1.0 fallisce l'handshake con un avviso sulla versione del protocollo. In genere significa firmware vecchio, non certificato errato.

Dove termina TLS

TLS protegge un collegamento: dal client al componente che termina TLS. Un load balancer cloud che termina TLS e inoltra TCP in chiaro al broker lascia quel tratto interno non cifrato, salvo che lo cifri di nuovo. Il broker inoltre non vede più il certificato client, quindi le ACL basate sui certificati non funzionano. Individua dove termina TLS prima di progettare l'identità attorno ai certificati client. Se il payload deve rimanere riservato oltre il broker, cifralo al livello applicativo con chiavi proprie. TLS collegamento per collegamento non equivale a cifratura end-to-end.

Quattro verifiche di sicurezza

1. Fiducia e identità del broker

Il client ha bisogno di un'ancora di fiducia, di solito il certificato della CA che ha firmato quello del broker. Verifica la catena, le date notBefore e notAfter definite in RFC 5280 e il nome. RFC 9525 descrive il confronto fra l'identificatore di riferimento configurato, normalmente il nome DNS inserito, e i nomi alternativi del soggetto nel certificato.

Configura il nome di dominio completo del broker, non l'indirizzo IP a cui si risolveva in quel momento. Un certificato per broker.example.net non corrisponde a 203.0.113.40. Invia Server Name Indication (SNI) dove il servizio ospita più nomi su un solo indirizzo; AWS IoT Core richiede SNI per domini personalizzati ed endpoint configurabili.

Considera attendibile la CA emittente invece di fissare il certificato leaf del broker. Un certificato leaf fissato interrompe il gateway a ogni rinnovo del broker.

2. Identità del client

Assegna a ogni gateway un'identità propria: un certificato client e una chiave privata oppure nome utente e password univoci. Non condividere mai un certificato fra tutti i gateway. Revocarlo per un sito disconnetterebbe ogni sito.

In Mosquitto, un listener TLS e l'obbligo di certificato client sono impostazioni separate. require_certificate true rifiuta i client senza certificato valido e use_identity_as_username true usa il CN del certificato come nome utente MQTT, che l'ACL può quindi utilizzare (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

Mosquitto 2.0 e successivi rifiutano i client anonimi quando è configurato un listener, salvo che sia impostato allow_anonymous true.

3. Autorizzazione ai topic

L'autenticazione stabilisce chi è il client. L'autorizzazione stabilisce su quali topic può pubblicare e a quali può sottoscriversi. Assegna a ogni gateway soltanto il proprio ramo. Con il listener sopra, il CN del certificato del gateway diventa %u nel modello ACL:

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

Il gateway gw-0417 può ora pubblicare sotto sites/gw-0417/telemetry/ e leggere il proprio topic dei comandi. Non può scrivere su un altro sito né sul proprio topic dei comandi. Il plugin Dynamic Security di Mosquitto esprime le stesse regole come ruoli con permessi separati di pubblicazione, ricezione e sottoscrizione.

Prova una pubblicazione consentita e una negata. La versione del protocollo cambia l'aspetto del rifiuto. MQTT 3.1.1 (sezione 3.3.5) non offre al broker un modo per segnalarlo: deve confermare normalmente o chiudere la connessione. Se il broker sceglie la conferma normale, un client 3.1.1 può scambiare una pubblicazione QoS 1 negata per un successo. Se invece il broker chiude la connessione, il client vede una disconnessione senza un motivo di rifiuto della pubblicazione. MQTT 5 restituisce il codice motivo 0x87 (Not authorized) nel PUBACK. Con 3.1.1, dimostra il rifiuto tramite un secondo client sottoscritto al topic di destinazione.

4. Accettazione dell'applicazione

Invia una lettura nota e trovala nell'applicazione destinataria: historian, piattaforma energetica o database del cliente. Confronta sorgente, timestamp, valore e unità. Il log del broker dimostra solo che il broker ha ricevuto il messaggio.

Esempio calcolato con nomi fittizi. Il gateway gw-0417 legge 412,6 kW dal contatore principale alle 14:03:00 UTC e pubblica su 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"
}

Il record della piattaforma deve mostrare lo stesso dispositivo, 412,6, kW e 14:03:00Z. Se mostra 14:03:07, la piattaforma ha assegnato l'ora di arrivo e scartato quella della sorgente. Se mostra 0,4126, una mappatura delle unità ha diviso per 1.000. Entrambi gli errori sono invisibili al broker.

Prove dalla riga di comando

Due strumenti coprono la maggior parte dei guasti di messa in servizio. Eseguili da un portatile sulla stessa tratta di rete del gateway.

Verifica la catena del certificato e il nome host con 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

Un esito valido mostra il protocollo negoziato (TLSv1.2 o TLSv1.3) e la verifica riuscita. Ripeti con -verify_hostname wrong.example.net e con un file CA diverso. Entrambe le prove devono fallire. Se riescono, la verifica non viene eseguita.

Pubblica quindi con le credenziali del gateway tramite 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

L'output di -d mostra CONNACK e il codice motivo PUBACK. Cambia il topic in sites/gw-0999/telemetry/main-meter e pubblica di nuovo. Con MQTT 5 dovresti vedere il codice motivo 135 (0x87). Tieni le chiavi private fuori da ticket, chat e schermate.

Firewall, porta 443 e WebSocket

La porta TCP 8883 in uscita è spesso bloccata nelle reti dei clienti e la richiesta di aprirla può richiedere settimane. Due alternative usano la porta 443:

• MQTT su WebSocket con TLS (wss://). La sezione 6 della specifica MQTT 5 definisce il trasporto WebSocket, con nome del sottoprotocollo mqtt. Mosquitto lo supporta con protocol websockets su un listener. AWS IoT Core lo offre a wss://<endpoint>/mqtt sulla porta 443.
• MQTT sulla porta 443 con ALPN. AWS IoT Core accetta MQTT semplice con un certificato client X.509 sulla porta 443 se il client invia il nome del protocollo ALPN x-amzn-mqtt-ca nel TLS ClientHello (tabella dei protocolli AWS).

Entrambe dipendono dal supporto del broker. Un proxy del sito che ispeziona TLS interrompe anche il TLS reciproco, perché non può presentare il certificato client del gateway. Chiedi di escludere dal proxy il nome host del broker.

Durata dei certificati e orologio del Gateway

La scadenza dei certificati è il guasto MQTTS più comune dopo la consegna. Arriva mesi dopo, quando nessuno del team di messa in servizio sta osservando.

La durata dei certificati TLS server considerati attendibili pubblicamente si sta riducendo. Secondo la delibera SC081v3 del CA/Browser Forum, la validità massima è scesa a 200 giorni il 15 marzo 2026. Scenderà a 100 giorni il 15 marzo 2027 e a 47 giorni il 15 marzo 2029. Un broker cloud che usa un certificato pubblico lo rinnoverà quindi più volte l'anno. Un gateway che considera attendibile la CA radice emittente non se ne accorge. Un gateway che fissa il certificato leaf fallisce a ogni rinnovo. Le CA private sono escluse da queste regole: la durata viene stabilita dal progetto. Registra chi rinnova il certificato del broker, chi rinnova quello di ogni gateway e quando scade il primo rinnovo.

Il client confronta notBefore e notAfter con il proprio orologio. Un gateway che si avvia con una data sbagliata, per esempio 1 gennaio 1970 dopo una lunga interruzione di alimentazione su hardware senza orologio con batteria tampone, rifiuta un certificato valido come «non ancora valido». Il Gateway EpiSensor imposta l'orologio tramite NTP, normalmente UDP 123. Consenti questo percorso nel firewall del sito e controlla l'ora del Gateway prima di diagnosticare l'handshake.

QoS e consegna

La qualità del servizio MQTT si applica a un collegamento mittente-destinatario. Da publisher a broker e da broker a subscriber sono scambi separati, con conferme separate.

Con QoS 1, il broker invia PUBACK dopo aver accettato la responsabilità del messaggio. La specifica MQTT 5 dice che il destinatario non deve completare l'inoltro prima di rispondere. Leggi il codice motivo prima di registrare il successo. 0x00 indica successo. 0x10 (No matching subscribers) significa che il broker ha accettato un messaggio senza subscriber pronti a riceverlo. 0x87 (Not authorized) e 0x97 (Quota exceeded) indicano rifiuti. Anche 0x00 non dice nulla su ciò che la piattaforma ha fatto in seguito.

Controlla i limiti della destinazione nella documentazione della piattaforma. AWS IoT Core supporta QoS 0 e 1 ma non QoS 2. AWS avverte inoltre che una connessione MQTT può durare anche solo pochi minuti (limiti di connessione), quindi il client deve riconnettersi correttamente.

Altre funzioni MQTT risolvono problemi diversi:

• Un messaggio retained conserva l'ultimo messaggio di un topic per il prossimo subscriber. Conserva un solo valore, non uno storico.
• Una sessione persistente (clean start disattivato, con intervallo di scadenza della sessione) conserva sottoscrizioni e messaggi QoS 1 e 2 in coda per un subscriber offline. Il broker stabilisce i limiti della coda. Non conserva dati che il gateway non è riuscito a inviare.
• Keep alive stabilisce ogni quanto il client deve inviare un pacchetto. Il broker chiude la connessione dopo 1,5 volte quell'intervallo senza traffico. Con 60 secondi, un collegamento interrotto viene rilevato entro 90.
• Un messaggio Will viene pubblicato dal broker quando il client scompare senza un DISCONNECT regolare. Usalo per indicare che il gateway è offline su un topic di stato.

Inserisci il timestamp della sorgente nel payload. Le letture ritrasmesse arrivano così all'ora corretta e non sembrano attuali.

Collisioni degli ID client

Il broker consente una sola connessione attiva per ogni ID client. Quando si collega un secondo client con lo stesso ID, il broker disconnette il primo. MQTT 5 invia il codice motivo 0x8E (Session taken over). Se entrambi si riconnettono automaticamente, si espellono a vicenda ogni pochi secondi. Il log del broker mostra un ciclo continuo di connessioni e disconnessioni per un solo ID, spesso da due indirizzi. La causa abituale è un'immagine del gateway clonata o un portatile di prova che usa le credenziali del gateway. Associa l'ID client all'identità del certificato e l'ACL può bloccare la copia.

MQTTS in EpiSensor Edge

EpiSensor Edge esegue un editor di flussi Node-RED sul Gateway. Un flusso legge dati di campo, li organizza nel topic e nel payload concordati e li pubblica tramite un nodo broker MQTT. Nel nodo broker, abilita TLS e seleziona una configurazione TLS. In tale configurazione, carica il certificato CA, oltre al certificato client e alla chiave se il broker li richiede. Seleziona «Verify server certificate» e imposta il nome server quando il broker richiede SNI.

Le integrazioni gestite da Edge affrontano le interruzioni con una coda di ritentativi persistente su disco. Quando una consegna fallisce, Edge la scrive nella coda, controlla ogni minuto se la destinazione è tornata e la riproduce con i timestamp originali. La coda non ha un limite di età: una lunga interruzione la fa crescere; dimensiona lo spazio del Gateway per l'interruzione più lunga prevista. Un batch ancora in memoria quando manca l'alimentazione può andare perso e una ritrasmissione può consegnarlo due volte se il broker l'ha ricevuto prima che Edge registrasse il completamento. Un nodo MQTT out aggiunto a un flusso proprio resta fuori da questa coda. Prova il suo comportamento attraverso un riavvio del Gateway prima di farvi affidamento.

Una tipica connessione alla piattaforma pubblica misure mappate sul broker della piattaforma tramite TCP 8883, autenticandosi con un certificato client specifico per il Gateway. Ogni piattaforma richiede dettagli del broker, contratto dei topic e prova di accettazione propri; collegare Edge alla propria piattaforma descrive le modalità di invio di Edge. Per un sito con più produttori, la guida all'interoperabilità tratta il contratto dei dati che il solo supporto MQTT non definisce.

Lista di controllo per la messa in servizio

Segui questi passaggi nell'ordine. Nessuno richiede un'azione di controllo reale.

1. Annota FQDN del broker, porta, versione MQTT, ID client, metodo di autenticazione, struttura dei topic, formato del payload, impostazioni QoS e retain.
2. Controlla orologio del Gateway, risoluzione DNS e regola del firewall in uscita per nome host e porta del broker.
3. Esamina i certificati. Controlla catena, nomi, date di scadenza e corrispondenza fra chiave e certificato del client.
4. Abilita la verifica del certificato sul Gateway. Dimostra che un nome host errato e una CA non attendibile vengono rifiutati.
5. Conferma che nessun altro dispositivo usi l'ID client o le credenziali del Gateway.
6. Pubblica su un topic consentito, poi tenta una pubblicazione negata.
7. Invia una lettura nota e confronta sorgente, timestamp, valore e unità nella piattaforma destinataria.
8. Osserva almeno tre intervalli di trasmissione. Un singolo valore può essere retained o obsoleto.
9. Interrompi la WAN per un periodo noto. Dopo la riconnessione, controlla vuoti, duplicati e timestamp nella piattaforma.
10. Registra le date di scadenza dei certificati e chi rinnova ciascuno. Prova un certificato sostitutivo prima di rimuovere quello vecchio.

Per la misura, la guida ai dati dei sensori tratta ora della sorgente, qualità e gestione dei vuoti. La guida SCADA distingue una conferma del protocollo dallo stato del dispositivo.

Comandi e controllo

Un topic dei comandi richiede più di uno di telemetria. Assegna a ogni comando una scadenza, così un messaggio ritardato da un'interruzione viene scartato anziché eseguito tardi. Assegna al controllore un topic dei comandi proprio con accesso in sola lettura. Rendi il comando idempotente, perché QoS 1 può consegnarlo due volte. Conferma l'esito rileggendo lo stato del dispositivo e con una misura indipendente dove il rischio lo giustifica.

Non impostare retain sui topic dei comandi. Il broker ripropone un comando retained a ogni nuovo subscriber: un controllore che si riconnette dopo un riavvio può eseguire un setpoint obsoleto. Gli interlock di sicurezza restano nel controllore locale; la guida all'integrazione BMS e SCADA mostra dove si colloca Edge. Non provare la connettività con un'attuazione in produzione.

Diagnostica per livello

Parti dal livello più basso che spiega il sintomo. Non risolvere mai un guasto disabilitando la verifica del certificato o ampliando l'ACL di un topic.

Registra ogni prova con ora, identità del Gateway e del broker, revisione del flusso, topic (oscurando i nomi dei siti), esito atteso ed esito osservato.