mTLS no MQTT: TLS Mútuo com Certificados de Cliente X.509 Explicado

O mTLS (TLS mútuo) no MQTT autentica os dois lados de uma conexão com certificados: o broker comprova sua identidade ao dispositivo, e o dispositivo comprova sua identidade ao broker com seu próprio certificado de cliente X.509. Este artigo explica como isso funciona, mostra uma configuração completa do Mosquitto com OpenSSL e ajuda você a decidir se o mTLS vale o custo operacional ou se usuário e senha via TLS são a melhor escolha para a sua frota.

TLS no servidor vs TLS mútuo

No MQTT sobre TLS comum, apenas o broker apresenta um certificado. O cliente o verifica, o túnel é criptografado e então o cliente se autentica dentro desse túnel com os campos de usuário e senha do pacote CONNECT do MQTT. É assim que funciona a maioria dos brokers na nuvem, e isso é explicado em detalhes no nosso guia de configuração de TLS no MQTT.

Com o TLS mútuo, o broker também envia um CertificateRequest durante o handshake. O cliente responde com seu próprio certificado e assina parte do handshake com a chave privada correspondente. O broker verifica se o certificado do cliente se encadeia a uma CA confiável, se está dentro do período de validade e se não foi revogado. Se qualquer verificação falhar, a conexão TCP é fechada antes que um único pacote MQTT seja processado.

Por que as equipes escolhem mTLS no MQTT

O argumento mais forte a favor do mTLS é que o segredo do dispositivo nunca sai do dispositivo. Uma senha é transmitida a cada conexão, então um broker comprometido, um log mal configurado ou um proxy de depuração podem capturá-la. Uma chave privada apenas produz assinaturas. Se a chave estiver em um secure element, como um ATECC608, ou em um TPM, ela não pode nem ser lida pelo firmware, o que torna a clonagem de um dispositivo muito mais difícil.

Outros benefícios:

• Identidade vinculada ao hardware: você pode emitir certificados na fábrica e ligar o common name do certificado ao número de série.
• Rejeição antecipada: clientes não autenticados são descartados antes de o broker fazer o parsing do MQTT, o que reduz a superfície de ataque.
• Ferramentas padrão: o X.509 é compreendido por qualquer biblioteca TLS, balanceador de carga e equipe de segurança.

O custo oculto: ciclo de vida dos certificados

O mTLS transfere a complexidade da base de usuários do broker para uma infraestrutura de chave pública (PKI). Antes de adotá-lo, seja honesto sobre estas tarefas:

1. Operar uma CA: mantenha a chave raiz offline, use uma intermediária para emissão e proteja ambas.
2. Provisionar: gere uma chave em cada dispositivo (de preferência no próprio dispositivo), crie um CSR, assine-o e instale o certificado.
3. Renovar: certificados expiram. Os dispositivos precisam de uma forma de obter um novo certificado antes que o antigo vença, mesmo que tenham passado um ano na prateleira.
4. Revogar: quando um dispositivo é roubado ou desativado, o broker precisa parar de aceitar seu certificado. O Mosquitto oferece suporte a um arquivo CRL; muitas equipes preferem certificados de vida curta.
5. Fazer a rotação da CA: em algum momento a própria CA emissora precisa ser substituída, o que significa distribuir uma nova âncora de confiança ao broker e novos certificados a cada dispositivo.

Erre em qualquer uma delas e você terá indisponibilidades que parecem falhas misteriosas de handshake em parte da frota. Para a maioria dos projetos pequenos e médios, credenciais exclusivas por dispositivo via TLS, com rotação periódica, oferecem uma relação melhor entre segurança e esforço. Nossos guias sobre autenticação MQTT com usuário e senha e rotação de credenciais MQTT mostram como fazer isso bem.

Configurando mTLS no Mosquitto

A configuração de laboratório a seguir usa o Eclipse Mosquitto, que oferece suporte nativo à autenticação por certificado de cliente. Execute-a em uma máquina que você controla.

Passo 1: crie uma CA privada

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

# Chave da CA e certificado de CA autoassinado (10 anos)
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

Passo 2: emita o certificado do broker

O certificado do broker precisa de um Subject Alternative Name que corresponda ao hostname que os clientes vão usar.

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

Passo 3: emita um certificado de dispositivo

Use o ID do dispositivo como common name. Em produção, a chave seria gerada no dispositivo e apenas o CSR sairia dele.

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

Passo 4: configure o 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

# Require a client certificate signed by cafile
require_certificate true

# Use the certificate CN as the MQTT username (for ACLs)
use_identity_as_username true

# Optional: reject revoked certificates
# crlfile /etc/mosquitto/certs/ca.crl

Copie os arquivos para /etc/mosquitto/certs/, torne a chave legível pelo usuário mosquitto e reinicie o serviço. Com use_identity_as_username, o CN sensor-001 vira o nome de usuário, então você pode escrever regras de ACL por dispositivo.

Passo 5: conecte-se com o 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

Os mesmos três arquivos funcionam no código. Em Python com 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()

Se você se conectar sem --cert e --key, o handshake falha imediatamente, o que é uma forma rápida de confirmar que require_certificate está ativo. Configurações de laboratório como esta usam uma raiz autoassinada; nosso guia sobre certificados autoassinados para MQTT aborda as armadilhas.

Erros comuns de mTLS

• "certificate required" ou alerta de handshake vindo do broker: o cliente não enviou um certificado. Verifique os caminhos do certificado e da chave.
• "unknown ca": o certificado do cliente foi assinado por uma CA que não está no cafile do broker.
• "unsupported certificate purpose": falta ao certificado o extended key usage clientAuth.
• Chave não corresponde: o arquivo de chave não pertence ao certificado. Compare openssl x509 -noout -modulus -in sensor-001.crt | openssl md5 com o mesmo comando aplicado à chave.
• Certificado expirado: verifique as datas com openssl x509 -noout -dates -in sensor-001.crt e confira o relógio do dispositivo.

Quando usar mTLS e quando credenciais bastam

O mTLS é uma boa escolha quando você controla o broker, precisa de identidade apoiada em hardware, atua em um ambiente regulado, como em alguns projetos de energia ou de óleo e gás, que exige identidade de dispositivo baseada em certificados ou já opera uma PKI. Normalmente é exagero para protótipos, frotas pequenas e equipes sem ninguém para cuidar da renovação de certificados.

A ConnectMQ adota a abordagem de credenciais via TLS: o broker apresenta um certificado Let's Encrypt publicamente confiável, e cada cliente se autentica com usuário, senha e client ID gerados no portal. Os client IDs ficam vinculados às credenciais emitidas, e logins com falha repetidos levam ao bloqueio do IP. A ConnectMQ não oferece autenticação por certificado de cliente, então, se o mTLS for um requisito obrigatório, você vai precisar de um broker configurado por você, como o Mosquitto mostrado acima. Para a maioria dos projetos, porém, um broker MQTT gerenciado com credenciais fortes por dispositivo elimina muito mais risco operacional do que o mTLS acrescenta. O panorama geral está nas nossas melhores práticas de segurança MQTT.

Comece a usar a ConnectMQ

Se credenciais via TLS atendem ao seu modelo de ameaças, a ConnectMQ oferece um broker protegido sem que você precise operar qualquer PKI. Cadastre-se em app.connectmq.com, escolha o plano Serverless (Free) sem cartão de crédito, crie um broker e conecte-se na porta 8883 com as credenciais geradas. Você pode prototipar primeiro no servidor MQTT público (gratuito) em broker.connectmq.com, que serve apenas para testes e protótipos, e depois mudar para credenciais privadas ao entrar em produção.

Perguntas frequentes

O mTLS é mais seguro do que usuário e senha via TLS?

Ele remove o segredo compartilhado da rede e combina bem com armazenamento de chaves em hardware, por isso resiste melhor ao roubo de credenciais. A contrapartida é um ciclo de vida de certificados que você precisa operar de forma confiável.

Posso usar mTLS e usuário e senha ao mesmo tempo?

Sim. O Mosquitto, por exemplo, pode exigir um certificado de cliente e ainda verificar o usuário e a senha do MQTT, oferecendo dois fatores independentes.

A ConnectMQ oferece autenticação por certificado de cliente?

Não. A ConnectMQ autentica os clientes com usuário, senha e client ID gerados e enviados via TLS. Use um broker autogerenciado se você precisar especificamente de mTLS.

Por quanto tempo os certificados de dispositivo devem ser válidos?

Não existe uma resposta única. Validades mais curtas reduzem a dependência da revogação, mas exigem uma renovação automatizada confiável; escolha o menor período que seu processo de renovação consegue suportar sem risco de expiração em campo.