TLS e certificados em automação: handshake, confiança e ciclo de vida
Entenda TLS, certificado, hostname, cadeia, validade, mTLS, versões, algoritmos, relógio e renovação sem transformar exceções de navegador em operação permanente.
Checklist de validação TLS
| Elemento | Falha típica | Evidência |
|---|---|---|
| Hostname/SAN | nome não coberto | URL usada e SAN |
| Cadeia | intermediária ausente ou CA desconhecida | cadeia enviada e trust store |
| Validade | expirado ou ainda não válido | relógio e datas |
| Versão/algoritmo | sem interseção | negociação e política |
| mTLS | cliente não aceito | certificado, uso e emissor |
| Renovação | consumidor esquecido | inventário e reteste completo |
Desativar validação elimina evidência de identidade e não deve virar configuração permanente.
TLS protege um canal depois de validar parâmetros e identidade
TLS negocia versão e algoritmos, estabelece segredos e protege confidencialidade e integridade. Normalmente o servidor apresenta certificado que liga uma chave pública a nomes. O cliente verifica assinatura, cadeia, período, uso e hostname. Se qualquer etapa é ignorada, ainda pode existir criptografia, mas a conexão pode terminar no equipamento errado.
HTTPS, FTPS, Syslog over TLS e outros serviços reutilizam TLS. O protocolo superior continua responsável por usuário, autorização e significado. Um certificado válido não prova que uma API deve aceitar comando, assim como login correto não valida parâmetro de proteção.
Certificado, chave privada e CA têm papéis diferentes
O certificado é distribuível; a chave privada deve permanecer protegida no titular; a autoridade certificadora assina e cria a âncora de confiança. Uma cadeia pode incluir intermediárias. Instalar apenas o certificado do servidor sem intermediária pode funcionar em um cliente com cache e falhar em outro.
Inventarie sujeito, SAN, emissor, serial, fingerprint, validade, algoritmo, uso e local da chave. O Common Name não deve ser a única referência de nome em implementações modernas; Subject Alternative Name precisa conter o hostname ou endereço realmente usado conforme a política.
Relógio incorreto pode derrubar a confiança
Certificados têm início e fim de validade. Um IED com data antiga pode considerar certificado ainda não válido; um cliente adiantado pode vê-lo expirado. Em ambientes isolados, perda prolongada de sincronismo transforma renovação bem-sucedida em falha aparente. Monitore relógio e vencimento como dependências separadas.
Não amplie validade indefinidamente para evitar manutenção. Períodos longos aumentam exposição de chave comprometida e favorecem esquecimento. Crie alertas com antecedência compatível com janela operacional, acesso ao ativo e aprovação de mudança.
Versões e algoritmos precisam de interseção segura
Cliente e servidor só conectam se compartilham versão, conjunto criptográfico e parâmetros. Equipamento antigo pode oferecer apenas protocolo ou algoritmo desaconselhado. Reabilitar opção fraca em toda a estação de engenharia amplia risco. Isole o perfil, atualize firmware ou use gateway controlado quando a substituição não for imediata.
TLS 1.3 simplifica e remove mecanismos antigos, mas o suporte OT varia. O requisito deve listar versões e algoritmos aceitos, não apenas “usar TLS”. Registre negociação real no aceite e após firmware.
mTLS autentica também o cliente
No TLS mútuo, o servidor solicita certificado do cliente e valida sua cadeia e uso. Isso oferece identidade forte entre sistemas, porém acrescenta emissão, instalação, renovação e revogação nos dois lados. Certificado de cliente não substitui necessariamente autorização por função.
Teste cliente válido, expirado, revogado quando o mecanismo existir, emissor desconhecido e certificado com uso incorreto. Planeje sobreposição de certificados durante rotação para evitar corte abrupto de integração.
Revogação e redes desconectadas exigem projeto
CRL e OCSP ajudam a informar que um certificado não deve mais ser aceito, mas endpoints OT podem não alcançar serviços de validação. Timeout de revogação pode atrasar ou bloquear conexão, e desabilitar a checagem muda o risco. Defina distribuição de CRL, cache, comportamento em indisponibilidade e processo de emergência.
Em PKI privada, proteja CA raiz offline quando aplicável, restrinja intermediárias e audite emissão. Backup de chave privada deve seguir necessidade e proteção; para alguns ativos é melhor gerar nova chave no equipamento.
Diagnóstico do handshake
Primeiro confirme TCP. Depois leia alerta TLS e certificados: unknown_ca, bad_certificate, handshake_failure ou protocol_version apontam classes diferentes. Compare hostname usado, cadeia enviada, relógio, versões e trust store. Navegador de um notebook não representa automaticamente o cliente embarcado.
Ferramentas podem inspecionar cadeia e negociação, mas não use modo inseguro como correção. Preserve fingerprint antes de substituir certificado. Se a falha surgiu após troca de equipamento, confirme se nova chave e nome foram cadastrados nos clientes.
Comissionamento e renovação sem surpresa
No aceite, teste nome correto e incorreto, CA confiável e desconhecida, validade, versões, mTLS e logs. Registre fingerprints e data de renovação. Em renovação, instale cadeia completa, valide em cliente representativo, mantenha rollback e só então retire certificado antigo.
Após a mudança, confira todos os consumidores, não apenas navegador. APIs, collectors e relays podem ter trust stores diferentes. A recuperação termina com conexão protegida, identidade válida, alarmes limpos e inventário atualizado. Preserve o certificado anterior e a configuração de confiança durante a janela de retorno, sem conservar a chave privada exposta. Registre qual cliente validou cada cadeia e quando a próxima renovação deve começar.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.