A Let’s Encrypt emite certificados por noventa dias e renova-os automaticamente, razão pela qual se deixa de pensar neles uma semana depois da configuração. O problema é que a renovação automática se parte em silêncio: ninguém vê os erros, e três meses depois o sítio recebe os visitantes com um aviso do navegador. Desde 2025 a Let’s Encrypt deixou de enviar avisos de expiração por correio, pelo que desapareceu também o último lembrete externo.

Seguem-se as razões pelas quais a renovação deixa de funcionar, por ordem decrescente de frequência.

1. O certificado foi renovado e o serviço nunca o releu

A mais frequente. O certbot renew correu, o ficheiro novo está no disco, e o nginx ou o Apache mantêm o antigo em memória, entregando-o aos visitantes até a configuração ser recarregada. Formalmente está tudo bem; de facto o sítio tem um certificado expirado.

Cura-se com um gancho executado depois de uma renovação bem-sucedida:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Isso escreve-se uma vez no ficheiro de renovação (/etc/letsencrypt/renewal/example.com.conf, secção [renewalparams], linha renew_hook) e a partir daí funciona sozinho.

2. Mudou o servidor web e a validação não

A validação HTTP-01 exige que um ficheiro de /.well-known/acme-challenge/ seja servido por HTTP simples. Costuma partir-se assim:

  • foi acrescentado à configuração um reencaminhamento incondicional de HTTP para HTTPS: a validação entra no reencaminhamento e não passa;
  • apareceu uma regra location ~ /\. com deny all que fecha todas as pastas com ponto, .well-known incluída;
  • a raiz do sítio mudou de sítio e nas definições do certbot ficou o antigo --webroot-path;
  • foi ativado um bloqueio por países ou uma autenticação básica que apanhou também o servidor de validação.

A ordem correta na configuração: primeiro um location próprio para /.well-known/acme-challenge/ e só depois o reencaminhamento geral.

3. O temporizador está desligado

A renovação é lançada por um temporizador do systemd ou por uma tarefa do cron, e ambos podem ser desativados por distração numa depuração ou perdidos numa mudança de servidor.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

O segundo comando executa um ciclo de renovação completo em modo de teste sem gastar a sua quota. É a única verificação que responde antecipadamente a «vai renovar daqui a um mês?» em vez de a posteriori.

4. Um domínio já não aponta para aqui

O certificado cobre cinco domínios, um deles mudou para outro alojamento, o DNS mudou. A validação desse domínio deixa de passar, e o certbot não renova o certificado inteiro, com os quatro domínios que funcionam incluídos. Os domínios a mais têm de ser retirados do certificado, não ignorados juntamente com a mensagem.

5. Chegou aos limites

A Let’s Encrypt limita o número de certificados por domínio e por semana. É normalmente consequência do ciclo «não resultou, tento outra vez» durante a depuração. Para experiências existe um servidor de testes (--dry-run ou --test-cert), e deve ser usado antes de esgotar o limite, não depois.

Verifique o que é entregue, não o que está guardado

Toda a verificação baseada em ficheiros tem o mesmo defeito: o ficheiro pode estar fresco enquanto o visitante recebe o certificado antigo. Olhe do lado do cliente:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

A opção -servername é indispensável: sem ela, num servidor com vários sítios obterá o certificado do primeiro anfitrião virtual que aparecer e não o que pretendia. Na saída, notAfter é a verdadeira data de expiração.

Aproveite para verificar a cadeia:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Se houver apenas um certificado, o intermédio não está a ser entregue. Os navegadores costumam perdoar essa configuração — constroem a cadeia sozinhos — mas o curl, as aplicações móveis e os clientes em Java falharão a validação. É o clássico «a mim abre tudo e ao cliente não funciona».

Quantos dias de aviso

Trinta dias são um primeiro limiar razoável: é também o que resta quando o certbot começa as tentativas de renovação, pelo que se até aí nada aconteceu, o mecanismo está partido. Catorze dias são o segundo sinal, o que já exige agir hoje. Sete são uma emergência.

O importante é acompanhar todos os certificados ao mesmo tempo, incluindo os que não vêm da Let’s Encrypt: os comprados por um ano são os que mais seguramente se esquecem, porque num ano toda a gente esqueceu tanto eles como a caixa de correio para onde chegam os avisos. Uma página com os domínios, as datas e os dias restantes encerra a questão por completo, como na demonstração abaixo.