Sécuriser Mosquitto : mots de passe, ACL et TLS

Une installation neuve de Mosquitto 2.x refuse les clients distants anonymes, ce qui est un bon début — mais pour l’utiliser réellement, il vous faut trois couches : l’authentification (qui êtes-vous ?), l’autorisation (à quels topics avez-vous droit ?) et le chiffrement (quelqu’un sur le réseau peut-il lire ceci ?). Dans Mosquitto, ce sont le fichier de mots de passe, le fichier ACL et un listener TLS. Ce guide met en place les trois.

Si le broker n’est pas encore installé, commencez par installer Mosquitto ou l’exécuter dans Docker. Les chemins ci-dessous supposent une installation par paquet sous Linux ; dans Docker, utilisez /mosquitto/config/ au lieu de /etc/mosquitto/.

1. Créer un fichier de mots de passe avec mosquitto_passwd

mosquitto_passwd enregistre les noms d’utilisateur avec des hachages de mots de passe salés (jamais en clair). Créez le fichier avec le premier utilisateur, puis ajoutez-en d’autres :

# -c creates a NEW file and overwrites any existing one — first user only
sudo mosquitto_passwd -c /etc/mosquitto/passwd alice

# add or update users (prompts for the password)
sudo mosquitto_passwd /etc/mosquitto/passwd sensor-01

# non-interactive, e.g. in provisioning scripts
sudo mosquitto_passwd -b /etc/mosquitto/passwd bob 'S3cure-pass'

# delete a user
sudo mosquitto_passwd -D /etc/mosquitto/passwd bob

Évitez -b sur les machines partagées : le mot de passe se retrouve dans l’historique du shell et dans la liste des processus. Verrouillez le fichier pour que seul le broker puisse le lire :

sudo chown mosquitto:mosquitto /etc/mosquitto/passwd
sudo chmod 0700 /etc/mosquitto/passwd

Indiquez ensuite au broker de l’utiliser :

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

sudo systemctl restart mosquitto

# should fail with "not authorised"
mosquitto_pub -h localhost -t test -m hi

# should succeed
mosquitto_pub -h localhost -u alice -P 'your-password' -t test -m hi

2. Restreindre les topics avec un fichier ACL

Un fichier de mots de passe seul permet à chaque utilisateur authentifié de lire et d’écrire sur tous les topics. Un fichier ACL limite cela. Dès que acl_file est défini, tout ce qui n’est pas explicitement autorisé est refusé.

# --- pattern rules apply to every authenticated client ---
# each device may read and write only below its own username
pattern readwrite devices/%u/#
# each client may read its own command topic, keyed by client ID
pattern read commands/%c

# --- user-specific rules ---
user alice
topic readwrite #

user dashboard
topic read devices/#
topic write commands/+

user sensor-01
topic write telemetry/sensor-01/#

Activez-le à côté du fichier de mots de passe :

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

Deux comportements piègent souvent. D’abord, une publication sur un topic interdit est silencieusement ignorée en MQTT 3.1.1 — le client ne voit aucune erreur (les clients MQTT 5 reçoivent un code de raison dans le PUBACK en QoS 1/2). Ensuite, un abonnement interdit est refusé dans le SUBACK, ce que beaucoup de bibliothèques clientes ne remontent pas. Quand « les messages n’arrivent tout simplement pas », vérifiez d’abord l’ACL et lancez le broker avec log_type all pendant le débogage. Utilisez le testeur de topics pour vérifier quels topics couvre réellement un filtre comme devices/+/#.

3. Chiffrer le trafic avec TLS

Sans TLS, noms d’utilisateur, mots de passe et payloads traversent le réseau en clair. La convention est MQTT sur TLS sur le port 8883 (voir les ports MQTT). Il vous faut un certificat, sa clé privée et — pour les configurations auto-signées — le certificat de la CA.

# MQTT over TLS
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key
# cafile is only needed for self-signed / private CA chains or client certificates
# cafile /etc/mosquitto/certs/ca.crt

# Secure WebSockets for browser clients
listener 8884
protocol websockets
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key

Une fois TLS fonctionnel, supprimez le listener 1883 en clair ou bloquez-le au pare-feu (ou liez-le à localhost avec listener 1883 127.0.0.1) pour que les identifiants ne puissent pas fuiter par ce biais. Pour exiger des certificats client (TLS mutuel), ajoutez cafile et require_certificate true au listener ; ajouter use_identity_as_username true fait du CN du certificat le nom d’utilisateur pris en compte par les ACL.

Testez depuis un client :

# public CA (e.g. Let's Encrypt): use the system trust store
mosquitto_sub -h mqtt.example.com -p 8883 --capath /etc/ssl/certs \
  -u alice -P 'your-password' -t 'devices/#' -v

# self-signed / private CA
mosquitto_sub -h mqtt.example.com -p 8883 --cafile ca.crt \
  -u alice -P 'your-password' -t 'devices/#' -v

Le nom d’hôte passé à -h doit correspondre au CN/SAN du certificat, sinon la vérification échoue. D’autres options CLI figurent dans l’aide-mémoire mosquitto_pub/sub.

Utiliser un certificat Let’s Encrypt

Avec un certificat reconnu publiquement, les clients n’ont pas besoin d’un fichier de CA spécifique. Obtenez-en un avec certbot pour le nom d’hôte de votre broker (le port 80 doit être joignable pour le challenge HTTP), puis pointez Mosquitto vers les fichiers live :

listener 8883
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile  /etc/letsencrypt/live/mqtt.example.com/privkey.pem

• Utilisez fullchain.pem, pas cert.pem — les clients ont besoin du certificat intermédiaire.
• L’utilisateur mosquitto doit pouvoir lire la clé ; par défaut, /etc/letsencrypt n’est accessible qu’à root. Beaucoup de configurations copient les fichiers dans /etc/mosquitto/certs/ via un deploy hook de certbot et y définissent le propriétaire.
• Les certificats se renouvellent tous les quelques mois. Ajoutez systemctl reload mosquitto au deploy hook pour que le broker prenne en compte le nouveau certificat.

Tout assembler

listener 1883 127.0.0.1

listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile  /etc/mosquitto/certs/privkey.pem

listener 8884
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile  /etc/mosquitto/certs/privkey.pem

allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

Plutôt que de l’éditer à la main, vous pouvez le générer avec le générateur de mosquitto.conf. Pour une vue d’ensemble — politiques de client ID, limites de débit, supervision — lisez les bonnes pratiques de sécurité MQTT, et si des clients se mettent à échouer avec « not authorised », le guide des erreurs de connexion explique chaque code.

Questions fréquentes