SSL-TLS (Certificados, ACM)

TLS, sucessor direto do antigo SSL, é o protocolo criptográfico que protege a comunicação entre clientes e serviços, garantindo confidencialidade, integridade e autenticação de servidor em toda requisição de produção. Em arquiteturas web, HTTPS sobre TLS é requisito inegociável, não apenas por proteção de dados sensíveis, mas porque navegadores, balanceadores modernos e protocolos como HTTP/2 e HTTP/3 dependem dele para funcionar. O lado operacional do TLS gira em torno de certificados, sua cadeia de confiança, sua expiração e sua renovação, e é exatamente nesse ponto que a maioria dos incidentes de certificado acontece. Ferramentas como AWS Certificate Manager, Let's Encrypt e certbot automatizaram o ciclo de vida e transformaram a renovação manual em anti-padrão. Um time que domina TLS em produção garante cifras modernas, expiração sem sustos e terminação no ponto certo da arquitetura.

O problema que o TLS resolve

Sem criptografia de transporte, todo tráfego é legível e modificável por qualquer ponto da rede intermediária, do Wi-Fi público ao roteador comprometido, expondo credenciais, tokens de sessão e dados pessoais. O TLS resolve três problemas de uma vez: confidencialidade, com cifra do conteúdo; integridade, com detecção de qualquer alteração no caminho; e autenticidade, com o certificado provando que o servidor é quem afirma ser. Em produção há um problema adicional de disciplina: certificados expiram, e um certificado vencido derruba o serviço para todos os clientes com a mesma eficiência de uma falha de rede. Por isso o tema envolve tanto a criptografia em si quanto o ciclo de vida automatizado dos certificados, que é o que impede o incidente previsível de expiração.

Há também a dimensão de confiança de terceiros: APIs, navegadores e gateways de pagamento exigem HTTPS em endpoints de integração, e cadeias ou cifras inaceitáveis bloqueiam integrações comerciais antes de qualquer análise técnica. O TLS, nesse sentido, funciona como requisito de interoperação do ecossistema web, e não apenas como proteção.

Handshake TLS 1.3

O handshake é a negociação inicial em que cliente e servidor estabelecem as chaves de sessão e se autenticam. O TLS 1.3 reduziu o processo para um único round trip, eliminando algoritmos antigos e tornando a negociação mais rápida e mais segura por construção. O fluxo resumido funciona assim: o cliente envia um ClientHello com o conjunto de cifras suportadas e seu compartilhamento de chaves; o servidor responde com a escolha de parâmetros, o certificado e o compartilhamento próprio; ambos derivam a mesma chave de sessão e trocam mensagens de confirmação autenticadas. Duas consequências práticas merecem destaque: a ordem de preferência de cifras passa a ser respeitada pelo servidor por padrão, e o modo de retomada com zero round trip, o 0-RTT, permite reuso de sessão com ressalva de replay, o que exige cuidado em operações não idempotentes. Por esses motivos, exigir TLS 1.3 com fallback para TLS 1.2 é o padrão de configuração atual.

Na comparação com o TLS 1.2, o ganho do 1.3 vai além da latência: a negociação passou a não permitir cifra sem sigilo à frente, os dados de handshake após o ServerHello passaram a ser cifrados, e a lista de extensões aceitáveis encolheu, reduzindo a superfície de downgrade conhecida da versão anterior.

Certificados e cadeia de confiança

Um certificado é um documento assinado por uma autoridade certificadora, a CA, que liga uma identidade, o domínio, a uma chave pública, com validade definida. A confiança funciona em cadeia: o certificado do servidor é assinado por um certificado intermediário, que por sua vez é assinado pela raiz, pré-instalada nos navegadores e sistemas operacionais. O servidor deve apresentar a cadeia completa, incluindo os intermediários, e a ausência desse encadeamento é a causa mais comum do erro "certificado inválido" em dispositivos móveis, que resolvem menos cadeias incompletas que desktops.

O diagnóstico de cadeia é rotina de operação e o OpenSSL resolve em uma linha, mostrando profundidade, emissor e validade de cada elo, como no comando openssl s_client -connect dominio.com:443 -servername dominio.com. Erros de cadeia incompleta aparecem com frequência após migração de provedor de certificado, quando o intermediário novo não foi incluído na configuração.

A extensão SNI, Server Name Indication, também pertence a essa discussão, porque é o campo que permite a um mesmo endereço servir múltiplos certificados de domínios diferentes, base da hospedagem moderna e de terminações em balanceadores com centenas de domínios. Em configurações de alta densidade, a correspondência entre domínio solicitado e certificado servido deve ser testada explicitamente, pois associação incorreta de certificado é erro silencioso que só aparece como warning no cliente.

Let's Encrypt e renovação automática

Let's Encrypt popularizou a emissão gratuita e automatizada de certificados com o protocolo ACME, em que o cliente prova o controle do domínio por desafio HTTP ou DNS e recebe certificado de vida curta, hoje de trinta dias para certificados comuns. A vida curta é proposital: com renovação automática a cada dois terços do prazo, a janela de exposição de um comprometimento encolhe e a operação manual deixa de existir. A implantação típica usa certbot ou o gerenciador cert-manager no Kubernetes, com verificação periódica e renovação quando o prazo restante cai abaixo do limiar.

# Renovação automática com certbot via desafio HTTP
certbot certonly --webroot -w /var/www/certbot \
    -d aplicacao.com.br -d www.aplicacao.com.br \
    --email ops@aplicacao.com.br --agree-tos --non-interactive

# Verificação de expiração com renovação somente quando necessário
certbot renew --dry-run          # Valida a configuração sem emitir
systemctl status certbot.timer   # Timer de renovação ativo no sistema

O requisito operacional central é que o processo de renovação também faça o recarregamento do serviço que consome o certificado, com hook pós-renovação executando reload do Nginx ou reinício controlado do contêiner, caso contrário o arquivo novo fica no disco e o serviço continua servindo o antigo até o próximo restart.

A validação do controle do domínio merece atenção especial em infraestrutura grande. O desafio DNS-01, baseado em registro TXT provisório, escala melhor que o desafio HTTP em cenários com milhares de domínios e com origens não expostas à internet, e é o caminho usado pelo cert-manager em Kubernetes. A credencial usada pelo cliente ACME deve ser limitada apenas à zona de DNS necessária, porque um segredo com permissão ampla de DNS converte o próprio sistema de renovação em risco.

ACM com ALB e CloudFront

Na AWS, o ACM elimina a operação de emissão e renovação para certificados usados em serviços gerenciados. O fluxo é criar ou importar o certificado, validar o domínio por DNS, adicionando os registros CNAME indicados, e anexar o certificado ao ALB, ao CloudFront ou ao API Gateway; a partir daí a renovação é automática e transparente. Dois detalhes de arquitetura são decisivos. Certificados ACM para CloudFront precisam residir na região us-east-1, independentemente da região da aplicação, o que é fonte clássica de confusão. E o certificado só é gratuito quando usado por serviço integrado; certificados de EC2, contêineres e serviços não gerenciados exigem caminho alternativo, como ACM Private CA ou Let's Encrypt no próprio host.

A terminação de TLS também é uma decisão de arquitetura. O padrão comum termina o TLS no CloudFront e no ALB, com a conexão interna para os targets reagrupada em HTTP simples dentro de rede privada, ou reencriptada de ponta a ponta quando requisitos de compliance exigem. Reencriptação completa custa latência e complexidade de gestão de certificados internos, e a decisão deve seguir o requisito regulatório real, não preferência estética de segurança.

A combinação CloudFront com ACM entrega ainda um benefício de observabilidade: a distribuição expõe métricas de erros de handshake e de versões de TLS negociadas, permitindo medir a base de clientes antigos antes de endurecer a política. Essa medição transforma decisões de segurança em escolhas informadas, com dado real de quem ainda depende de cada protocolo.

# Listener HTTPS de um ALB apontando para o certificado do ACM
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
  LoadBalancerArn: !Ref CheckoutALB
  Port: 443
  Protocol: HTTPS
  SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06   # TLS 1.3 com fallback 1.2
  Certificates:
    - CertificateArn: !Ref CheckoutCertificate    # Emitido e renovado pelo ACM
  DefaultActions:
    - Type: forward
      TargetGroupArn: !Ref CheckoutTargets

HSTS e políticas de transporte

O HSTS, Strict Transport Security, é o header que instrui o navegador a recusar HTTP para o domínio, mesmo que o usuário digite a URL em texto puro, eliminando a janela de redirecionamento explorável por ataques de downgrade. A política carrega tempo de vida em segundos, escopo de subdomínios e a opção de inclusão em preload, que registra o domínio na lista compilada nos navegadores; entrar na preload é compromisso de longo prazo, pois a saída é lenta e falhas de TLS passam a bloquear completamente o acesso.

# Nginx: HSTS com um ano, incluindo subdomínios, sem preload inicial
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Redirecionamento de HTTP para HTTPS deve ser canônico e simples
server {
    listen 80;
    server_name aplicacao.com.br;
    return 301 https://$host$request_uri;
}

A recomendação é adotar HSTS com prazo crescente, começar sem includeSubDomains até confirmar que todos os subdomínios servem HTTPS, e considerar preload apenas em domínios maduros, porque erros de configuração com preload se tornam indisponibilidade prolongada.

Cipher suites modernos

A política de cifras define quais algoritmos o servidor aceita, e a configuração moderna segue princípio de restrição: TLS 1.3 com AES-256-GCM, AES-128-GCM e ChaCha20-Poly1305, com key exchange exclusivamente ECDHE, e TLS 1.2 restrito a ECDHE com cifras AEAD, eliminando CBC e todo modo estático de chave RSA. Cipher suites legados existem apenas como fallback de compatibilidade para clientes antigos, e cada exceção abre superfície de ataque; a prática de segurança moderna é medir quem ainda precisa do fallback, por meio de logs de handshake rejeitado, e reduzir essa base até poder desativá-la. Ferramentas de avaliação externa pontuam a configuração e servem como verificação contínua da política.

TLS interno e mTLS

A discussão de TLS não termina na borda. Entre serviços, o mTLS, mutual TLS, adiciona autenticação de cliente ao handshake, de forma que ambos os lados apresentem certificado, criando identidade verificável de workload e criptografia de ponta a ponta dentro da malha. Service meshes como Istio e Linkerd implementam mTLS automaticamente, emitindo certificados de vida curta para cada pod e renovando sem intervenção, o que viabiliza a prática em escala. O ganho combina defesa em profundidade contra movimento lateral de atacantes com um mecanismo de autorização baseado em identidade: uma política pode permitir que apenas o serviço de checkout chame o serviço de pagamento, independentemente do IP. Em ambientes sem malha de serviços, o mesmo efeito exige gestão manual de certificados de cliente, e é por isso que a adoção de mTLS costuma acompanhar a adoção da malha.

A adoção progressiva costuma operar em modo permissivo primeiro, onde o mTLS é negociado quando ambos os lados suportam, e só depois em modo estrito, que rejeita tráfego sem certificado. Essa migração em duas fases evita quebra de integrações legadas e dá tempo para instrumentar exceções documentadas.

Erros comuns

Os incidentes abaixo se repetem em ambientes de todos os tamanhos.

• Expiração de certificado sem alerta, com o serviço fora do ar por descuido previsível, geralmente em domínio secundário esquecido.
• Cadeia incompleta entregue pelo servidor, funcionando em desktops e falhando em dispositivos móveis e integrações.
• Certificado ACM criado na região errada para o CloudFront, bloqueando a associação na distribuição.
• Renovação automática que emite o certificado mas não recarrega o serviço, mantendo o arquivo antigo em memória.
• Configuração de TLS com cifras fracas herdadas de template antigo, detectada apenas em avaliação externa ou pentest.
• Domínios adicionados a certificado wildcard sem análise, ampliando o raio de comprometimento de uma única chave privada.
• Ambiente interno com TLS desativado por conveniência, permitindo movimento lateral não cifrado dentro da rede privada.

Boas práticas

As práticas abaixo consolidam a operação madura de TLS em produção.

• Automatize todo o ciclo de vida de certificados, com ACM para serviços gerenciados e cert-manager ou certbot para o resto, sem renovação manual em nenhum ponto.
• Configure alertas de expiração com folga maior que o ciclo de renovação, monitorando certificados por telemetria externa, e não apenas pelo confinamento do servidor.
• Adote TLS 1.3 como política primária com fallback controlado para 1.2, revisando a base de clientes antes de eliminar o fallback.
• Imprima o HSTS com prazo progressivo e trate preload como decisão formal de arquitetura, com análise de impacto em todos os subdomínios.
• Valide a configuração com avaliações externas periódicas e com testes de cadeia após qualquer troca de provedor de certificado.
• Habilite OCSP stapling e registre handshakes rejeitados, transformando a política de cifras em um número observável de clientes afetados.
• Proteja a chave privada com restrição de acesso rigorosa, e considere certificados com ECDSA, que oferecem o mesmo nível de segurança com chaves menores e handshakes mais rápidos.