Let's Encrypt: como funciona a renovação

O certificado expirou num domingo de madrugada

A primeira vez que isso me pegou, o monitoramento gritou às três da manhã: o site fora, navegadores cuspindo NET::ERR_CERT_DATE_INVALID, clientes sem conseguir pagar. O certificado tinha vencido. O certbot estava instalado, o timer rodando, tudo "automático" — e mesmo assim expirou. O problema não era a renovação, era que o servidor nunca recarregou o certificado novo. A renovação tinha funcionado em silêncio e ninguém aplicou o resultado.

Este texto explica como a renovação do Let's Encrypt funciona de verdade, onde ela costuma falhar e como não ser acordado de madrugada por um certificado vencido. Antes de mais nada, se você ainda duvida de certificado gratuito em produção, leia se um certificado SSL gratuito é seguro — spoiler: é o mesmo TLS de qualquer outro.

Por que os certificados duram só 90 dias

Quem vem de certificado pago de um ano estranha a validade curta do Let's Encrypt: noventa dias. Não é limitação técnica, é decisão de design, e é uma boa decisão.

Validade curta força automação. Se o certificado dura um ano, você renova manualmente, esquece, e ele vence — exatamente o cenário do parágrafo de abertura. Com noventa dias, manual é insustentável, então você automatiza, e automação é o estado correto. O segundo motivo é limitar o estrago de uma chave vazada: se uma chave privada vaza, a janela de exposição é de no máximo noventa dias, não de um ano inteiro. Validade curta é uma propriedade de segurança, não um incômodo.

ACME e o desafio: HTTP-01 vs DNS-01

Por trás de tudo está o protocolo ACME. Para emitir ou renovar, a CA precisa provar que você controla o domínio. Isso acontece via um "challenge", e os dois principais são:

• HTTP-01. A CA pede para você servir um arquivo específico em http://seu-dominio/.well-known/acme-challenge/<token>. Se ela consegue baixar, você controla o domínio na porta 80. Simples, mas exige a porta 80 aberta e um servidor web respondendo.
• DNS-01. Você publica um registro TXT em _acme-challenge.seu-dominio. A CA consulta o DNS e valida. Mais trabalhoso, porque precisa de acesso programático ao seu provedor de DNS, mas é o único que funciona para certificado wildcard.

# HTTP-01, plugin nginx cuida do challenge e do reload
sudo certbot --nginx -d exemplo.com -d www.exemplo.com

# DNS-01, obrigatório para wildcard
sudo certbot certonly --dns-cloudflare -d "*.exemplo.com" -d exemplo.com

A regra é direta: se você quer *.exemplo.com, esquece HTTP-01. Wildcard só sai com DNS-01.

Como a renovação automática acontece

O certbot moderno instala um systemd timer (ou uma entrada de cron) que roda certbot renew duas vezes por dia. Você pode conferir:

# o timer que dispara a renovação
systemctl list-timers | grep certbot

# simula a renovação sem aplicar nada
sudo certbot renew --dry-run

Aqui mora um detalhe que muita gente não sabe: certbot renew não renova todo dia. Ele só age quando o certificado está a menos de trinta dias do vencimento, ou seja, por volta do dia sessenta dos noventa. Antes disso, o comando roda, verifica e não faz nada. Isso é proposital: dá uma folga de trinta dias para algo dar errado e ainda haver tempo de corrigir antes de expirar. O --dry-run exercita o fluxo inteiro contra o ambiente de staging da CA sem gastar uma emissão de verdade.

A falha clássica: renovou mas não recarregou

Volto ao certificado do domingo de madrugada. A renovação funcionou: o certbot baixou um certificado novo, válido, salvo em disco. Mas o nginx (ou Apache, ou o que for) carrega o certificado na memória quando inicia e não relê o arquivo sozinho. Resultado: arquivo novo no disco, certificado velho na memória, e o velho expira.

A correção é o deploy-hook — um comando que o certbot roda só quando uma renovação de fato aconteceu:

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

Os plugins --nginx e --apache já fazem o reload por você; o furo aparece justamente em quem usa certonly e cuida do servidor à mão. Se você renova com certonly, o deploy-hook não é opcional. Sem ele, você cai exatamente na armadilha de ter a renovação verde no log e o site fora no ar.

Monitore a expiração para não ser surpreendido

Confiar cegamente na automação é como o sujeito que nunca testa o backup. A automação vai falhar um dia — o token do DNS expira, a porta 80 fica bloqueada por uma regra de firewall nova, um upgrade quebra o plugin. O que diferencia um susto de um incidente é descobrir antes do vencimento.

# quantos dias faltam para o certificado expirar
echo | openssl s_client -servername exemplo.com -connect exemplo.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Coloque um check externo que alerta quando faltam, digamos, vinte dias. Externo é a palavra-chave: precisa enxergar o certificado de fora, do ponto de vista de quem visita o site, não confiar no log local que diz "renovado com sucesso". O log mente quando o reload falha. O check externo não.

Perguntas frequentes

Preciso renovar o certificado manualmente alguma vez?

Em condições normais, não — o timer do certbot cuida disso. Você renova manualmente apenas para resolver uma falha, testar uma mudança de configuração ou forçar a emissão depois de corrigir algo. Se você está renovando à mão de rotina, a automação está quebrada e vale investigar.

Por que a renovação roda no dia 60 e não no 89?

Porque a janela de trinta dias é uma margem de segurança. Se a renovação falhar por qualquer motivo no dia sessenta, ainda restam quase trinta dias de tentativas diárias antes do certificado vencer. Renovar só no último dia não deixaria espaço para corrigir nada.

O que muda na renovação de um certificado wildcard?

Wildcard exige o desafio DNS-01, então a automação precisa de credenciais do seu provedor de DNS para criar e remover o registro TXT a cada renovação. Não dá para renovar wildcard com HTTP-01. O resto do fluxo do certbot é igual.

Renovar gera um certificado idêntico ou um novo?

Gera um certificado novo, com nova validade e, dependendo da configuração, nova chave. Por isso o reload do servidor é obrigatório: o arquivo em disco muda de fato. Tratar a renovação como "só estender o que existe" é a origem do erro de não recarregar.

O que garantir antes do próximo vencimento

A renovação do Let's Encrypt é confiável quando você entende as três partes: o ACME prova o domínio via challenge (HTTP-01 ou DNS-01 para wildcard), o timer do certbot renova por volta do dia sessenta, e — o ponto que mais derruba sites — o servidor precisa recarregar o certificado novo via deploy-hook. Automatize, mas não confie cegamente: rode --dry-run, garanta o reload e coloque um monitor externo de expiração. A validade de noventa dias é uma aliada de segurança, desde que a automação esteja realmente fechando o ciclo.