mTLS MQTT : le TLS mutuel avec certificats clients X.509 expliqué

Le mTLS MQTT (TLS mutuel) authentifie les deux côtés d'une connexion par certificats : le broker prouve son identité à l'appareil, et l'appareil prouve la sienne au broker avec son propre certificat client X.509. Cet article explique ce fonctionnement, présente une configuration Mosquitto complète avec OpenSSL et vous aide à décider si le mTLS vaut son coût d'exploitation ou si un nom d'utilisateur et un mot de passe via TLS conviennent mieux à votre flotte.

TLS serveur ou TLS mutuel

Avec MQTT sur TLS classique, seul le broker présente un certificat. Le client le vérifie, le tunnel est chiffré, puis le client s'authentifie dans ce tunnel avec les champs nom d'utilisateur et mot de passe du paquet MQTT CONNECT. C'est ainsi que fonctionnent la plupart des brokers cloud, comme l'explique en détail notre guide de configuration TLS MQTT.

Avec le TLS mutuel, le broker envoie en plus un CertificateRequest pendant le handshake. Le client répond avec son propre certificat et signe une partie du handshake avec la clé privée correspondante. Le broker vérifie que le certificat client remonte à une AC de confiance, qu'il est dans sa période de validité et qu'il n'a pas été révoqué. Si un contrôle échoue, la connexion TCP est fermée avant qu'un seul paquet MQTT ne soit traité.

Pourquoi les équipes choisissent le mTLS MQTT

L'argument le plus fort en faveur du mTLS est que le secret de l'appareil ne quitte jamais l'appareil. Un mot de passe est transmis à chaque connexion, si bien qu'un broker compromis, un journal mal configuré ou un proxy de débogage peut le capturer. Une clé privée ne fait que produire des signatures. Si la clé réside dans un élément sécurisé comme un ATECC608 ou un TPM, le firmware ne peut même pas la lire, ce qui rend le clonage d'un appareil bien plus difficile.

Autres avantages :

• Identité liée au matériel : vous pouvez émettre les certificats en usine et lier le common name du certificat au numéro de série.
• Rejet précoce : les clients non authentifiés sont rejetés avant que le broker n'analyse MQTT, ce qui réduit la surface d'attaque.
• Outillage standard : X.509 est compris par toutes les bibliothèques TLS, tous les répartiteurs de charge et toutes les équipes sécurité.

Le coût caché : le cycle de vie des certificats

Le mTLS déplace la complexité de la base d'utilisateurs du broker vers une infrastructure à clé publique. Avant de l'adopter, soyez lucide sur ces tâches :

1. Exploiter une AC : garder la clé racine hors ligne, utiliser une AC intermédiaire pour l'émission, et protéger les deux.
2. Provisionner : générer une clé sur chaque appareil (idéalement sur l'appareil lui-même), créer une CSR, la signer et installer le certificat.
3. Renouveler : les certificats expirent. Les appareils doivent pouvoir obtenir un nouveau certificat avant l'expiration de l'ancien, même s'ils sont restés un an sur une étagère.
4. Révoquer : lorsqu'un appareil est volé ou mis hors service, le broker doit cesser d'accepter son certificat. Mosquitto prend en charge un fichier CRL ; beaucoup d'équipes préfèrent des certificats à courte durée de vie.
5. Renouveler l'AC : tôt ou tard, l'AC émettrice elle-même doit être remplacée, ce qui implique de distribuer une nouvelle ancre de confiance au broker et de nouveaux certificats à chaque appareil.

Si l'une de ces étapes est mal faite, vous obtenez des pannes qui ressemblent à de mystérieux échecs de handshake sur une partie de la flotte. Pour la plupart des petits et moyens projets, des identifiants uniques par appareil via TLS, renouvelés selon un calendrier, offrent un meilleur rapport sécurité/effort. Nos guides sur l'authentification MQTT par nom d'utilisateur et mot de passe et sur la rotation des identifiants MQTT montrent comment bien le faire.

Mettre en place le mTLS MQTT sur Mosquitto

La configuration de laboratoire suivante utilise Eclipse Mosquitto, qui prend en charge nativement l'authentification par certificat client. Exécutez-la sur une machine que vous maîtrisez.

Étape 1 : créer une AC privée

mkdir -p ~/mqtt-pki && cd ~/mqtt-pki

# Clé de l'AC et certificat d'AC auto-signé (10 ans)
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/CN=Lab MQTT Root CA" -out ca.crt

Étape 2 : émettre le certificat du broker

Le certificat du broker a besoin d'un Subject Alternative Name correspondant au nom d'hôte qu'utiliseront les clients.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=mqtt.lab.local" -out server.csr

cat > server.ext <<'EOF'
subjectAltName = DNS:mqtt.lab.local
extendedKeyUsage = serverAuth
EOF

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 825 -sha256 -extfile server.ext -out server.crt

Étape 3 : émettre un certificat d'appareil

Utilisez l'ID de l'appareil comme common name. En production, la clé serait générée sur l'appareil et seule la CSR en sortirait.

openssl genrsa -out sensor-001.key 2048
openssl req -new -key sensor-001.key -subj "/CN=sensor-001" -out sensor-001.csr

cat > client.ext <<'EOF'
extendedKeyUsage = clientAuth
EOF

openssl x509 -req -in sensor-001.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 365 -sha256 -extfile client.ext -out sensor-001.crt

Étape 4 : configurer le broker

# /etc/mosquitto/conf.d/mtls.conf
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

# Exiger un certificat client signé par cafile
require_certificate true

# Utiliser le CN du certificat comme nom d'utilisateur MQTT (pour les ACL)
use_identity_as_username true

# Optionnel : rejeter les certificats révoqués
# crlfile /etc/mosquitto/certs/ca.crl

Copiez les fichiers dans /etc/mosquitto/certs/, rendez la clé lisible par l'utilisateur mosquitto et redémarrez le service. Avec use_identity_as_username, le CN sensor-001 devient le nom d'utilisateur, ce qui permet d'écrire des règles ACL par appareil.

Étape 5 : se connecter avec le certificat client

mosquitto_sub -h mqtt.lab.local -p 8883 --cafile ca.crt \
  --cert sensor-001.crt --key sensor-001.key \
  -i sensor-001 -t "lab/sensor-001/#" -v

Les trois mêmes fichiers fonctionnent dans le code. En Python avec paho-mqtt 2.x :

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="sensor-001")
client.tls_set(ca_certs="ca.crt", certfile="sensor-001.crt", keyfile="sensor-001.key")
client.connect("mqtt.lab.local", 8883)
client.publish("lab/sensor-001/temp", "21.4", qos=1)
client.loop(2)
client.disconnect()

Si vous vous connectez sans --cert ni --key, le handshake échoue immédiatement, ce qui permet de vérifier rapidement que require_certificate est actif. Les configurations de laboratoire comme celle-ci utilisent une racine auto-signée ; notre guide sur les certificats auto-signés pour MQTT en détaille les pièges.

Erreurs mTLS courantes

• « certificate required » ou alerte de handshake du broker : le client n'a pas envoyé de certificat. Vérifiez les chemins du certificat et de la clé.
• « unknown ca » : le certificat client a été signé par une AC absente du cafile du broker.
• « unsupported certificate purpose » : le certificat ne comporte pas l'usage étendu de clé clientAuth.
• Clé non correspondante : le fichier de clé n'appartient pas au certificat. Comparez openssl x509 -noout -modulus -in sensor-001.crt | openssl md5 avec la même commande appliquée à la clé.
• Certificat expiré : vérifiez les dates avec openssl x509 -noout -dates -in sensor-001.crt, ainsi que l'horloge de l'appareil.

Quand utiliser le mTLS et quand les identifiants suffisent

Le mTLS convient bien lorsque vous maîtrisez le broker, avez besoin d'une identité adossée au matériel, opérez dans un environnement réglementé qui impose une identité d'appareil par certificat, ou exploitez déjà une PKI. Il est généralement excessif pour les prototypes, les petites flottes et les équipes où personne ne peut prendre en charge le renouvellement des certificats.

ConnectMQ adopte l'approche des identifiants via TLS : le broker présente un certificat Let's Encrypt reconnu publiquement, et chaque client s'authentifie avec un nom d'utilisateur, un mot de passe et un client ID générés dans le portail. Les client IDs sont liés aux identifiants émis, et des échecs de connexion répétés entraînent un blocage d'IP. ConnectMQ ne propose pas d'authentification par certificat client : si le mTLS est une exigence ferme, il vous faudra un broker que vous configurez vous-même, comme Mosquitto ci-dessus. Pour la majorité des projets, cependant, un broker MQTT managé avec des identifiants robustes par appareil supprime bien plus de risques opérationnels que le mTLS n'en ajoute. La vue d'ensemble est présentée dans nos bonnes pratiques de sécurité MQTT.

Démarrer avec ConnectMQ

Si les identifiants via TLS correspondent à votre modèle de menace, ConnectMQ vous offre un broker sécurisé sans exploiter de PKI. Inscrivez-vous sur app.connectmq.com, choisissez l'offre gratuite Serverless sans carte bancaire, créez un broker et connectez-vous sur le port 8883 avec les identifiants générés. Vous pouvez d'abord prototyper sur le serveur MQTT public gratuit, réservé aux tests, à l'adresse broker.connectmq.com, puis passer à des identifiants privés lors de la mise en production.

Questions fréquentes

Le mTLS est-il plus sûr qu'un nom d'utilisateur et un mot de passe via TLS ?

Il supprime le secret partagé du réseau et se combine bien avec le stockage matériel des clés, il résiste donc mieux au vol d'identifiants. La contrepartie est un cycle de vie des certificats que vous devez exploiter de manière fiable.

Peut-on utiliser le mTLS avec un nom d'utilisateur et un mot de passe ?

Oui. Mosquitto, par exemple, peut exiger un certificat client tout en vérifiant le nom d'utilisateur et le mot de passe MQTT, ce qui donne deux facteurs indépendants.

ConnectMQ prend-il en charge l'authentification par certificat client ?

Non. ConnectMQ authentifie les clients avec un nom d'utilisateur, un mot de passe et un client ID générés, envoyés via TLS. Utilisez un broker autogéré si vous avez spécifiquement besoin du mTLS.

Quelle durée de validité donner aux certificats d'appareils ?

Il n'y a pas de réponse unique. Des durées plus courtes réduisent la dépendance à la révocation mais exigent un renouvellement automatisé fiable ; choisissez la période la plus courte que votre processus de renouvellement peut gérer sans risque d'expiration sur le terrain.