Um certificado SSL/TLS raramente falha do nada. Antes do navegador exibir a tela de aviso e do usuário abandonar o site, existe um prazo correndo em silêncio. A data de expiração é fixa, está gravada no próprio certificado e não degrada com o tempo: o certificado funciona plenamente até o segundo anterior ao vencimento e, no segundo seguinte, deixa de ser aceito. Não existe meio-termo, não existe "validade parcial" e não existe aviso embutido que o servidor envie para si mesmo.
Essa característica — uma transição brusca entre válido e inválido — é o que transforma a expiração de certificado em um problema operacional previsível e, ao mesmo tempo, em uma das causas mais comuns de indisponibilidade evitável em produção.
O que é, na prática, a expiração
Um certificado X.509 contém, entre outros campos, dois timestamps: notBefore e notAfter. O campo notAfter é o que chamamos de data de expiração. Quando um cliente TLS (o navegador, o curl, um outro serviço chamando sua API) recebe o certificado durante o handshake, ele compara o relógio atual com essa janela. Se o relógio estiver depois de notAfter, a conexão é interrompida antes de qualquer byte de aplicação trafegar.
Certificados emitidos por autoridades públicas hoje têm validade máxima de 395 dias. Isso significa que, no mínimo, uma vez por ano cada hostname público precisa passar por uma renovação. Ambientes que usam Let's Encrypt renovam a cada 60–90 dias, automaticamente na maioria dos casos — mas "na maioria" não é "sempre". Hooks falham, DNS não propaga, tokens expiram e o cron que deveria renovar silenciosamente deixa de rodar.
O que observar antes do vencimento
Dias restantes é a métrica mais óbvia, mas não é a única. Uma revisão útil de certificado público considera ao menos quatro sinais:
- Dias até
notAfter. Abaixo de 30 dias já é sinal para agendar renovação; abaixo de 7 dias, emergência. - Emissor (CN/O do issuer). Saber quem emitiu ajuda a identificar qual fluxo de renovação usar — ACME, painel do emissor, arquivo enviado por e-mail.
- Hostname coberto (CN e Subject Alternative Names). Um certificado pode cobrir
exemplo.come não cobrirwww.exemplo.com. Renovar o errado é um erro comum. - Cadeia de confiança. O certificado da folha precisa chegar ao cliente acompanhado dos intermediários corretos. Um servidor pode entregar um certificado válido e ainda assim gerar erro no navegador se a cadeia estiver incompleta.
O último ponto merece atenção. Cadeia incompleta não é problema de expiração, mas aparece junto em diagnósticos porque o sintoma é parecido: o navegador reclama, o curl reclama, e a causa raiz é diferente. Ferramentas de linha de comando como openssl s_client -showcerts e curl -vvI mostram a cadeia completa entregue pelo servidor.
Por que monitorar de fora
Uma armadilha comum é confiar apenas em monitoramento interno. O agente que roda dentro do servidor sabe que o arquivo do certificado existe, mas não necessariamente vê o que o servidor entrega na porta 443. Um proxy reverso mal configurado pode continuar servindo um certificado antigo mesmo depois que o ACME renovou. Um balanceador pode estar terminando TLS com um certificado diferente do que a aplicação espera.
Uma checagem externa — vinda de fora da rede, como um cliente real faria — pega esse tipo de desencontro. Ela responde à pergunta "o que um visitante está efetivamente recebendo agora?", que é a única que importa do ponto de vista de quem acessa o serviço.
Como transformar o alerta em tarefa
Alerta sem dono vira ruído. A diferença entre um monitoramento útil e um painel ignorado está em transformar cada sinal em uma ação com responsável e prazo.
Na prática:
- Defina limiares claros: 30 dias para começar a tratar, 14 dias para escalar, 7 dias para considerar incidente.
- Associe cada hostname a um responsável — pode ser uma pessoa, um time ou um runbook.
- Quando o alerta disparar, a ação já deve estar descrita: "renovar via ACME", "atualizar certificado no balanceador", "revisar cadeia com o emissor".
- Registre o que aconteceu. Histórico de renovação serve tanto para auditoria quanto para identificar padrões — um certificado que precisa ser renovado manualmente toda vez é um candidato a automação.
O objetivo não é acumular métricas. É saber, a qualquer momento, quantos dias de validade restam nos certificados críticos e qual é o próximo passo concreto para cada um.
Próximo passo
Se você não sabe hoje quantos dias faltam para os certificados dos seus hostnames públicos, esse é o ponto de partida. Uma varredura externa, mesmo que manual com openssl s_client, já dá a resposta em segundos. A partir daí, o trabalho é montar o loop: medir, comparar com o limiar, agir, registrar.
Ferramentas como a cymesh automatizam esse ciclo — fazem a checagem externa contínua, comparam com limiares configuráveis e guardam histórico — mas o princípio é o mesmo independentemente da ferramenta: o certificado expira em uma data fixa, e a única forma de não ser pego de surpresa é olhar antes.