Lista de Verificação da Infraestrutura de Redirecionamento para a Era do Certificado de 45 Dias

As durações dos certificados SSL estão prestes a ser reduzidas pela metade. O Let's Encrypt — que dá suporte a 60% de todos os certificados da web — está passando de 90 dias para um máximo de 45 dias para a validade dos certificados. A proposta do Google no CA/Browser Forum segue essa mesma direção. Toda a indústria de certificados está avançando para durações menores como padrão de segurança, e o cronograma já não é mais uma hipótese.

Para equipes que gerenciam infraestrutura de redirecionamento em centenas ou milhares de domínios, isso não é um ajuste menor — é um multiplicador operacional. O que exigia 4 ciclos de renovação por domínio por ano em breve exigirá 8. Processos manuais que mal funcionavam com 90 dias vão falhar completamente com 45.

Esta lista de verificação foi criada para ajudar equipes de infraestrutura a avaliar sua prontidão em seis domínios críticos: automação, monitoramento, timing da renovação, alertas, estratégia com wildcard e recuperação de desastres. Cada seção inclui uma pergunta de autoavaliação e um estado-alvo. Ao final, você terá uma visão clara de onde sua infraestrutura está — e do que precisa mudar antes de chegar a era de 45 dias.

1. Automação: Ciclo de Vida de Certificados sem Intervenção#

A pergunta mais importante na sua avaliação de prontidão: todos os certificados emitidos e renovados acontecem sem intervenção humana?

Se a resposta for qualquer coisa diferente de um “sim” sem ressalvas, você tem um problema. Com durações de 45 dias, operações manuais de certificados se tornam insustentáveis em escalas surpreendentemente pequenas. Um portfólio com apenas 50 domínios exige 400 operações de certificado por ano — mais de uma por dia, todos os dias, incluindo fins de semana e feriados.

Autoavaliação do estado atual: como sua equipe lida com o provisionamento de certificados hoje? Se a resposta envolve lembretes de calendário, planilhas, geração manual de CSR ou “alguém normalmente resolve”, você está na categoria manual. Mesmo que você tenha automatizado partes do fluxo, verifique se o script cobre todos os domínios, trata todos os casos-limite e se recupera de todas as falhas sem necessidade de escalonamento humano.

Estado-alvo: cada hostname na sua infraestrutura de redirecionamento provisiona automaticamente SSL via ACME no momento em que o DNS é configurado. A emissão, instalação e renovação dos certificados acontecem sem qualquer ação humana. O sistema detecta novos domínios, valida a titularidade via desafio DNS-01, solicita o certificado, instala-o nos nós de borda e agenda a próxima renovação — tudo em segundos após o hostname ser adicionado.

Uma plataforma de redirecionamento que gerencia SSL por hostname — em vez de exigir que você gerencie certificados por servidor — elimina completamente a lacuna de automação. Quando o DNS é delegado à plataforma, o SSL se torna uma propriedade da infraestrutura, e não uma tarefa na lista de afazeres de alguém.

2. Monitoramento: Saiba Antes de Quebrar#

Pergunte a si mesmo: Você tem monitoramento ativo de expiração de certificados em todos os domínios?

O monitoramento é a rede de segurança por baixo da automação. Mesmo com renovação baseada em ACME, as coisas podem dar errado: uma entrada de DNS é alterada, um limite de taxa é acionado, uma CA sofre uma indisponibilidade. Sem monitoramento, você descobre certificados expirados do mesmo jeito que seus usuários — por meio de um aviso no navegador.

Mas monitoramento não é apenas verificar datas de expiração. Um monitoramento eficaz para infraestrutura de redirecionamento significa verificações de integridade (health checks) a partir de múltiplas localizações globais, porque um certificado que parece válido no seu escritório pode falhar na localização de um usuário devido a atrasos de propagação na borda ou ao cache do CDN.

Autoavaliação do estado atual: Você tem um painel ou sistema de alertas que mostra as datas de expiração dos certificados para cada domínio? Ele é atualizado em tempo real quando os certificados são renovados? Você consegue ver de relance quais domínios estão se aproximando da expiração e quais já falharam?

Estado-alvo: Monitoramento contínuo da saúde dos certificados a partir de múltiplas localizações globais na borda. O sistema executa verificações ativas de handshake TLS — não apenas consultas de data de expiração — para verificar se cada certificado é válido, confiável e está servindo corretamente. O painel mostra o status em tempo real em todos os domínios. O monitoramento é automático: quando um novo nome de host é adicionado, o monitoramento começa sem configuração.

3. Timing da Renovação: A Zona de Buffer#

A pergunta: As renovações estão sendo tentadas cedo o suficiente para sobreviver a indisponibilidades de vários dias?

Com certificados de 90 dias, renovar 7-14 dias antes da expiração fornecia um buffer confortável. Com certificados de 45 dias, o mesmo buffer consome 15-30% do tempo de vida total utilizável do certificado. A matemática força um trade-off: renovar cedo demais e você fica constantemente alternando certificados; renovar tarde demais e uma indisponibilidade temporária de CA vira um incidente em produção.

Os limites de taxa do Let's Encrypt adicionam outra dimensão. O limite de "Duplicate Certificate" permite 5 certificados por semana para o mesmo conjunto de nomes de host, e o limite de "Certificates per Registered Domain" limita a 50 por semana. Em ciclos de renovação de 45 dias, grandes portfólios de domínios podem se aproximar desses limites mais rápido do que o esperado — especialmente se você também estiver provisionando certificados para novos domínios.

Autoavaliação do estado atual: Qual é a sua janela de renovação? Se o seu time renova certificados manualmente, as renovações são iniciadas pelo menos 15 dias antes da expiração? Você consegue sobreviver a uma indisponibilidade de 5 dias da CA sem que nenhum certificado expire? Você testou o que acontece quando uma tentativa de renovação falha — o sistema tenta novamente automaticamente ou espera intervenção humana?

Estado-alvo: As renovações automatizadas começam 30 dias antes do vencimento, com uma lógica de retentativa por backoff exponencial. Se a primeira tentativa falhar, o sistema tenta novamente em intervalos crescentes — 1 hora, 4 horas, 12 horas, 24 horas — até que a renovação seja bem-sucedida. Os limites de taxa são rastreados e respeitados automaticamente. O sistema consegue sobreviver a uma indisponibilidade de CA por vários dias sem nenhum domínio atingir a data de vencimento, porque as renovações são iniciadas cedo o suficiente para sempre haver pelo menos 15 dias de margem.

4. Alertas: Antes, Não Depois#

A pergunta: as pessoas certas são notificadas antes — e não depois — do vencimento do certificado?

O alertamento é a diferença entre um não-evento e um incidente. Quando uma renovação de certificado falha, duas coisas precisam acontecer: o sistema tenta novamente automaticamente (veja a seção 3) e a pessoa certa fica sabendo. Se seu monitoramento detecta um certificado expirado sem alertar ninguém, ainda há uma lacuna — você só está descobrindo isso mais rápido.

O alertamento deve ser escalonado por severidade e público. Uma renovação falha que é retomada com sucesso 30 minutos depois não precisa de uma página às 2 da manhã — mas deve aparecer em um resumo diário. Um certificado se aproximando das últimas 72 horas sem renovação bem-sucedida é um alerta crítico que deve chegar ao engenheiro de plantão imediatamente.

Autoavaliação do estado atual: Quem é notificado quando um certificado está prestes a expirar? Existe um sistema de alertas escalonado com diferentes níveis de severidade? Os alertas vão para os canais corretos (Slack, e-mail, PagerDuty) com base na urgência? Se a pessoa principal de plantão estiver indisponível, o alerta é escalado?

Estado-alvo: Alertas em três níveis: Info (renovação tentada, resumo diário), Warning (renovação falhou, janela de 7 dias, Slack/e-mail), Critical (renovação falhou repetidamente, janela de 72 horas, escalonamento no PagerDuty/plantão). Os alertas incluem o nome do domínio, a data de expiração do certificado, o horário da última tentativa de renovação e o motivo da falha. Todos os domínios do portfólio são cobertos — sem exceções, sem “vamos monitorar manualmente aquele”.

5. Certificados Wildcard: Conveniência vs. Risco#

A pergunta: os certificados wildcard são tratados corretamente ou estão criando pontos únicos de falha?

Certificados wildcard são tentadores: um certificado para *.example.com cobre todos os subdomínios. Uma renovação. Uma data de expiração. Uma coisa para gerenciar. Mas essa “coisa para gerenciar” também é uma coisa que pode falhar — e quando falha, todos os subdomínios apagam simultaneamente.

Para infraestrutura de redirecionamento especificamente, curingas criam outro problema: desafios DNS-01 para certificados curingas exigem acesso à zona DNS do domínio apex. Se seus domínios de redirecionamento estiverem distribuídos entre vários registradores e provedores de DNS — comum em portfólios grandes — gerenciar desafios DNS-01 para um único curinga fica significativamente mais complexo do que gerenciar certificados por hostname.

Autoavaliação do estado atual: Você está usando certificados curinga para domínios de redirecionamento? Se o certificado curinga falhar ao renovar, quantos domínios são afetados? Você tem um plano de rollback testado? Os curingas são gerenciados pela mesma equipe que gerencia certificados por domínio, ou são processos separados com responsáveis diferentes?

Estado-alvo: Certificados por hostname são o padrão. Cada domínio recebe seu próprio certificado, provisionado e renovado de forma independente. Isso fornece isolamento: uma falha de renovação em um domínio não afeta nenhum outro. Curingas são usados apenas quando explicitamente necessário (por exemplo, serviços internos por trás de um subdomínio compartilhado), com monitoramento e alertas separados — e um procedimento de recuperação documentado e testado.

6. Recuperação de Desastres: Quando a AC cai#

A pergunta: Se sua Autoridade Certificadora (AC) estiver indisponível por 5 dias, seus certificados sobrevivem?

O Let's Encrypt já passou por interrupções de várias horas no passado. Com durações de certificados de 90 dias, uma indisponibilidade de 2 a 3 dias era administrável — os certificados tinham validade restante suficiente para aguentar. Com 45 dias, a mesma indisponibilidade pode empurrar os certificados para além da janela de renovação antes que a AC volte a ficar online.

A recuperação de desastres para SSL não é apenas sobre a AC. É sobre DNS — se seu provedor de DNS tiver uma indisponibilidade durante a janela de desafio DNS-01, o desafio falha e a renovação é bloqueada. É sobre propagação na borda — se um certificado renovado não se propagar para todos os nós de borda antes que o antigo expire, alguns usuários veem erros. E é sobre o próprio pipeline de renovação — se sua plataforma de automação tiver uma indisponibilidade, as renovações entram em fila ou são descartadas?

Autoavaliação do estado atual: Você modelou o que acontece durante uma indisponibilidade de 5 dias da AC? Qual é a menor janela de validade de certificado no portfólio? Você tem uma AC de contingência configurada, ou todos os certificados estão vinculados a um único provedor? Sua infraestrutura de DNS consegue sobreviver a uma indisponibilidade durante uma janela de desafio?

Estado-alvo: Os certificados são renovados com antecedência suficiente para que cada domínio mantenha pelo menos 15 dias de folga — o bastante para sobreviver a uma indisponibilidade realista da AC. O pipeline de renovação é resiliente: se uma renovação falhar devido à indisponibilidade da AC, o sistema tenta novamente automaticamente quando a AC se recupera. O monitoramento cobre toda a cadeia de dependências (DNS, AC, propagação na borda), não apenas as datas de expiração dos certificados. ACs de contingência são configuradas para domínios críticos, e a equipe tem um runbook documentado e testado para provisionar certificados manualmente durante indisponibilidades prolongadas da AC.

Autoavaliação: Avalie sua prontidão#

Avalie sua infraestrutura em cada um dos seis domínios abaixo. Seja honesto — uma nota baixa não é uma falha, é um roteiro.

Pontuação: 1 = Manual / Sem capacidade, 2 = Parcialmente automatizado / Há lacunas, 3 = Majoritariamente automatizado / Pequenas lacunas, 4 = Totalmente automatizado / Sem lacunas, 5 = Totalmente automatizado + testado / Resiliente

Interpretando seu total:

24-30: Você está pronto. Sua infraestrutura é automatizada, monitorada e resiliente. Foque em manter esse estado e testar regularmente seus procedimentos de recuperação.

18-23: Você tem bases sólidas, mas ainda há lacunas. Priorize primeiro os domínios 'Críticos' — automação e timing de renovação são as melhorias com maior retorno sobre investimento. Um prazo de 45 dias vai pressionar sua configuração atual.

12-17: Sua infraestrutura não está pronta para certificados de 45 dias. Processos manuais que funcionam em 90 dias vão falhar em 45. Comece com automação (domínio ①) — se você só corrigir uma coisa, torne automático o provisionamento e a renovação de certificados.

6-11: Você está em alto risco. Cada domínio do seu portfólio está vulnerável a um único lembrete de calendário perdido ou a uma indisponibilidade da CA. Considere migrar para uma plataforma de redirecionamento que trate a automação de SSL como infraestrutura — não como uma tarefa — para fechar a lacuna rapidamente.

O Abismo Só Aumenta#

A era do certificado de 45 dias não é uma possibilidade futura — é uma trajetória da indústria com um cronograma definido. Let's Encrypt, que emite certificados para mais de 360 milhões de domínios, está liderando a mudança. A proposta do Google no CA/Browser Forum segue a mesma direção. O padrão está se movendo, e a diferença entre infraestrutura automatizada e manual só aumenta à medida que a validade dos certificados diminui.

As equipes que automatizam agora não vão sentir a mudança. Elas vão ver seus painéis mostrarem renovações concluídas no prazo — 30 dias antes, todas as vezes, em todos os domínios — enquanto outras correm para atualizar planilhas. A lista de verificação acima não é apenas uma ferramenta de avaliação. É um roteiro para uma infraestrutura preparada para qualquer validade de certificado que a indústria venha a adotar — 45 dias, 30 dias ou menos.

Avalie sua infraestrutura. Corrija as lacunas. A era do certificado de 45 dias está chegando — seus domínios de redirecionamento devem ser a última coisa com que você se preocupa.