DNS, TLS e certificados: o que acontece antes do seu request

# O que acontece quando você digita "google.com" no browser:

1. CACHE LOCAL — browser verifica cache DNS do SO
   (TTL não expirou? → resposta imediata)

2. RESOLVER RECURSIVO — geralmente o DNS do seu ISP ou do roteador
   (8.8.8.8 = Google, 1.1.1.1 = Cloudflare são resolvers públicos)

3. ROOT NAMESERVERS (.) — 13 clusters de servidores ao redor do mundo
   Resposta: "não sei, mas para .com pergunte ao nameserver TLD: X.X.X.X"

4. TLD NAMESERVER (.com) — gerenciado pela Verisign
   Resposta: "não sei, mas google.com usa nameserver: ns1.google.com"

5. AUTHORITATIVE NAMESERVER (ns1.google.com) — gerenciado pelo Google
   Resposta: "google.com = 142.250.79.46, TTL=300" ← resposta final!

6. RESPOSTA CACHEADA pelo resolver e devolvida para você
   Válida por TTL=300 segundos (5 minutos)

# Tempo total desse processo: ~50-200ms na primeira vez
# Com cache: <1ms

# Ferramentas de diagnóstico DNS
dig exemplo.com              # query A record
dig exemplo.com MX           # query MX records
dig exemplo.com NS           # nameservers autoritativos
dig @8.8.8.8 exemplo.com     # query usando resolver específico (Google)
dig +trace exemplo.com       # mostra toda a cadeia de resolução
dig -x 203.0.113.10          # reverse DNS lookup

nslookup exemplo.com         # alternativa mais simples (disponível no Windows)
host exemplo.com             # ainda mais simples

# Ver TTL atual de um registro:
dig exemplo.com | grep -A1 "ANSWER SECTION"
# → exemplo.com.   300   IN   A   203.0.113.10
#                  ↑ TTL em segundos

# Handshake TLS 1.3 (simplificado — 1 round-trip):

Cliente → Servidor:
  ClientHello:
  - Versão: TLS 1.3
  - Cipher suites suportados: TLS_AES_256_GCM_SHA384, ...
  - Chave pública efêmera (ECDHE) — para estabelecer a chave de sessão
  - SNI (Server Name Indication): "quero falar com api.exemplo.com"
    ↑ SNI é o hostname na camada TLS — permite múltiplos certs no mesmo IP

Servidor → Cliente:
  ServerHello:
  - Cipher suite escolhido
  - Chave pública efêmera do servidor (ECDHE)
  - Certificado X.509 do servidor (contém a chave pública RSA/ECDSA)
  - Assinatura que prova que o servidor tem a chave privada

Ambos derivam a mesma chave de sessão simétrica (AES-256-GCM):
  - A partir de: client_ephemeral_private × server_ephemeral_public (ECDH)
  - A chave de sessão NUNCA trafega pela rede → Perfect Forward Secrecy

Handshake completo! Comunicação cifrada com AES-256-GCM começa.

# Estrutura de um certificado X.509
openssl x509 -in certificado.pem -text -noout

# Campos importantes:
Subject: CN=exemplo.com, O=Empresa Ltda, C=BR  ← quem é o dono
Issuer: CN=Let's Encrypt R3, O=Let's Encrypt, C=US  ← quem assinou
Validity:
  Not Before: Jan  1 00:00:00 2026 GMT
  Not After:  Apr  1 00:00:00 2026 GMT   ← expira em 90 dias (Let's Encrypt)
Subject Alternative Names:
  DNS:exemplo.com
  DNS:www.exemplo.com                    ← wildcard: *.exemplo.com seria todos os subdomínios
Public Key Algorithm: id-ecPublicKey     ← ECDSA P-256

# Cadeia de confiança:
# Root CA (ISRG Root X1) → Intermediária (R3) → Leaf (exemplo.com)
# O Root CA está no trust store do seu SO/browser
# O browser valida a cadeia completa: leaf assinado por R3? R3 assinado por ISRG Root X1? Root confiado?

# Let's Encrypt + certbot: gratuito, automático, confiável
# https://letsencrypt.org — CA sem fins lucrativos

# Instalar certbot (Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx

# Obter certificado para nginx
sudo certbot --nginx -d exemplo.com -d www.exemplo.com

# Apenas obter o cert (sem configurar o servidor):
sudo certbot certonly --webroot -w /var/www/html -d exemplo.com

# Renovação automática (cron já configurado pelo certbot)
sudo certbot renew --dry-run    # testa renovação sem executar

# Arquivos gerados em /etc/letsencrypt/live/exemplo.com/:
# cert.pem       → certificado do seu domínio
# chain.pem      → certificados intermediários
# fullchain.pem  → cert.pem + chain.pem (o que o nginx/apache usa)
# privkey.pem    → sua chave privada (600 perms, nunca compartilhar)

# Configuração nginx mínima com TLS:
server {
    listen 443 ssl;
    server_name exemplo.com www.exemplo.com;

    ssl_certificate /etc/letsencrypt/live/exemplo.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemplo.com/privkey.pem;

    # Redirect HTTP para HTTPS
    # (em outro bloco server listen 80)
}

# Diagnóstico TLS
openssl s_client -connect exemplo.com:443 -servername exemplo.com
# Mostra: certificado completo, cadeia, datas de validade, cipher suite

# Verificar expiração do certificado
echo | openssl s_client -connect exemplo.com:443 2>/dev/null   | openssl x509 -noout -dates

# Testar renovação sem downtime
curl -I https://exemplo.com  # headers incluem informações do TLS

# Verificar se o hostname está no cert (SAN):
openssl s_client -connect exemplo.com:443 -servername exemplo.com   | openssl x509 -noout -text | grep -A1 "Subject Alternative"

# Problemas comuns:
# ERR_CERT_COMMON_NAME_INVALID → hostname não está no SAN do certificado
# ERR_CERT_DATE_INVALID → certificado expirado (renovar!)
# ERR_CERT_AUTHORITY_INVALID → cadeia incompleta ou CA não confiável
# SSL_ERROR_RX_RECORD_TOO_LONG → servidor não está falando TLS na porta (HTTP na porta 443)