mTLS en MQTT: TLS mutuo con certificados de cliente X.509 explicado

El mTLS en MQTT (TLS mutuo) autentica ambos extremos de una conexión con certificados: el broker demuestra su identidad al dispositivo y el dispositivo demuestra la suya al broker con su propio certificado de cliente X.509. Este artículo explica cómo funciona, muestra una configuración completa de Mosquitto con OpenSSL y te ayuda a decidir si el mTLS compensa su coste operativo o si usuario y contraseña sobre TLS es la mejor opción para tu flota.

TLS de servidor frente a TLS mutuo

En el MQTT sobre TLS habitual, solo el broker presenta un certificado. El cliente lo verifica, el túnel se cifra y después el cliente se autentica dentro de ese túnel con los campos de usuario y contraseña del paquete CONNECT de MQTT. Así funcionan la mayoría de los brokers en la nube, y se explica en detalle en nuestra guía de configuración TLS en MQTT.

Con TLS mutuo, el broker también envía un CertificateRequest durante el handshake. El cliente responde con su propio certificado y firma parte del handshake con la clave privada correspondiente. El broker comprueba que el certificado del cliente encadena con una CA de confianza, que está dentro de su periodo de validez y que no ha sido revocado. Si alguna comprobación falla, la conexión TCP se cierra antes de procesar un solo paquete MQTT.

Por qué los equipos eligen mTLS en MQTT

El argumento más fuerte a favor del mTLS es que el secreto del dispositivo nunca sale de él. Una contraseña se transmite en cada conexión, así que un broker comprometido, un log mal configurado o un proxy de depuración pueden capturarla. Una clave privada solo produce firmas. Si la clave reside en un elemento seguro como un ATECC608 o un TPM, ni siquiera el firmware puede leerla, lo que hace mucho más difícil clonar un dispositivo.

Otras ventajas:

• Identidad ligada al hardware: puedes emitir certificados en fábrica y vincular el common name del certificado al número de serie.
• Rechazo temprano: los clientes no autenticados se descartan antes de que el broker analice MQTT, lo que reduce la superficie de ataque.
• Herramientas estándar: X.509 lo entienden todas las librerías TLS, los balanceadores de carga y los equipos de seguridad.

El coste oculto: el ciclo de vida de los certificados

El mTLS traslada la complejidad desde la base de datos de usuarios del broker a una infraestructura de clave pública. Antes de adoptarlo, sé honesto con estas tareas:

1. Operar una CA: mantén la clave raíz offline, usa un intermedio para emitir y protege ambos.
2. Aprovisionar: genera una clave en cada dispositivo (idealmente en el propio dispositivo), crea una CSR, fírmala e instala el certificado.
3. Renovar: los certificados caducan. Los dispositivos necesitan una forma de obtener un nuevo certificado antes de que expire el anterior, incluso si han pasado un año en una estantería.
4. Revocar: cuando un dispositivo se roba o se retira, el broker debe dejar de aceptar su certificado. Mosquitto admite un archivo CRL; muchos equipos prefieren certificados de vida corta.
5. Rotar la CA: tarde o temprano hay que sustituir la propia CA emisora, lo que implica distribuir un nuevo ancla de confianza al broker y nuevos certificados a cada dispositivo.

Si fallas en cualquiera de ellas, tendrás cortes que parecen misteriosos fallos de handshake en parte de la flota. Para la mayoría de los proyectos pequeños y medianos, las credenciales únicas por dispositivo sobre TLS, rotadas periódicamente, ofrecen una mejor relación entre seguridad y esfuerzo. Nuestras guías de autenticación MQTT con usuario y contraseña y de rotación de credenciales MQTT muestran cómo hacerlo bien.

Cómo configurar mTLS en MQTT con Mosquitto

La siguiente configuración de laboratorio usa Eclipse Mosquitto, que admite de forma nativa la autenticación por certificado de cliente. Ejecútala en una máquina que controles.

Paso 1: crea una CA privada

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

# Clave de la CA y certificado de CA autofirmado (10 años)
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

Paso 2: emite el certificado del broker

El certificado del broker necesita un Subject Alternative Name que coincida con el hostname que usarán los clientes.

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

Paso 3: emite un certificado de dispositivo

Usa el ID del dispositivo como common name. En producción, la clave se generaría en el dispositivo y solo saldría de él la CSR.

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

Paso 4: configura el 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

# Exige un certificado de cliente firmado por cafile
require_certificate true

# Usa el CN del certificado como usuario MQTT (para las ACL)
use_identity_as_username true

# Opcional: rechaza certificados revocados
# crlfile /etc/mosquitto/certs/ca.crl

Copia los archivos en /etc/mosquitto/certs/, haz que la clave sea legible por el usuario mosquitto y reinicia el servicio. Con use_identity_as_username, el CN sensor-001 se convierte en el usuario, así que puedes escribir reglas ACL por dispositivo.

Paso 5: conéctate con el certificado de cliente

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

Los mismos tres archivos sirven en código. En Python con 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 te conectas sin --cert y --key, el handshake falla de inmediato, lo que es una forma rápida de confirmar que require_certificate está activo. Las configuraciones de laboratorio como esta usan una raíz autofirmada; nuestra guía de certificados autofirmados para MQTT cubre sus trampas.

Errores comunes de mTLS

• "certificate required" o alerta de handshake del broker: el cliente no envió un certificado. Revisa las rutas del certificado y de la clave.
• "unknown ca": el certificado del cliente lo firmó una CA que no está en el cafile del broker.
• "unsupported certificate purpose": al certificado le falta el extended key usage clientAuth.
• Clave que no coincide: el archivo de clave no pertenece al certificado. Compara openssl x509 -noout -modulus -in sensor-001.crt | openssl md5 con el mismo comando sobre la clave.
• Certificado caducado: comprueba las fechas con openssl x509 -noout -dates -in sensor-001.crt y revisa el reloj del dispositivo.

Cuándo usar mTLS y cuándo bastan las credenciales

El mTLS encaja bien cuando controlas el broker, necesitas una identidad respaldada por hardware, operas en un entorno regulado que exige identidad de dispositivo basada en certificados o ya tienes una PKI. Suele ser excesivo para prototipos, flotas pequeñas y equipos sin nadie que se responsabilice de renovar certificados.

ConnectMQ sigue el enfoque de credenciales sobre TLS: el broker presenta un certificado de Let's Encrypt de confianza pública y cada cliente se autentica con un usuario, una contraseña y un client ID generados en el portal. Los client ID están vinculados a las credenciales emitidas, y los logins fallidos repetidos provocan el bloqueo de la IP. ConnectMQ no ofrece autenticación por certificado de cliente, así que si el mTLS es un requisito imprescindible necesitarás un broker que configures tú mismo, como Mosquitto según lo mostrado arriba. Para la mayoría de los proyectos, sin embargo, un broker MQTT gestionado con credenciales sólidas por dispositivo elimina mucho más riesgo operativo del que añade el mTLS. La visión general está en nuestras buenas prácticas de seguridad MQTT.

Empieza con ConnectMQ

Si las credenciales sobre TLS encajan con tu modelo de amenazas, ConnectMQ te da un broker protegido sin operar ninguna PKI. Regístrate en app.connectmq.com, elige el plan gratuito Serverless sin tarjeta de crédito, crea un broker y conéctate por el puerto 8883 con las credenciales generadas. Puedes hacer primero el prototipo en el servidor MQTT público gratuito en broker.connectmq.com y pasar a credenciales privadas cuando entres en producción.

Preguntas frecuentes

¿Es el mTLS más seguro que usuario y contraseña sobre TLS?

Elimina el secreto compartido de la red y combina bien con el almacenamiento de claves en hardware, así que resiste mejor el robo de credenciales. La contrapartida es un ciclo de vida de certificados que debes operar de forma fiable.

¿Puedo usar mTLS junto con usuario y contraseña?

Sí. Mosquitto, por ejemplo, puede exigir un certificado de cliente y seguir comprobando el usuario y la contraseña MQTT, lo que da dos factores independientes.

¿ConnectMQ admite autenticación por certificado de cliente?

No. ConnectMQ autentica a los clientes con un usuario, una contraseña y un client ID generados y enviados sobre TLS. Usa un broker autogestionado si necesitas específicamente mTLS.

¿Cuánto tiempo deben ser válidos los certificados de dispositivo?

No hay una única respuesta. Las vidas más cortas reducen la dependencia de la revocación, pero requieren una renovación automática fiable; elige el periodo más corto que tu proceso de renovación pueda gestionar sin riesgo de caducidad en campo.