Caddy on_demand_tls explicado em 10 minutos
Como servir TLS pra milhares de domínios sem pre-provisionar certificado — e como evitar abuso.
Plataforma multi-tenant tem um problema chato: cada tenant pode usar seu próprio domínio, e cada domínio precisa de certificado TLS. Pré-provisionar é impossível se você não sabe ainda quais domínios vão existir. Esperar o tenant criar o domínio pra pedir certificado é frágil — alguém precisa rodar comando, e isso quebra fluxo de self-service. Caddy resolve isso com on_demand_tls, e a sutileza está nos detalhes.
Conceito: quando uma requisição HTTPS chega pra um domínio que Caddy não tem certificado, ele tenta emitir na hora via ACME. Se o domínio resolve pra ele e o desafio HTTP-01 passa, certificado emitido em 2-3 segundos e armazenado pra próximas requisições. Pra usuário final, parece mágica — domínio aponta DNS, primeira visita demora um pouco, próximas são instantâneas. Pra operador, é potencial DoS — qualquer um pode forçar Caddy a tentar emissão pra domínios aleatórios e estourar rate limit do Let's Encrypt.
A solução é o 'ask': Caddy só tenta emitir se uma URL configurável retornar 200 pra aquele domínio. Em Camverly, essa URL é http://127.0.0.1:8082/internal/caddy/check?domain=X, que consulta tenancy-svc. Se o domínio está cadastrado como primary_domain ou alias de algum site ativo, retorna 200. Caso contrário, 403. Caddy aborta e retorna erro pro cliente. Isso elimina DoS porque atacante precisaria primeiro criar tenant.
Outra preocupação é rate limit. Let's Encrypt limita 50 certificados por domínio raiz por semana. Se um cliente faz cinco subdomínios e três aliases, isso é 8 certificados num site só. Multiplique por 100 tenants e você está raspando o limite. Solução: usar ZeroSSL como CA secundário (Caddy faz fallback automático), e configurar storage compartilhado entre múltiplas instâncias se houver mais de um nó Caddy.
Em produção, depois de seis meses, os números são tranquilos. Emissão média de 12 certificados por dia, picos de 30 quando alguém faz uma migração WordPress completa. Tempo médio de emissão: 1.8 segundos. Falhas: 0.3% (todas por DNS apontado mas não propagado ainda). O tipo de pergunta que recebíamos no início — 'isso aguenta produção?' — desapareceu sozinho. Caddy + on_demand_tls é uma das melhores decisões da arquitetura, perto de NATS e Postgres.