| Domínio | Emissor | Expira | Dias restantes | Estado |
|---|---|---|---|---|
| mail.example.com | Let's Encrypt | 01.11.2026 | 21 | Expira em breve |
| app.example.com | Let's Encrypt | 26.11.2026 | 46 | Válido |
| shop.example.com | Let's Encrypt | 19.12.2026 | 69 | Válido |
| example.com | Let's Encrypt | 07.01.2027 | 88 | Válido |
A renovação automática resolveu a maior parte do problema e criou uma versão mais silenciosa dele. Os certificados renovam-se agora sozinhos, até ao dia em que deixam de o fazer. E como ninguém está a olhar, a falha manifesta-se como um aviso do browser à frente dos visitantes em vez de uma tarefa numa lista.
Esta página lista os certificados que o servidor apresenta, com emissor, data de expiração e dias restantes. Qualquer valor abaixo de trinta dias num certificado que devia renovar-se sozinho é sinal de que a renovação anda a falhar em silêncio há algum tempo.
Vale a pena conhecer as causas habituais. O desafio HTTP quebra quando um encaminhamento ou uma regra da firewall começa a intercetar /.well-known/acme-challenge/. A renovação corre bem mas o novo certificado nunca chega aos visitantes porque o servidor web não foi recarregado. Um domínio permanece na configuração do certificado depois de o DNS já ter mudado para outro lado, e toda a renovação falha por causa de um nome obsoleto. Vistos de fora, os três casos são idênticos: um certificado a descer calmamente para zero.
Vale olhar para aqui segundo um calendário e não quando calha lembrar: a passagem pelos certificados corre a partir do cron, pelo que trinta dias de margem se tornam um aviso muito antes de um visitante ver algum. Também ajuda conhecer a fronteira. O Monit dirá que o servidor web deixou de responder, mas nada dirá sobre um certificado a que faltam três dias: um SSL expirado não derruba o serviço, derruba a confiança do navegador.