Certificados TLS para serviços internos feitos da maneira certa

Artigo original ↗ Discussão no Hacker News ↗

DNS de horizonte dividido vs alternativas

  • Muitos criticam o DNS de horizonte dividido por ser frágil e exigir muita manutenção, especialmente em escala (registros duplicados, estranhezas de cache, problemas de roteamento de VPN).
  • Outros dizem que ele é suficiente para laboratórios pequenos/em casa e pode ser combinado com hairpin NAT; a verdadeira dor são as grandes configurações corporativas em que zonas internas e públicas compartilham o mesmo nome.
  • Alguns recusam explicitamente usar DNS dividido, preferindo zonas públicas únicas com IPs internos ou redes overlay.

ACME, DNS-01 e padrões de automação

  • Forte preferência por validação DNS-01 em vez de HTTP-01 para serviços internos.
  • Padrões comuns:
    • Usar um domínio público com APIs de DNS para obter certificados (muitas vezes wildcard), e então apontar nomes para IPs internos.
    • Usar alias CNAME “_acme-challenge” para delegar DNS-01 a uma zona/provedor separado ou a ferramentas como acme-dns.
    • Serviços centrais auxiliares de ACME ou GitHub Actions que possuem credenciais de DNS e emitem certificados para hosts internos.
  • Há interesse no futuro desafio DNS-PERSIST-01 para reduzir a necessidade de atualizações dinâmicas de DNS, embora o suporte ainda seja limitado.

CAs públicas vs CAs internas

  • Um grupo: “Apenas execute uma CA interna, assine certificados internos e confie nessa CA nos seus dispositivos.” Visto como a solução criptográfica mais limpa.
  • Contra-argumentos:
    • Distribuir e gerenciar âncoras de confiança em sistemas operacionais, linguagens, contêineres e navegadores heterogêneos é doloroso.
    • Alguns argumentam que CAs públicas (por exemplo, Let’s Encrypt via DNS-01) são mais simples operacionalmente, especialmente quando você não controla totalmente os dispositivos clientes.
    • Preocupações com limites de taxa e semântica de confiança (um certificado público só prova controle do domínio, não identidade organizacional).

Certificados wildcard, logs CT e preocupações com hostnames/privacidade

  • Alguns se preocupam que certificados públicos não-wildcard exponham hostnames internos em logs de Certificate Transparency; certificados wildcard mitigam isso, mas concentram o risco da chave.
  • Outros não se incomodam com o vazamento de hostnames genéricos de casa ou dizem que a superfície de ataque importa mais do que a obscuridade.
  • Debate sobre se colocar IPs internos e hostnames em DNS público é aceitável; alguns veem isso como inofensivo, outros rejeitam totalmente.

Trust stores de clientes e fragmentação de ferramentas

  • Vários comentários lamentam que configurar clientes para confiar em CAs internas é mais difícil do que deveria ser.
  • Diferentes ecossistemas usam diferentes trust stores (SO, Java, navegadores, Node, Python/certifi, contêineres, snaps), forçando a instalação repetida da CA.
  • Essa complexidade é uma grande razão pela qual alguns favorecem certificados ACME públicos mesmo para serviços puramente internos.

Modelos de segurança e padrões de acesso

  • Alguns defendem um estilo “BeyondCorp/zero trust”: mTLS, certificados de dispositivo e proxies reversos autenticados em vez de VPN mais DNS dividido.
  • Outros dependem de VPNs (WireGuard, Tailscale) com DNS interno, ou de proxies reversos/balanceadores de carga centrais terminando TLS e roteando para serviços internos.
  • A opinião continua dividida sobre se usar certificados públicos para serviços internos de alto valor é apropriado; alguns chamam isso de “bogus”, outros perguntam por que isso seria prejudicial.