Русский
English
Українська
Deutsch
Español
Português
Türkçe
中文
Quando configurado como proxy reverso, o Caddy provisiona, renova e gerencia automaticamente os certificados TLS dos seus domínios usando provedores ACME como Let's Encrypt ou ZeroSSL, habilitando HTTPS por padrão sem intervenção manual. Esse recurso simplifica a implantação de servidores web seguros ao eliminar as tarefas manuais de gerenciamento de certificados.
Entendendo o HTTPS automático do Caddy
O principal diferencial do Caddy é sua abordagem de HTTPS sem configuração. Quando o Caddy recebe uma requisição para um domínio, ele tenta obter um certificado TLS para esse domínio caso ainda não exista um e nenhum tenha sido configurado explicitamente. Esse processo usa o protocolo ACME (Automatic Certificate Management Environment).
Como o ACME e o Caddy interagem
- Resolução do domínio: o Caddy identifica o nome de domínio associado à requisição recebida.
- Verificação do certificado: ele consulta seu armazenamento local em busca de um certificado válido já existente para esse domínio.
- Desafio ACME: se nenhum certificado válido for encontrado, o Caddy inicia um desafio ACME com o provedor ACME configurado (por padrão Let's Encrypt, com ZeroSSL como alternativa). Os tipos de desafio mais comuns são HTTP-01 e DNS-01.
- Desafio HTTP-01: o Caddy cria um arquivo temporário em um caminho específico (
/.well-known/acme-challenge/) no servidor. O provedor ACME então tenta acessar esse arquivo via HTTP na porta 80 para verificar a posse do domínio. Isso exige que o Caddy esteja publicamente acessível na porta 80. - Desafio DNS-01: o Caddy instrui o provedor ACME a verificar a posse do domínio checando um registro TXT específico na zona DNS do domínio. Esse método é obrigatório para certificados wildcard e pode ser usado quando a porta 80 não está disponível. Ele exige que o Caddy tenha credenciais de um provedor DNS suportado.
- Desafio HTTP-01: o Caddy cria um arquivo temporário em um caminho específico (
- Emissão do certificado: após a conclusão bem-sucedida do desafio, o provedor ACME emite um certificado TLS para o domínio.
- Armazenamento do certificado: o Caddy guarda o certificado e sua chave privada de forma segura em disco.
- Renovação automática: o Caddy monitora as datas de expiração dos certificados e os renova automaticamente com boa antecedência (normalmente 30 dias antes do vencimento) usando o mesmo processo de desafio ACME.
- OCSP Stapling: o Caddy também busca e anexa automaticamente respostas OCSP aos certificados, melhorando o desempenho e a privacidade do cliente ao permitir que ele verifique o status de revogação do certificado sem contatar diretamente a Autoridade Certificadora.
Configuração básica de proxy reverso com HTTPS automático
Uma configuração mínima de Caddyfile para proxy reverso já habilita implicitamente o HTTPS automático.
Exemplo simples de proxy reverso
yourdomain.com {
reverse_proxy localhost:8080
}
Neste exemplo:
* yourdomain.com: este é o rótulo do site. O Caddy vai escutar as requisições para esse domínio tanto na porta 80 (para redirecionamentos HTTP e desafios ACME) quanto na 443 (para HTTPS).
* reverse_proxy localhost:8080: esta diretiva encaminha todas as requisições recebidas para yourdomain.com a uma aplicação upstream rodando em localhost na porta 8080.
Ao iniciar com essa configuração, o Caddy executa automaticamente os seguintes passos:
1. Tenta obter um certificado TLS para yourdomain.com de um provedor ACME.
2. Configura redirecionamentos de HTTP para HTTPS para todo o tráfego na porta 80.
3. Serve yourdomain.com via HTTPS usando o certificado obtido.
Executando o Caddy
Para rodar o Caddy com essa configuração:
- Salve o conteúdo acima como
Caddyfileno diretório desejado. - Navegue até esse diretório no seu terminal.
- Execute:
caddy run
Em ambientes de produção, recomenda-se rodar o Caddy como serviço systemd ou dentro de um contêiner Docker.
Configurações avançadas de HTTPS
Certificados personalizados
Se você já tem certificados TLS (por exemplo, de uma CA corporativa ou certificados wildcard obtidos manualmente), o Caddy pode ser configurado para usá-los em vez de provisionar automaticamente.
yourdomain.com {
tls /path/to/your/cert.pem /path/to/your/key.pem
reverse_proxy localhost:8080
}
tls /path/to/your/cert.pem /path/to/your/key.pem: especifica o arquivo de certificado com a cadeia completa e o arquivo da chave privada. O Caddy usará esses arquivos e não tentará provisionar um certificado parayourdomain.com.
Certificados wildcard com desafio DNS-01
Certificados wildcard (*.yourdomain.com) exigem o desafio ACME DNS-01, porque o desafio HTTP-01 não consegue comprovar a posse de subdomínios arbitrários. Isso torna necessário configurar o Caddy com credenciais do seu provedor DNS.
*.yourdomain.com {
tls {
dns cloudflare {
api_token "YOUR_CLOUDFLARE_API_TOKEN"
}
}
reverse_proxy localhost:8080
}
tls { dns cloudflare { ... } }: este bloco diz ao Caddy para usar o desafio DNS-01 com o provedor DNS Cloudflare.api_token "YOUR_CLOUDFLARE_API_TOKEN": substitua pelo seu token de API real da Cloudflare. O Caddy suporta diversos provedores DNS por meio de plugins. Consulte a documentação do Caddy para as configurações específicas de cada provedor.
Múltiplos domínios e blocos de site
O Caddy pode servir vários domínios, cada um com seu próprio HTTPS automático.
yourdomain.com {
reverse_proxy localhost:8080
}
anotherdomain.org {
reverse_proxy localhost:8081
}
O Caddy vai provisionar e gerenciar certificados de forma independente para yourdomain.com e anotherdomain.org.
Comparação entre os desafios HTTP-01 e DNS-01
| Característica | Desafio HTTP-01 | Desafio DNS-01 |
|---|---|---|
| Método de verificação | Servir um arquivo na porta 80 | Adicionar um registro TXT ao DNS |
| Porta necessária | 80 (para o desafio ACME) | Nenhuma porta específica, apenas acesso ao DNS |
| Suporte a wildcard | Não | Sim (*.yourdomain.com) |
| Servidores internos | Inadequado se o Caddy não for acessível publicamente | Adequado para servidores internos se o DNS for gerenciável |
| Configuração | Normalmente automática, sem config extra | Exige credenciais do provedor DNS e um plugin |
| Necessidades de firewall | A porta 80 precisa estar aberta para a internet | Nenhuma porta de entrada necessária no host do Caddy para o desafio |
Provedores ACME
Por padrão, o Caddy usa o Let's Encrypt para provisionar certificados. O ZeroSSL é usado como alternativa. Você pode configurar explicitamente qual provedor ACME usar.
yourdomain.com {
tls [email protected] {
ca https://acme-v02.api.letsencrypt.org/directory
}
reverse_proxy localhost:8080
}
ca https://acme-v02.api.letsencrypt.org/directory: especifica a URL da CA ACME.[email protected]: informar um endereço de e-mail é recomendado para o registro da conta ACME e para notificações importantes da CA.
Gerenciando certificados
O Caddy gerencia os certificados automaticamente, mas entender seu armazenamento e as opções manuais pode ser útil.
Armazenamento de certificados
Por padrão, o Caddy guarda certificados, chaves privadas e informações da conta ACME em um diretório de dados. O local exato depende do sistema operacional e de como o Caddy é executado:
* Linux: /var/lib/caddy/.local/share/caddy (quando executado como root via systemd) ou $HOME/.local/share/caddy (quando executado como usuário).
* Docker: dentro do volume /data do contêiner.
Esse diretório deve ser persistente (por exemplo, um volume montado no Docker) para evitar reprovisionar certificados a cada reinício.
Renovação e revogação manuais
Embora o Caddy automatize a renovação, raramente é preciso interagir diretamente com o armazenamento de certificados.
* Renovação: se for necessária uma renovação imediata (por exemplo, após o comprometimento de um certificado), você pode apagar os arquivos daquele certificado no diretório de dados do Caddy. O Caddy então tentará provisionar um novo na próxima inicialização ou requisição.
* Revogação: a revogação de certificados é uma operação avançada, normalmente feita quando uma chave privada é comprometida. O Caddy não oferece um utilitário de linha de comando direto para revogação. Isso geralmente seria feito pela API do provedor ACME ou por um cliente dedicado, se necessário.
Solucionando problemas comuns de HTTPS
Configuração de firewall
Garanta que as portas 80 e 443 estejam abertas para tráfego de entrada no seu servidor Caddy. A porta 80 é essencial para o desafio ACME HTTP-01 e para os redirecionamentos de HTTP para HTTPS.
Propagação de DNS
Se estiver usando o desafio DNS-01, verifique se seus registros DNS (especificamente o registro TXT do desafio) se propagaram corretamente. Use ferramentas como dig ou serviços online de consulta DNS. Propagação incorreta ou lenta pode impedir a emissão do certificado.
Limites de taxa do ACME
Provedores ACME como o Let's Encrypt têm limites de taxa para emissão de certificados. Tentativas repetidas com falha podem levar a bloqueios temporários.
* Ambiente de staging: use o ambiente de staging do ACME para testes e evite atingir os limites de produção.
caddyfile
yourdomain.com {
tls [email protected] {
ca https://acme-staging-v02.api.letsencrypt.org/directory
}
reverse_proxy localhost:8080
}
* Consolide domínios: se você serve muitos subdomínios, considere um certificado wildcard para reduzir o número de requisições individuais de certificado.
Logs do Caddy
Os logs do Caddy trazem informações detalhadas sobre tentativas de provisionamento de certificados, renovações e eventuais erros. Consulte os logs em busca de mensagens de erro específicas se o HTTPS não estiver funcionando como esperado.
* Local padrão dos logs: os logs normalmente são escritos na saída padrão (stdout) ou em um arquivo de log configurado.
* Log detalhado: você pode aumentar o nível de detalhe dos logs para obter mais informações de diagnóstico.
{
log {
output file /var/log/caddy/caddy.log
level DEBUG
}
}
yourdomain.com {
reverse_proxy localhost:8080
}
Considerações de implantação
Docker
Ao implantar o Caddy no Docker, garanta que o diretório de dados esteja mapeado para um volume persistente.
version: '3.8'
services:
caddy:
image: caddy:latest
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data # Armazenamento persistente para os certificados
- caddy_config:/config
myapp:
image: myapp:latest
restart: unless-stopped
expose:
- "8080" # Porta interna, não exposta externamente
volumes:
caddy_data:
caddy_config:
Serviço systemd
Para implantações em bare-metal ou VM, rodar o Caddy como serviço systemd é a prática padrão. A documentação oficial do Caddy fornece arquivos caddy.service de exemplo que configuram o Caddy para rodar como usuário dedicado e gerenciar corretamente seu diretório de dados.
Uso de recursos
O Caddy é leve. As operações de gerenciamento de certificados consomem recursos mínimos e normalmente ocorrem em segundo plano. O consumo principal de recursos estará ligado ao encaminhamento do tráfego.
Boas práticas de segurança
O HTTPS automático do Caddy cuida de muitos aspectos de segurança por padrão:
* Cifras TLS fortes: o Caddy usa conjuntos de cifras TLS modernos e seguros.
* HTTP Strict Transport Security (HSTS): o Caddy pode adicionar automaticamente o cabeçalho Strict-Transport-Security, instruindo os navegadores a sempre se conectarem via HTTPS.
* OCSP Stapling: reduz a latência e melhora a privacidade.
Embora o Caddy resolva boa parte da complexidade do TLS, as práticas gerais de segurança continuam relevantes:
* Mantenha o Caddy atualizado: atualize o Caddy regularmente para a versão mais recente e aproveite as correções de segurança e os novos recursos.
* Menor privilégio: rode o Caddy com as permissões mínimas necessárias. Os arquivos oficiais de serviço systemd configuram o Caddy para rodar como usuário não-root.
* Firewall: restrinja o acesso às suas aplicações upstream (por exemplo, localhost:8080) para que só sejam acessíveis a partir da instância do Caddy.
* Controle de acesso: implemente controle de acesso ou autenticação adicionais, se necessário, para rotas ou aplicações específicas por trás do proxy.