La configuration TLS de MQTT dans Node-RED ne prend que quelques minutes, mais deux ou trois champs faciles à manquer décident si votre connexion est vraiment sécurisée ou seulement chiffrée. Ce tutoriel configure le nœud de configuration mqtt-broker pour le port 8883 avec vérification du certificat, identifiants et MQTT 5, vous fournit un flow importable et explique les erreurs que vous pourriez rencontrer en chemin.
Comment fonctionne TLS dans Node-RED
Les nœuds MQTT de Node-RED reposent sur MQTT.js et sur la pile TLS de Node.js. Trois éléments interviennent :
- Le nœud de configuration mqtt-broker : contient le serveur, le port, le client ID, la version du protocole, les identifiants et une case « Use TLS ».
- Le nœud tls-config : un nœud de configuration distinct qui contient les options TLS comme le certificat d'AC, le certificat client, le nom du serveur et la vérification ou non du certificat serveur.
- Les nœuds mqtt in / mqtt out : ils référencent le nœud broker et n'ont pas de réglages TLS propres.
Lorsque le broker utilise un certificat d'une AC reconnue publiquement, Node.js lui fait déjà confiance grâce à sa liste de racines Mozilla intégrée. Le broker ConnectMQ utilise un certificat Let's Encrypt : vous n'avez donc aucun fichier d'AC à téléverser, il suffit d'activer TLS et de laisser la vérification active.
Si Node-RED n'est pas encore installé, suivez d'abord notre guide pour installer Node-RED.
Choix du port et du protocole
| Option | Champ Server | Port | Quand l'utiliser |
|---|---|---|---|
| MQTT sur TLS | broker.connectmq.com |
8883 | Par défaut pour Node-RED sur serveurs, PC et passerelles |
| WebSocket sécurisé | wss://broker.connectmq.com:8084/mqtt |
8084 | Réseaux qui bloquent le 8883 mais autorisent un trafic de type HTTPS |
| MQTT en clair | broker.connectmq.com |
1883 | Tests locaux sur le serveur public uniquement |
Configuration Node-RED MQTT TLS pas à pas
Étape 1 : créer le nœud broker
Faites glisser un nœud mqtt in dans l'espace de travail et double-cliquez dessus. À côté de Server, choisissez Add new mqtt-broker et cliquez sur l'icône crayon.
Dans l'onglet Connection :
- Server :
broker.connectmq.com - Port :
8883 - Connect automatically : coché
- Use TLS : coché
- Protocol : MQTT V5 (ou V3.1.1 si vos autres clients en ont besoin)
- Client ID : le client ID généré dans le portail du broker (
YOUR_CLIENT_ID). Ne le laissez jamais vide pour un broker privé et ne le réutilisez jamais dans un autre client, sinon les deux connexions ne cesseront de se déconnecter mutuellement. - Keep Alive : 60 secondes est une valeur par défaut raisonnable.
Étape 2 : ajouter la configuration TLS
Quand vous cochez Use TLS, un champ TLS Configuration apparaît. Choisissez Add new tls-config et cliquez sur l'icône crayon :
- Certificate / Private Key : laissez vides. Ces champs servent à l'authentification par certificat client (TLS mutuel), que ConnectMQ n'utilise pas ; il authentifie par nom d'utilisateur et mot de passe via TLS.
- CA Certificate : laissez vide pour les brokers reconnus publiquement. Ne téléversez votre fichier d'AC que pour un broker privé doté de sa propre AC.
- Verify server certificate : coché. C'est la case la plus importante de la page.
- Server Name :
broker.connectmq.com. Node.js déduit normalement le SNI du champ serveur, mais le définir explicitement évite les surprises. - Name : un libellé descriptif comme
Cloud broker TLS, pour pouvoir réutiliser le nœud dans d'autres configurations de broker.
Cliquez sur Add pour revenir au nœud broker.
Étape 3 : saisir les identifiants
Dans l'onglet Security du nœud broker, saisissez le Username et le Password issus du portail. Node-RED les stocke dans flows_cred.json, séparément du flow, et ils ne sont jamais inclus lors de l'export des flows. Définissez credentialSecret dans settings.js pour que ce fichier soit chiffré avec une clé que vous maîtrisez plutôt qu'avec une clé générée automatiquement ; sinon, déplacer le projet vers une autre machine peut vous laisser avec des identifiants illisibles.
Étape 4 : réglages MQTT 5 optionnels
Avec MQTT V5 sélectionné, des options supplémentaires apparaissent :
- Session Expiry sur le nœud broker : la durée pendant laquelle le broker conserve vos abonnements et les messages QoS 1/2 en file d'attente après une déconnexion. Associé à un client ID fixe et à clean start désactivé, ce réglage permet à une instance Node-RED redémarrée de récupérer les messages manqués.
- Onglet Messages : messages de naissance (birth), de fermeture (close) et de dernière volonté (will). Un message de naissance retenu comme
{"status":"online"}et un message will{"status":"offline"}sur un topic de statut vous donnent un indicateur de santé simple. - Options de mqtt in : gestion des retained messages, « no local » (ne pas recevoir ses propres publications) et « retain as published ».
- Options de mqtt out : expiration du message, type de contenu, topic de réponse, données de corrélation et propriétés utilisateur.
Notre présentation des fonctionnalités de MQTT 5 détaille chacune de ces options.
Étape 5 : déployer et vérifier
Pointez le nœud mqtt in vers un topic comme factory/line1/#, reliez-le à un nœud debug et cliquez sur Deploy. En quelques secondes, le statut du nœud doit passer à un « connected » vert. S'il affiche « connecting » indéfiniment ou « disconnected », passez directement à la section de dépannage ci-dessous.
Flow d'exemple importable
Importez ce flow (menu, Import, coller) pour obtenir une configuration TLS complète en une seule étape. Il utilise le serveur MQTT public gratuit via TLS avec un accès anonyme, il fonctionne donc immédiatement. Remplacez 8b2f par vos propres caractères aléatoires ; pour un broker privé, changez le client ID et ajoutez les identifiants dans l'onglet Security.
[
{
"id": "f1e2d3c4b5a69701",
"type": "tls-config",
"name": "ConnectMQ TLS",
"cert": "",
"key": "",
"ca": "",
"certname": "",
"keyname": "",
"caname": "",
"servername": "broker.connectmq.com",
"verifyservercert": true,
"alpnprotocol": ""
},
{
"id": "f1e2d3c4b5a69702",
"type": "mqtt-broker",
"name": "ConnectMQ over TLS",
"broker": "broker.connectmq.com",
"port": "8883",
"tls": "f1e2d3c4b5a69701",
"clientid": "nodered-tls-8b2f",
"autoConnect": true,
"usetls": true,
"protocolVersion": "5",
"keepalive": "60",
"cleansession": true,
"autoUnsubscribe": true,
"sessionExpiry": "",
"birthTopic": "connectmq/demo/8b2f/nodered/status",
"birthQos": "1",
"birthRetain": "true",
"birthPayload": "{\"status\":\"online\"}",
"willTopic": "connectmq/demo/8b2f/nodered/status",
"willQos": "1",
"willRetain": "true",
"willPayload": "{\"status\":\"offline\"}"
},
{
"id": "f1e2d3c4b5a69703",
"type": "inject",
"name": "Every 10 s",
"props": [{ "p": "payload" }],
"repeat": "10",
"once": true,
"onceDelay": "2",
"topic": "",
"payload": "",
"payloadType": "date",
"x": 140,
"y": 80,
"wires": [["f1e2d3c4b5a69704"]]
},
{
"id": "f1e2d3c4b5a69704",
"type": "change",
"name": "Build reading",
"rules": [
{ "t": "set", "p": "payload", "pt": "msg", "to": "{\"ts\": payload, \"value\": $round($random() * 100, 1)}", "tot": "jsonata" },
{ "t": "set", "p": "topic", "pt": "msg", "to": "connectmq/demo/8b2f/nodered/reading", "tot": "str" }
],
"x": 330,
"y": 80,
"wires": [["f1e2d3c4b5a69705"]]
},
{
"id": "f1e2d3c4b5a69705",
"type": "mqtt out",
"name": "Publish over TLS",
"topic": "",
"qos": "1",
"retain": "false",
"broker": "f1e2d3c4b5a69702",
"x": 540,
"y": 80,
"wires": []
},
{
"id": "f1e2d3c4b5a69706",
"type": "mqtt in",
"name": "Subscribe over TLS",
"topic": "connectmq/demo/8b2f/nodered/#",
"qos": "1",
"datatype": "auto-detect",
"broker": "f1e2d3c4b5a69702",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 160,
"y": 160,
"wires": [["f1e2d3c4b5a69707"]]
},
{
"id": "f1e2d3c4b5a69707",
"type": "debug",
"name": "Show",
"active": true,
"tosidebar": true,
"console": false,
"complete": "true",
"targetType": "full",
"x": 370,
"y": 160,
"wires": []
}
]
Après le déploiement, la barre latérale de débogage affiche le statut « online » retenu et une nouvelle mesure toutes les dix secondes, le tout transitant via TLS. L'espace public est visible par tous : ne l'utilisez que pour des données de test.
Utiliser plutôt le WebSocket sécurisé
Si votre réseau bloque le port 8883, saisissez une URL complète dans le champ Server : wss://broker.connectmq.com:8084/mqtt. Node-RED ignore alors le champ port et se connecte via WebSocket sécurisé sur le port 8084, TLS étant géré avec la même vérification du certificat. C'est fréquent sur les réseaux d'entreprise ; voir MQTT sur WebSocket pour le contexte.
Dépannage Node-RED MQTT TLS
- Bloqué sur « connecting » : le port 8883 est probablement bloqué. Testez depuis l'hôte Node-RED avec
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.comet essayez WSS sur le port 8084. - « unable to get local issuer certificate » dans le journal : Node.js ne parvient pas à construire la chaîne. Cause habituelle : une inspection TLS sur le réseau, ou un fichier d'AC téléversé qui a remplacé les valeurs par défaut par la mauvaise racine. Supprimez le fichier d'AC pour les brokers reconnus publiquement.
- « Hostname/IP does not match certificate's altnames » : vous avez saisi une adresse IP ou un alias. Utilisez le nom d'hôte.
- « Connection refused: Not authorized » ou un code de raison après la connexion : TLS fonctionne ; ce sont les identifiants ou le client ID qui sont erronés. Recopiez-les depuis le portail.
- Se connecte puis se déconnecte toutes les quelques secondes : un autre client utilise le même client ID, souvent une seconde instance Node-RED ou un script de test oublié.
- « Use TLS » décoché alors que le port est 8883 : la connexion se bloque ou tombe, car le broker attend un handshake TLS sur le port 8883 ; « Use TLS » doit donc être coché.
Le guide Node-RED MQTT ne se connecte pas et la résolution des échecs de handshake TLS MQTT couvrent d'autres cas. Ne décochez jamais Verify server certificate pour faire disparaître une erreur : cela masque la vraie cause et supprime la protection contre les brokers imposteurs.
Durcir le reste de votre installation Node-RED
Une connexion chiffrée au broker n'est qu'une couche. Protégez aussi l'éditeur avec adminAuth, servez-le en HTTPS, tenez Node-RED et ses nœuds à jour, et définissez credentialSecret. Notre guide pour sécuriser Node-RED couvre chaque étape, et le tutoriel Node-RED MQTT montre comment structurer topics et payloads pour des flows plus importants.
Exécutez vos flows Node-RED sur ConnectMQ
Node-RED est un client MQTT : il a besoin d'un broker fiable à l'autre bout. Un broker MQTT managé comme ConnectMQ vous offre TLS sur le port 8883, le WebSocket sécurisé sur le port 8084, un certificat renouvelé automatiquement et un portail doté d'un explorateur de topics en direct et d'un tableau de bord pour vérifier ce que publient vos flows. Inscrivez-vous sur app.connectmq.com, choisissez l'offre gratuite Serverless sans carte bancaire, créez un broker et collez le nom d'utilisateur, le mot de passe et le client ID générés dans le nœud broker. Pour comparer d'abord les modèles d'hébergement, lisez notre guide du broker MQTT cloud.
Questions fréquentes
Faut-il téléverser un certificat d'AC dans Node-RED pour ConnectMQ ?
Non. Son certificat est émis par Let's Encrypt, auquel Node.js fait déjà confiance. Activez TLS, laissez « Verify server certificate » coché et laissez le champ CA vide.
Mes identifiants MQTT sont-ils inclus lorsque j'exporte un flow ?
Non. Node-RED stocke les identifiants séparément dans flows_cred.json et les exclut des exports : vous devez donc les ressaisir après l'import sur une autre instance.
Plusieurs instances Node-RED peuvent-elles partager une même configuration de broker ?
Elles peuvent partager les mêmes réglages, mais chaque instance a besoin de son propre client ID unique. Deux clients ayant le même ID ne cesseront de se déconnecter mutuellement.
Faut-il choisir MQTT V5 ou V3.1.1 dans le nœud broker ?
Choisissez V5, sauf si une autre partie de votre système exige 3.1.1. V5 ajoute l'expiration de session, l'expiration des messages, les propriétés utilisateur et des codes de raison plus clairs, et ConnectMQ prend en charge les deux versions.



