¿Qué es MQTTS? MQTT sobre TLS para IoT energético

MQTTS es una forma abreviada de llamar a MQTT transportado sobre Transport Layer Security (TLS). No es otra versión de MQTT. Los paquetes MQTT no cambian; TLS los envuelve. Si el cliente verifica el certificado, TLS cifra la conexión, detecta alteraciones y demuestra a qué bróker se ha conectado.

En una instalación energética, compruebe tres cosas por separado: la Gateway llegó al bróker correcto; solo puede publicar en sus propios temas; y la plataforma almacenó el valor, unidad y marca temporal correctos. Un indicador verde de «conectado» solo demuestra la primera mitad de la primera comprobación.

No confunda MQTTS con MQTT-SN, antes llamado MQTT-S. MQTT-SN es un protocolo distinto para redes de sensores y transportes que no son TCP/IP (especificaciones MQTT).

MQTT y MQTTS de un vistazo

La especificación MQTT 5.0 indica que los puertos TCP 8883 y 1883 están registrados en IANA para MQTT sobre TLS y MQTT sin TLS. Sus nombres de servicio son secure-mqtt y mqtt. El puerto es una convención. La seguridad depende del establecimiento de TLS y la verificación del certificado; un servicio en 8883 también puede estar mal configurado.

MQTT 5 también define autenticación mejorada mediante el paquete AUTH. Que demuestre la identidad del servidor depende del método: uno de desafío-respuesta como SCRAM puede hacerlo, un token simple no. Pocos brókeres lo implementan; en casi todos los despliegues, la identidad del bróker procede del certificado TLS.

Versiones de TLS

Use TLS 1.2 o 1.3. RFC 8996 retiró TLS 1.0 y 1.1 en 2021. Mosquitto permite TLS 1.3 y 1.2 por defecto (mosquitto.conf), y AWS IoT Core acepta ambos. Un cliente limitado a TLS 1.0 falla en el establecimiento de la conexión con una alerta de versión de protocolo. Suele indicar firmware antiguo, no un certificado incorrecto.

Dónde termina TLS

TLS protege un tramo: desde el cliente hasta el componente que termina TLS. Un equilibrador de carga en la nube que termina TLS y reenvía TCP sin cifrar al bróker deja sin cifrar ese tramo interno, a menos que vuelva a cifrarlo. El bróker deja de ver el certificado del cliente, de modo que las ACL basadas en él ya no funcionan. Averigüe dónde termina TLS antes de diseñar la identidad sobre certificados de cliente. Si la carga útil debe seguir siendo confidencial después del bróker, cífrela en la aplicación con claves propias. TLS por tramos no equivale a cifrado de extremo a extremo.

Cuatro comprobaciones de seguridad

1. Confianza e identidad del bróker

El cliente necesita una raíz de confianza, normalmente el certificado de la autoridad (CA) que firmó el del bróker. Valida la cadena, las fechas notBefore y notAfter definidas en RFC 5280, y el nombre. RFC 9525 describe la comparación entre el identificador de referencia configurado, normalmente el nombre DNS introducido, y los nombres alternativos del certificado.

Configure el nombre de dominio completo del bróker, no la dirección IP a la que resolvió un día concreto. Un certificado de broker.example.net no coincide con 203.0.113.40. Envíe Server Name Indication (SNI) si el servicio aloja varios nombres en una dirección; AWS IoT Core necesita SNI para dominios personalizados y extremos configurables.

Confíe en la CA emisora en lugar de fijar el certificado final del bróker. Si se fija ese certificado, la Gateway falla con cada renovación.

2. Identidad del cliente

Dé una identidad propia a cada Gateway: un certificado y clave privada de cliente, o un usuario y contraseña únicos. Nunca comparta un certificado entre toda una flota: revocarlo por una instalación desconectaría a todas.

En Mosquitto, el servicio TLS y la obligación de presentar un certificado de cliente son ajustes distintos. require_certificate true rechaza clientes sin certificado válido y use_identity_as_username true convierte el CN del certificado en el usuario MQTT que utilizará la ACL (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

Desde Mosquitto 2.0, configurar un servicio hace que rechace clientes anónimos, salvo que se establezca allow_anonymous true.

3. Autorización de temas

La autenticación establece quién es el cliente. La autorización determina en qué temas puede publicar y a cuáles puede suscribirse. Asigne a cada Gateway su propia rama y ninguna otra. Con el servicio anterior, el CN del certificado pasa a ser %u en un patrón ACL:

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

La Gateway gw-0417 puede publicar en sites/gw-0417/telemetry/ y leer su tema de órdenes. No puede escribir en otra instalación ni en su propio tema de órdenes. El complemento Dynamic Security de Mosquitto expresa las mismas reglas como roles con permisos de publicación, recepción y suscripción separados.

Pruebe una publicación permitida y otra denegada. La versión del protocolo cambia la respuesta. MQTT 3.1.1, sección 3.3.5, no ofrece al bróker una forma de comunicar la denegación: debe confirmar normalmente o cerrar la conexión. Si el bróker elige la confirmación normal, un cliente 3.1.1 puede confundir una publicación QoS 1 denegada con un éxito. Si el bróker cierra la conexión, el cliente ve una desconexión sin un motivo de rechazo de la publicación. MQTT 5 devuelve el código de motivo 0x87 (no autorizado) en PUBACK. En 3.1.1, demuestre la denegación con un segundo cliente suscrito al tema de destino.

4. Aceptación por la aplicación

Envíe una lectura conocida y búsquela en la aplicación receptora: el historiador, plataforma energética o base de datos del cliente. Compare origen, marca temporal, valor y unidad. El registro del bróker solo demuestra que recibió el mensaje.

Ejemplo con nombres ficticios: la Gateway gw-0417 lee 412,6 kW del contador principal a las 14:03:00 UTC y publica en 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"
}

El registro de la plataforma debe mostrar el mismo dispositivo, 412,6, kW y 14:03:00Z. Si muestra 14:03:07, ha asignado la hora de llegada y perdido la de origen. Si muestra 0,4126, una conversión de unidades dividió entre 1.000. Ninguno de los dos errores es visible en el bróker.

Pruebas desde la línea de comandos

Dos herramientas permiten detectar la mayoría de los fallos de puesta en servicio. Ejecútelas desde un portátil en el mismo segmento de red que la Gateway.

Compruebe la cadena de certificados y el nombre de host con 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 resultado correcto muestra el protocolo negociado (TLSv1.2 o TLSv1.3) y verificación satisfactoria. Repita con -verify_hostname wrong.example.net y con otro archivo CA. Ambos intentos deben fallar. Si funcionan, no se está verificando el certificado.

Después publique con las credenciales de la Gateway mediante 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 salida de -d muestra el CONNACK y el código de motivo de PUBACK. Cambie el tema a sites/gw-0999/telemetry/main-meter y repita. En MQTT 5 debería ver el código 135 (0x87). No incluya claves privadas en tickets, chats ni capturas de pantalla.

Cortafuegos, puerto 443 y WebSockets

El TCP saliente por 8883 suele estar bloqueado en redes de clientes, y abrirlo puede llevar semanas. Hay dos alternativas que usan el puerto 443:

• MQTT sobre WebSockets con TLS (wss://). La sección 6 de la especificación MQTT 5 define el transporte WebSocket, con el nombre de subprotocolo mqtt. Mosquitto lo admite con protocol websockets en un servicio. AWS IoT Core lo ofrece en wss://<endpoint>/mqtt sobre 443.
• MQTT en 443 con ALPN. AWS IoT Core acepta MQTT ordinario con certificado de cliente X.509 en 443 si el cliente envía el nombre de protocolo ALPN x-amzn-mqtt-ca en su TLS ClientHello (tabla de protocolos de AWS).

Ambas alternativas requieren que el bróker las ofrezca. Un proxy que inspeccione TLS también rompe el TLS mutuo: el proxy no puede presentar el certificado de cliente de la Gateway. Solicite que el nombre de host del bróker evite ese proxy.

Vigencia de certificados y reloj de la Gateway

El vencimiento del certificado es el fallo MQTTS más habitual después de la entrega. Llega meses después, cuando nadie de la puesta en servicio está mirando.

Los certificados TLS de servidor de confianza pública duran cada vez menos. Según la decisión SC081v3 del CA/Browser Forum, la validez máxima bajó a 200 días el 15 de marzo de 2026. Bajará a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029. Un bróker en la nube con certificado público se renovará varias veces al año. Una Gateway que confía en la raíz emisora no lo nota; una que fija el certificado final falla en cada renovación. Estas normas no se aplican a las CA privadas, cuyas vigencias establece el proyecto. Documente quién renueva el certificado del bróker, quién renueva cada certificado de Gateway y cuándo vence el primero.

El cliente comprueba notBefore y notAfter con su propio reloj. Una Gateway que arranca con fecha incorrecta, como el 1 de enero de 1970 tras un corte prolongado en hardware sin reloj con batería, rechaza un certificado válido como «aún no válido». La Gateway EpiSensor ajusta su reloj mediante NTP, normalmente UDP 123. Permita ese tráfico en el cortafuegos y compruebe la hora de la Gateway antes de investigar el establecimiento de TLS.

QoS y entrega

La calidad de servicio MQTT se aplica a un tramo entre emisor y receptor. Los tramos publicador-bróker y bróker-suscriptor son intercambios distintos con confirmaciones separadas.

En QoS 1, el bróker envía PUBACK cuando acepta hacerse cargo del mensaje. La especificación MQTT 5 indica que el receptor no tiene que completar la entrega posterior antes de responder. Lea el código de motivo antes de registrar el éxito. 0x00 significa éxito. 0x10 (ningún suscriptor coincidente) significa que el bróker aceptó un mensaje sin destinatarios suscritos. 0x87 (no autorizado) y 0x97 (cuota superada) son rechazos. Ni siquiera 0x00 revela qué hizo luego la plataforma.

Consulte los límites del destino en la documentación de la plataforma. AWS IoT Core admite QoS 0 y 1, pero no QoS 2. AWS también advierte de que una conexión MQTT puede durar solo unos minutos (límites de conexión); el cliente debe reconectarse correctamente.

Otras funciones MQTT resuelven problemas distintos:

• Un mensaje retenido conserva el último mensaje de un tema para el siguiente suscriptor. Guarda un solo valor, no un historial.
• Una sesión persistente (inicio limpio desactivado, con intervalo de expiración de sesión) conserva suscripciones y mensajes QoS 1 y 2 en cola para un suscriptor desconectado. El bróker fija los límites de cola. No almacena datos que la Gateway nunca logró enviar.
• Keep alive fija la frecuencia con que el cliente debe enviar un paquete. El bróker cierra la conexión tras 1,5 veces el intervalo sin tráfico. Con 60 segundos, detecta un enlace muerto antes de 90.
• El bróker publica un mensaje Will cuando el cliente desaparece sin enviar DISCONNECT limpio. Utilícelo para marcar la Gateway como desconectada en un tema de estado.

Incluya la marca temporal de origen en la carga útil. Así, las lecturas reenviadas se colocan en su momento correcto y no parecen actuales.

Colisiones de ID de cliente

El bróker permite una sola conexión activa por ID de cliente. Al conectarse otro cliente con el mismo ID, desconecta al primero. MQTT 5 envía el código de motivo 0x8E (sesión sustituida). Si ambos se reconectan automáticamente, se expulsan mutuamente cada pocos segundos. El registro del bróker muestra un ciclo continuo de conexión y desconexión para un ID, a menudo desde dos direcciones. Suele deberse a una imagen de Gateway clonada o a un portátil de pruebas que utiliza sus credenciales. Vincule el ID al certificado para que la ACL pueda bloquear la copia.

MQTTS en EpiSensor Edge

EpiSensor Edge ejecuta en la Gateway un editor de flujos Node-RED. Un flujo lee datos de campo, les da el tema y la carga útil acordados y los publica mediante un nodo bróker MQTT. En ese nodo, active TLS y seleccione una configuración TLS. Cargue allí el certificado CA y, si el bróker los requiere, el certificado y clave de cliente. Marque «Verify server certificate» y establezca el nombre del servidor si el bróker necesita SNI.

Las integraciones gestionadas por Edge tratan las interrupciones mediante una cola de reintentos respaldada en disco. Si falla la entrega, Edge escribe el lote en esa cola, comprueba cada minuto si ha vuelto el destino y lo reenvía con las marcas temporales originales. La cola no tiene límite de antigüedad: una interrupción prolongada la hará crecer; dimensione el almacenamiento de la Gateway para la interrupción máxima prevista. Un lote que aún esté en memoria al cortarse la alimentación puede perderse, y un reenvío puede duplicarlo si el bróker lo recibió antes de que Edge registrase la entrega. Un nodo MQTT out añadido a un flujo propio queda fuera de esa cola. Pruebe cómo se comporta tras reiniciar la Gateway antes de depender de él.

Una conexión habitual con una plataforma publica medidas mapeadas en su bróker por TCP 8883, con un certificado de cliente específico para cada Gateway. Cada plataforma necesita sus propios datos de bróker, contrato de temas y prueba de aceptación; conectar Edge a su plataforma explica las formas en que Edge envía datos. En una instalación con varios proveedores, la guía de interoperabilidad trata el contrato de datos que admitir MQTT por sí solo no resuelve.

Lista de puesta en servicio

Siga estos pasos en orden. Ninguno requiere una acción de control real.

1. Anote el nombre de dominio completo del bróker, puerto, versión MQTT, ID de cliente, método de autenticación, estructura de temas, formato de carga útil, QoS y configuración de retención.
2. Compruebe el reloj de la Gateway, la resolución DNS y la regla de salida del cortafuegos para el nombre y puerto del bróker.
3. Examine los certificados: cadena, nombres, fechas de caducidad y correspondencia entre clave y certificado de cliente.
4. Active la verificación de certificados en la Gateway. Demuestre que rechaza un nombre de host incorrecto y una CA no confiable.
5. Confirme que ningún otro dispositivo utiliza el ID de cliente ni las credenciales de la Gateway.
6. Publique en un tema permitido y después intente una publicación denegada.
7. Envíe una lectura conocida y compare origen, marca temporal, valor y unidad en la plataforma receptora.
8. Observe al menos tres intervalos de informe. Un solo valor podría estar retenido u obsoleto.
9. Desconecte la WAN durante un periodo conocido. Tras la reconexión, compruebe huecos, duplicados y marcas temporales en la plataforma.
10. Registre las fechas de caducidad de los certificados y quién renueva cada uno. Pruebe un certificado de sustitución antes de retirar el anterior.

Para la propia medida, la guía sobre datos de sensores trata la hora de origen, la calidad y los huecos. La guía SCADA distingue la confirmación del protocolo del estado del dispositivo.

Órdenes y control

Un tema de órdenes necesita más medidas que uno de telemetría. Dé a cada orden una caducidad para que un mensaje retrasado por una interrupción se descarte en lugar de ejecutarse tarde. Dé al controlador su propio tema de órdenes con acceso de solo lectura. Haga que la orden sea idempotente: QoS 1 puede entregarla dos veces. Confirme el resultado leyendo de nuevo el estado del dispositivo y, cuando el riesgo lo justifique, mediante una medida independiente.

No active la retención en temas de órdenes. El bróker vuelve a entregar una orden retenida a cada nuevo suscriptor; un controlador que se reconecte tras reiniciarse podría ejecutar una consigna antigua. Los enclavamientos de seguridad permanecen en el controlador local; la guía de integración BMS y SCADA muestra el lugar de Edge junto a él. No pruebe la conectividad mediante una actuación de producción.

Diagnóstico por capas

Empiece por la capa más baja que explique el síntoma. Nunca resuelva un fallo desactivando la verificación de certificados ni ampliando la ACL de temas.

Registre para cada prueba la hora, identidad de Gateway y bróker, revisión del flujo, tema (con los nombres de instalaciones ocultos), resultado esperado y resultado observado.