MQTT sous TLS : sécurité des données énergétiques

MQTTS désigne MQTT transporté sur une connexion Transport Layer Security (TLS). Ce n’est pas une autre version de MQTT. Les paquets MQTT restent identiques ; TLS les enveloppe. Quand le client vérifie le certificat, TLS chiffre la connexion, détecte les modifications et prouve l’identité du courtier joint.

Sur un site énergétique, vérifiez séparément trois choses : le Gateway a joint le bon courtier ; il ne peut publier que dans ses propres rubriques ; la plateforme a stocké la bonne valeur, unité et heure. Un indicateur vert « connecté » ne couvre que la première moitié de la première vérification.

Ne confondez pas MQTTS et MQTT-SN, autrefois appelé MQTT-S. MQTT-SN est un protocole distinct destiné aux réseaux de capteurs et aux transports autres que TCP/IP (spécifications MQTT).

MQTT et MQTTS en bref

La spécification MQTT 5.0 indique que l’IANA a enregistré les ports TCP 8883 et 1883 pour MQTT sous TLS et MQTT en clair. Les noms de service IANA sont secure-mqtt et mqtt. Le port est une convention. La sécurité dépend de la négociation TLS et de la vérification du certificat ; un service écoutant sur 8883 peut tout de même être mal configuré.

MQTT 5 définit aussi une authentification renforcée par paquet AUTH. La preuve de l’identité du serveur dépend de la méthode : un mécanisme de défi-réponse comme SCRAM peut la fournir, un simple jeton non. Peu de courtiers l’implémentent ; dans presque tous les déploiements, c’est donc le certificat TLS qui établit l’identité du courtier.

Versions de TLS

Utilisez TLS 1.2 ou 1.3. La RFC 8996 a déprécié TLS 1.0 et 1.1 en 2021. Mosquitto autorise TLS 1.3 et 1.2 par défaut (mosquitto.conf), tout comme AWS IoT Core. Un client limité à TLS 1.0 échoue avec une alerte de version du protocole. La cause habituelle est un ancien micrologiciel, pas un mauvais certificat.

Où TLS se termine

TLS protège une seule liaison : du client au composant qui termine TLS. Si un répartiteur de charge cloud termine TLS puis relaie du TCP en clair au courtier, cette seconde liaison reste non chiffrée à moins d’être rechiffrée. Le courtier ne voit plus non plus le certificat client, ce qui rend inopérantes ses règles d’accès fondées sur ce certificat. Trouvez le point de terminaison TLS avant de concevoir l’identité des clients autour des certificats. Si la charge utile doit rester confidentielle au-delà du courtier, chiffrez-la au niveau applicatif avec ses propres clés. TLS de liaison en liaison n’est pas un chiffrement de bout en bout.

Quatre vérifications de sécurité

1. Confiance et identité du courtier

Le client a besoin d’une ancre de confiance, habituellement le certificat de l’autorité ayant signé celui du courtier. Il vérifie la chaîne, les dates notBefore et notAfter définies dans la RFC 5280, ainsi que le nom. La RFC 9525 décrit la comparaison entre l’identifiant de référence configuré, normalement le nom DNS saisi, et les autres noms de sujet du certificat.

Configurez le nom de domaine pleinement qualifié du courtier, et non l’adresse IP vers laquelle il pointe ce jour-là. Un certificat pour broker.example.net ne correspond pas à 203.0.113.40. Envoyez l’indication du nom de serveur (SNI) si le service héberge plusieurs noms sur une adresse ; AWS IoT Core exige SNI pour les domaines personnalisés et certains points de terminaison configurables.

Faites confiance à l’autorité émettrice plutôt qu’au seul certificat du courtier. Une épingle sur ce certificat final rompt la connexion du Gateway à chaque renouvellement.

2. Identité du client

Attribuez une identité propre à chaque Gateway : certificat et clé privée de client, ou nom d’utilisateur et mot de passe uniques. Ne partagez jamais un certificat dans une flotte. Le révoquer pour un seul site déconnecterait alors tous les sites.

Dans Mosquitto, un service TLS et l’obligation d’un certificat client sont deux réglages distincts. require_certificate true refuse les clients sans certificat valide ; use_identity_as_username true prend le CN du certificat comme nom d’utilisateur MQTT, utilisable ensuite par la liste de contrôle d’accès (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

Depuis Mosquitto 2.0, les clients anonymes sont refusés dès qu’un service d’écoute est configuré, sauf si allow_anonymous true est défini.

3. Autorisation des rubriques

L’authentification indique qui est le client. L’autorisation indique où il peut publier et à quoi il peut s’abonner. Attribuez à chaque Gateway sa branche, sans autre droit. Avec le service ci-dessus, le CN du certificat du Gateway devient %u dans le motif d’accès :

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

Le Gateway gw-0417 peut alors publier sous sites/gw-0417/telemetry/ et lire sa propre rubrique de commandes. Il ne peut ni écrire sur un autre site ni publier dans ses propres commandes. Le module Dynamic Security de Mosquitto exprime les mêmes règles par rôles, avec des droits distincts de publication, réception et abonnement.

Testez une publication autorisée et une refusée. La version du protocole change l’apparence du refus. MQTT 3.1.1, section 3.3.5, ne permet pas au courtier de le signaler : il doit confirmer normalement ou fermer la connexion. Si le courtier choisit la confirmation normale, un client 3.1.1 peut prendre une publication QoS 1 refusée pour un succès. Si le courtier ferme plutôt la connexion, le client constate une déconnexion sans motif de refus de la publication. MQTT 5 renvoie le code de motif 0x87 (Not authorized) dans PUBACK. En 3.1.1, prouvez le refus avec un second client abonné à la rubrique cible.

4. Acceptation par l’application

Envoyez une lecture connue et retrouvez-la dans l’application destinataire : historien, plateforme énergétique ou base client. Comparez source, horodatage, valeur et unité. Le journal du courtier prouve seulement qu’il a reçu le message.

Exemple avec des noms fictifs : le Gateway gw-0417 lit 412,6 kW sur le compteur principal à 14:03:00 UTC et publie dans 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"
}

L’enregistrement de la plateforme doit indiquer le même appareil, 412,6, kW et 14:03:00Z. S’il indique 14:03:07, la plateforme a apposé l’heure d’arrivée et perdu l’heure source. S’il indique 0,4126, une conversion d’unité a divisé par 1 000. Aucune de ces erreurs n’est visible au niveau du courtier.

Essais en ligne de commande

Deux outils couvrent la plupart des défaillances à la mise en service. Exécutez-les depuis un ordinateur sur le même segment réseau que le Gateway.

Vérifiez la chaîne de certificats et le nom d’hôte avec 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 bon résultat indique la version négociée (TLSv1.2 ou TLSv1.3) et une vérification réussie. Réessayez avec -verify_hostname wrong.example.net, puis avec un autre fichier d’autorité. Les deux doivent échouer. S’ils réussissent, la vérification n’a pas lieu.

Publiez ensuite avec les identifiants du Gateway à l’aide de 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

La sortie -d affiche CONNACK et le code de motif PUBACK. Remplacez la rubrique par sites/gw-0999/telemetry/main-meter et republiez. Sous MQTT 5, le code attendu est 135 (0x87). Ne placez pas de clés privées dans les tickets, les discussions ou les captures d’écran.

Pare-feu, port 443 et WebSockets

Le trafic TCP 8883 sortant est souvent bloqué sur les réseaux clients et son ouverture peut demander des semaines. Deux variantes passent par le port 443 :

• MQTT sur WebSockets avec TLS (wss://). La section 6 de MQTT 5 définit le transport WebSocket et le nom de sous-protocole mqtt. Mosquitto le propose avec protocol websockets sur un service d’écoute. AWS IoT Core le sert sur wss://<endpoint>/mqtt au port 443.
• MQTT sur 443 avec ALPN. AWS IoT Core accepte MQTT ordinaire avec un certificat client X.509 sur 443 si le client envoie le nom de protocole ALPN x-amzn-mqtt-ca dans son TLS ClientHello (tableau des protocoles AWS).

Les deux supposent que le courtier les propose. Un proxy de site qui inspecte TLS brise aussi TLS mutuel, car il ne peut pas présenter le certificat client du Gateway. Demandez une exemption de proxy pour le nom d’hôte du courtier.

Durée des certificats et horloge du Gateway

L’expiration d’un certificat est la panne MQTTS la plus fréquente après la remise du système. Elle survient des mois plus tard, lorsque l’équipe de mise en service ne surveille plus la liaison.

La durée des certificats TLS publics diminue. Selon le vote SC081v3 du CA/Browser Forum, le maximum est passé à 200 jours le 15 mars 2026. Il passera à 100 jours le 15 mars 2027 et à 47 jours le 15 mars 2029. Un courtier cloud à certificat public le renouvellera donc plusieurs fois par an. Un Gateway qui fait confiance à l’autorité racine ne le remarquera pas ; un Gateway qui épingle le certificat final échouera à chaque renouvellement. Les autorités privées ne relèvent pas de ces règles : le projet fixe leurs durées. Consignez qui renouvelle le certificat du courtier, qui renouvelle celui de chaque Gateway et la date du premier renouvellement.

Le client compare notBefore et notAfter à sa propre horloge. Un Gateway qui démarre avec une mauvaise date, par exemple le 1er janvier 1970 après une longue coupure sur un matériel sans horloge secourue par batterie, rejette un certificat valide comme « pas encore valable ». Le Gateway EpiSensor règle son horloge par NTP, généralement sur UDP 123. Autorisez ce trajet dans le pare-feu du site et vérifiez l’heure du Gateway avant de diagnostiquer la négociation TLS.

QoS et transmission

La qualité de service MQTT s’applique à une seule liaison entre émetteur et destinataire. La liaison éditeur-courtier et la liaison courtier-abonné sont deux échanges distincts, chacun avec ses propres confirmations.

À QoS 1, le courtier envoie PUBACK une fois qu’il a accepté la responsabilité du message. La spécification MQTT 5 précise qu’il n’a pas à achever la transmission en aval avant de répondre. Lisez le code de motif avant de déclarer un succès. 0x00 signifie succès. 0x10 (No matching subscribers) signifie que le courtier a accepté un message sans destinataire abonné. 0x87 (Not authorized) et 0x97 (Quota exceeded) sont des refus. Même 0x00 ne dit rien de ce que la plateforme a fait ensuite.

Vérifiez les limites du destinataire dans sa documentation. AWS IoT Core prend en charge QoS 0 et 1, mais pas QoS 2. AWS prévient aussi qu’une connexion MQTT peut ne durer que quelques minutes (limites de connexion) : le client doit se reconnecter proprement.

D’autres fonctions MQTT répondent à d’autres besoins :

• Un message conservé garde la dernière publication d’une rubrique pour le prochain abonné. C’est une valeur, pas un historique.
• Une session persistante (clean start désactivé et durée d’expiration définie) conserve les abonnements et les messages QoS 1 et 2 en file pour un abonné hors ligne. Le courtier fixe les limites de cette file. Elle ne garde pas les données que le Gateway n’a jamais pu envoyer.
• Keep alive définit la fréquence minimale des paquets envoyés par le client. Le courtier ferme la connexion après 1,5 fois l’intervalle sans trafic. Avec 60 secondes, une liaison morte est détectée en 90 secondes au plus.
• Un message testament est publié par le courtier si le client disparaît sans DISCONNECT propre. Utilisez-le pour signaler que le Gateway est hors ligne dans une rubrique d’état.

Placez l’horodatage de la source dans la charge utile. Les lectures retransmises seront ainsi classées à leur heure réelle et ne sembleront pas actuelles.

Collision des identifiants clients

Le courtier n’autorise qu’une connexion active par identifiant client. Quand un second client arrive avec le même identifiant, il déconnecte le premier. MQTT 5 envoie le code de motif 0x8E (Session taken over). Si les deux clients se reconnectent automatiquement, ils s’expulsent mutuellement toutes les quelques secondes. Le journal du courtier montre une suite de connexions et déconnexions pour un identifiant, souvent depuis deux adresses. La cause habituelle est une image de Gateway clonée ou un ordinateur de test utilisant les identifiants du Gateway. Liez l’identifiant client à l’identité du certificat ; la liste de contrôle d’accès peut alors bloquer la copie.

MQTTS dans EpiSensor Edge

EpiSensor Edge exécute un éditeur de flux Node-RED sur le Gateway. Un flux lit les données du terrain, les met au format convenu de rubrique et de charge utile, puis les publie par un nœud de courtier MQTT. Sur ce nœud, activez TLS et choisissez une configuration TLS. Chargez-y le certificat de l’autorité et, si le courtier l’exige, le certificat client et sa clé. Cochez « Vérifier le certificat du serveur » et indiquez le nom du serveur si SNI est nécessaire.

Les intégrations gérées par Edge traversent les pannes grâce à une file de reprise persistante. Quand une transmission échoue, Edge l’écrit dans la file, vérifie chaque minute si le destinataire est revenu, puis la retransmet avec l’horodatage d’origine. La file n’a pas de limite d’âge : une longue coupure la fait grossir ; dimensionnez le stockage du Gateway pour la plus longue coupure prévue. Un lot encore en mémoire lors d’une panne de courant peut être perdu ; une retransmission peut livrer deux fois un lot si le courtier l’a reçu avant qu’Edge n’enregistre la réussite. Un nœud de sortie MQTT ajouté à votre propre flux n’utilise pas cette file. Testez son comportement après un redémarrage du Gateway avant d’en dépendre.

Une connexion de plateforme typique publie les mesures associées dans le courtier de la plateforme sur TCP 8883, avec un certificat client propre au Gateway. Chaque plateforme exige ses paramètres de courtier, un contrat de rubriques et un essai de réception propres ; la page Connecter Edge à votre plateforme décrit les modes de transmission d’Edge. Pour un site multimarque, le guide de l’interopérabilité traite du contrat de données que le seul support MQTT ne définit pas.

Liste de mise en service

Suivez ces étapes dans l’ordre. Aucune ne demande de commande réelle d’un équipement.

1. Consignez le nom de domaine pleinement qualifié du courtier, le port, la version MQTT, l’identifiant client, la méthode d’authentification, l’organisation des rubriques, le format de la charge utile, le QoS et le réglage des messages conservés.
2. Vérifiez l’horloge du Gateway, la résolution DNS et la règle de pare-feu sortant pour le nom d’hôte et le port du courtier.
3. Examinez les certificats : chaîne, noms et dates d’expiration, et correspondance entre la clé privée et le certificat client.
4. Activez la vérification du certificat sur le Gateway. Prouvez qu’un mauvais nom d’hôte et une autorité non approuvée sont refusés.
5. Vérifiez qu’aucun autre appareil n’utilise l’identifiant client ou les identifiants du Gateway.
6. Publiez dans une rubrique autorisée, puis essayez une publication refusée.
7. Envoyez une lecture connue et comparez source, horodatage, valeur et unité dans la plateforme destinataire.
8. Surveillez au moins trois intervalles de transmission. Une valeur isolée peut être conservée ou périmée.
9. Coupez le WAN pour une durée connue. Après reconnexion, recherchez lacunes, doublons et horodatages dans la plateforme.
10. Consignez les dates d’expiration des certificats et la personne responsable de chaque renouvellement. Testez un nouveau certificat avant de retirer l’ancien.

Pour la mesure elle-même, le guide des données de capteurs couvre l’heure de la source, la qualité et les lacunes. Le guide SCADA distingue l’accusé de réception du protocole de l’état réel de l’appareil.

Commandes et pilotage

Une rubrique de commandes exige plus de précautions qu’une rubrique de télémétrie. Donnez une date d’expiration à chaque commande, pour qu’un message retardé par une panne soit ignoré au lieu d’être exécuté tardivement. Donnez au contrôleur sa propre rubrique de commandes avec un accès en lecture seule. Rendez la commande idempotente, car QoS 1 peut la livrer deux fois. Confirmez le résultat par relecture de l’état de l’appareil et, si le risque le justifie, par une mesure indépendante.

N’activez pas l’option retain sur les rubriques de commandes. Le courtier rejoue une commande conservée à chaque nouvel abonné : un contrôleur reconnecté après redémarrage pourrait exécuter une ancienne consigne. Les verrouillages de sécurité restent dans le contrôleur local ; le guide d’intégration BMS et SCADA montre la place d’Edge à ses côtés. Ne testez pas la connectivité en actionnant un équipement de production.

Dépanner par couche

Commencez par la couche la plus basse susceptible d’expliquer le symptôme. Ne corrigez jamais une panne en désactivant la vérification des certificats ou en élargissant une liste de droits sur les rubriques.

Consignez pour chaque essai l’heure, l’identité du Gateway et du courtier, la révision du flux, la rubrique (noms de sites masqués), le résultat attendu et le résultat observé.