TLS e certificados
Como duas máquinas que nunca se viram combinam uma chave secreta e como o certificado prova a identidade do servidor.
As decisões de TLS são cinco: de onde vêm os certificados, como são renovados, onde o TLS termina, quais versões aceitar e como proteger a comunicação entre os próprios serviços.
De onde vêm os certificados
| Origem | Exemplo | Custo | Quando usar |
|---|---|---|---|
| Autoridade pública com ACME | Let's Encrypt, ZeroSSL, Google Trust Services | Gratuito | Sites e APIs públicas: o padrão hoje |
| Certificado gerenciado pela nuvem | AWS Certificate Manager, certificados do balanceador da Google Cloud ou Azure | Gratuito no balanceador ou CDN | Quando o TLS termina num serviço da própria nuvem |
| Autoridade pública paga | DigiCert, Sectigo | Pago | Exigências contratuais ou de validação de organização |
| Autoridade privada | Uma CA interna, step-ca, CA de um service mesh, AWS Private CA | Operação própria | Serviços internos que não ficam expostos à internet |
| Autoassinado | Gerado com openssl | Nenhum | Só testes locais; nunca entre serviços em produção |
O ACME é o protocolo que tornou os certificados gratuitos e automáticos. Um cliente ACME, como o Certbot ou o próprio Caddy, prova à autoridade que controla o domínio e recebe o certificado sem intervenção humana.
| Desafio ACME | Como prova o controle do domínio | Observação |
|---|---|---|
| HTTP-01 | Publica um arquivo num caminho conhecido do site | Exige a porta 80 acessível pela internet |
| DNS-01 | Cria um registro TXT no DNS do domínio | Funciona para servidores internos e é o único que emite certificados curinga (*.loja.com.br) |
| TLS-ALPN-01 | Responde a uma negociação TLS especial na porta 443 | Usado por alguns proxies |
Renovação: certificados vencem
Os certificados públicos têm validade cada vez menor. Os da Let's Encrypt valem 90 dias, e as regras do setor aprovadas em 2025 estão reduzindo a validade máxima por etapas até 47 dias em 2029. Com prazos assim, a renovação manual deixa de ser viável.
| Abordagem | Como funciona |
|---|---|
| Proxy que renova sozinho | Caddy e Traefik obtêm e renovam os certificados por ACME, sem configuração extra |
| Cliente ACME agendado | Certbot ou acme.sh rodam periodicamente e recarregam o servidor |
| No Kubernetes | O cert-manager emite e renova certificados como recursos do cluster |
| Certificado gerenciado | O balanceador ou a CDN da nuvem cuida de tudo |
Onde o TLS termina
O tópico de HTTP compara terminar o TLS na borda, num proxy reverso ou na aplicação. O resumo:
| Onde | Quem cuida do certificado | O que fica sem TLS |
|---|---|---|
| CDN ou balanceador gerenciado | O provedor | O trecho entre o provedor e a sua rede, salvo se cifrado de novo |
| Proxy reverso próprio | O proxy, geralmente com ACME | O trecho entre o proxy e a aplicação |
| Aplicação | Cada serviço | Nada |
Terminar no proxy e deixar o trecho interno sem TLS é comum e aceitável quando esse trecho é uma rede privada, sob o seu controle. Em redes compartilhadas, ou com exigências como as de dados de pagamento e de saúde, o trecho interno também precisa de TLS.
Versões e configuração
| Versão | Situação |
|---|---|
| SSL 2.0, SSL 3.0 | Quebradas, desligadas em tudo |
| TLS 1.0, TLS 1.1 | Obsoletas, removidas pelos navegadores; não aceite |
| TLS 1.2 | Aceitável, com conjuntos de cifras modernos |
| TLS 1.3 | A preferida: negociação mais rápida e só algoritmos seguros |
Para a configuração de um servidor, não escolha cifras uma a uma. Use um perfil pronto, como o perfil "intermediário" do gerador de configuração da Mozilla, que aceita TLS 1.2 e 1.3 com cifras seguras e compatibilidade ampla.
Duas configurações completam o quadro:
- HSTS (
Strict-Transport-Security): um cabeçalho que diz ao navegador para nunca mais acessar o site por HTTP. Evita que um atacante force o primeiro acesso sem TLS. - Redirecionar HTTP para HTTPS: a porta 80 só serve para redirecionar e para o desafio HTTP-01 do ACME.
TLS entre serviços e mTLS
No TLS comum, só o servidor apresenta certificado. No TLS mútuo (mTLS), o cliente também apresenta o seu, e cada lado sabe com quem está falando.
| TLS comum | mTLS | |
|---|---|---|
| Quem prova identidade | Só o servidor | Servidor e cliente |
| Autenticação do cliente | Por token, senha ou chave de API, dentro da conexão | Pelo certificado, na própria conexão |
| Uso típico | Sites e APIs públicas | Comunicação entre serviços internos, integrações bancárias |
| Custo | Um certificado por servidor | Um certificado por serviço, emitido e renovado por uma CA interna |
Gerenciar certificados de cliente para dezenas de serviços à mão é inviável. Por isso o mTLS costuma vir com um service mesh (Istio, Linkerd) ou com uma CA interna automatizada, que emitem e renovam certificados de vida curta para cada serviço.
Conexões com o banco e outros serviços
O TLS não é só para HTTP. As conexões com o banco carregam os dados mais sensíveis do sistema:
Modo do PostgreSQL (sslmode) | Cifra | Confere o certificado | Confere o nome |
|---|---|---|---|
disable | Não | Não | Não |
require | Sim | Não | Não |
verify-ca | Sim | Sim | Não |
verify-full | Sim | Sim | Sim |
O modo require parece seguro e tem o mesmo problema de desligar a verificação: cifra a conexão com quem quer que responda. Para conexões que atravessam redes que você não controla, use verify-full, com o certificado da autoridade do banco configurado no cliente. Redis, MySQL, MongoDB e brokers de mensagens têm opções equivalentes.
Resumo da decisão
- Certificados públicos: ACME, com renovação automática e alerta de vencimento.
- Serviços internos: autoridade privada automatizada; nunca autoassinados em produção.
- Versões: TLS 1.2 e 1.3, com um perfil de configuração pronto.
- Cadeia: o servidor envia o certificado e o intermediário.
- Verificação: sempre ligada nos clientes, inclusive na conexão com o banco.
- mTLS: entre serviços, quando a rede não é confiável, com emissão automatizada.
O próximo nível mostra como inspecionar certificados, como confiar numa autoridade privada nas cinco linguagens sem desligar a verificação e como montar uma autoridade de teste.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Planejar os certificados do meu sistema
Quero planejar a obtenção, a instalação e a renovação dos certificados do meu sistema. Faça estas perguntas, uma por vez: - Quais domínios e serviços precisam de TLS, e quais são públicos ou internos? - Onde o TLS termina hoje: CDN, balanceador, proxy próprio ou aplicação? - Onde o sistema roda: servidor próprio, nuvem, Kubernetes? - O DNS dos domínios é gerenciado por um provedor com API? Com as respostas, recomende para cada caso a origem do certificado (ACME público, certificado gerenciado da nuvem, autoridade privada), o desafio ACME adequado, a ferramenta de renovação e a forma de monitorar o vencimento. Explique também como a redução da validade máxima dos certificados públicos nos próximos anos afeta o plano.
Configurar o TLS de um servidor
Quero configurar o TLS de um servidor corretamente. Pergunte qual servidor eu uso (Nginx, Caddy, Traefik, a própria aplicação) e quais clientes precisam acessá-lo. Explique, com a configuração para o meu caso: 1. Quais versões do TLS aceitar e por quê. 2. Por que usar um perfil pronto de cifras em vez de escolher uma a uma, e qual perfil usar. 3. Como montar o arquivo com a cadeia completa e conferir que o intermediário está sendo enviado. 4. Redirecionamento de HTTP para HTTPS e o cabeçalho HSTS, com os cuidados antes de ativá-lo. 5. Como testar a configuração com openssl s_client e com uma ferramenta de análise externa.
TLS entre serviços internos e mTLS
Quero decidir como proteger a comunicação entre os serviços internos do meu sistema. Pergunte como os serviços se comunicam, onde rodam e se a rede entre eles é compartilhada com outros sistemas. Explique: 1. Quando é aceitável deixar o tráfego interno sem TLS, e quando não é. 2. A diferença entre TLS comum e mTLS, e o que o mTLS acrescenta em autenticação. 3. Como emitir e renovar certificados para muitos serviços: autoridade privada automatizada, service mesh, ou certificados gerenciados. 4. Como configurar TLS com verificação completa nas conexões com o banco de dados e os brokers, e por que o modo require não basta. Termine com uma recomendação para o meu caso, com o esforço de implantação.