Renovação Let's Encrypt: as três falhas clássicas

A renovação automática de certificado tem uma personalidade muito sua: funciona impecavelmente durante meses, depois para, e não o diz a ninguém. O comando continua a correr à sua hora. Simplesmente sai em erro, num ficheiro de registo que ninguém abre. Eis as três formas como quebra realmente, e a única verificação que as apanha às três.

As três avarias, numa tabela

A terceira linha é a que sai mais cara, precisamente porque o registo parece perfeito. Uma supervisão que lê o registo de renovação declara portanto que corre tudo bem enquanto os seus visitantes veem um ecrã vermelho.

1. O desafio de validação já não alcança o seu servidor

Para confirmar que controla o domínio, a autoridade de certificação pede um ficheiro sob /.well-known/acme-challenge/… no seu site. O seu servidor deve servi-lo, em HTTP simples, sem interferência.

O que quebra isso, meses depois da instalação:

• Um redirecionamento global para HTTPS ou para um novo domínio, acrescentado por excelentes razões, e que apanha também o caminho do desafio.
• Uma regra de firewall ou de WAF que começa a filtrar os caminhos desconhecidos, ou que bloqueia os endereços de onde chega a validação.
• Uma rota apanha-tudo de framework que transforma cada URL desconhecido em página 404, incluindo o ficheiro de desafio, que devolve agora um 404 numa bonita paginação.
• Uma proteção antirrobôs instalada à frente do site, que apresenta uma página de espera a todo o cliente que não execute JavaScript.

O comando de renovação não mudou. O seu ambiente sim. É o que torna difícil imputar esta avaria: ninguém tocou no certificado, e no entanto já não se renova.

O teste cabe numa linha, a partir de qualquer máquina:

mkdir -p /var/www/html/.well-known/acme-challenge && echo ok > /var/www/html/.well-known/acme-challenge/test
curl -sI http://exemplo.pt/.well-known/acme-challenge/test | head -n 1

A resposta esperada é 200. Um 301 para HTTPS já é um problema em certas configurações, e um 403 ou um 404 é-o sempre.

2. O DNS mexeu-se

Se renova um certificado universal, a validação passa por um registo DNS em vez de um ficheiro. Isso pressupõe uma chave de API no seu fornecedor de DNS, posta num ficheiro de configuração, e que expira ou é revogada em silêncio no dia em que alguém roda as credenciais.

Três variantes da mesma história:

• A chave foi revogada durante uma limpeza de segurança, seis meses antes.
• O domínio foi transferido para outro registador, e ninguém se lembrou de informar o script.
• Os servidores de nomes mudaram, a zona é agora gerida noutro sítio, e o script escreve conscienciosamente o seu registo numa zona que já ninguém consulta.

Nos três casos, o erro é explícito no registo. Falta ainda que alguém o abra, e é aí que está todo o problema. Quem gere um certificado universal faria bem em pôr o ensaio em seco no mesmo dia em que revê as credenciais: as duas tarefas falham pela mesma razão.

3. A renovação resultou, a instalação não

É a versão cruel. O novo certificado está no disco, datado de hoje, perfeitamente válido. O seu servidor web continua a apresentar o antigo, porque não foi recarregado desde o arranque.

Nada no registo de renovação parece anormal. O ficheiro está lá. E os seus visitantes recebem na mesma o aviso de segurança em ecrã inteiro.

A causa é quase sempre um gancho de recarga ausente ou silencioso:

# A recarga deve fazer parte da renovação, não de um gesto manual
--deploy-hook "systemctl reload nginx"

Duas armadilhas a conhecer. Um gancho que falha não faz falhar a renovação: deixa uma mensagem no registo e devolve o controlo. E um serviço que precisa de um reinício completo, em vez de uma recarga, não pega no novo ficheiro; é frequente nas configurações que terminam o TLS fora do servidor web, atrás de um proxy ou de um balanceador de carga, onde o certificado tem de ser empurrado em dois sítios.

A quarta avaria, mais rara e mais desconcertante

As três anteriores vêm da sua instalação. Esta vem de outro lado, e desconcerta porque o comando está correto e o servidor é irrepreensível.

A quota foi atingida. As autoridades de certificação limitam o número de certificados emitidos para um mesmo domínio num período dado. Chega-se lá raramente em funcionamento normal, e muito facilmente em ciclo de depuração: dez tentativas de reemissão numa tarde, e ei-lo bloqueado durante uma semana com um certificado expirado em produção. É a razão de ser do ensaio em seco, que não consome nada.

A chave de conta desapareceu. Uma reinstalação do servidor, um restauro parcial, um contentor reconstruído sem o seu volume: o cliente já não encontra a conta que possuía os certificados, e recomeça do zero sem o dizer com clareza.

O domínio já não resolve para si. Um registo modificado, uma migração em curso, uma mudança mal terminada. A validação falha porque aterra noutra máquina, o que é exato e nada tem a ver com o certificado.

Diagnosticar em três comandos

certbot renew --dry-run                 # repete toda a renovação sem consumir quota
curl -sI http://exemplo.pt/.well-known/acme-challenge/test   # o desafio passa?
echo | openssl s_client -connect exemplo.pt:443 2>/dev/null | openssl x509 -noout -dates

O primeiro apanha as avarias 1 e 2. O terceiro apanha a avaria 3, e é o único que diz o que o público recebe realmente.

E se quer apenas saber o que o público recebe neste momento, sem abrir um terminal, a página que lê um certificado responde a essa pergunta precisa com um endereço.

O que não fazer durante a avaria

Não reemita em ciclo: é assim que um problema reparável se torna um problema de uma semana. Não corte o HTTPS para «repor o site em linha»: todos os links da web que apontam para os seus endereços em https:// quebrariam, e os navegadores memorizam durante muito tempo essa preferência. E não instale um certificado autoassinado como remendo: produz exatamente a mesma página vermelha, com as mesmas consequências, mais um segundo problema para desfazer depois.

A verificação que apanha as três

Cada uma destas avarias é invisível do interior e evidente do exterior. Então olhe do exterior: abra uma ligação TLS para o seu próprio nome de anfitrião e leia a data de expiração do certificado realmente servido.

Essa única medida cobre de uma vez um desafio falhado, um problema de DNS e uma recarga em falta, porque as três acabam no mesmo sítio: um certificado velho ainda apresentado ao público. Tem também o mérito de nada pressupor da sua instalação, o que a mantém válida após uma mudança de alojador ou de pilha técnica.

Alerte aos trinta dias, sete dias e um dia. Trinta deixam espaço para depurar com calma; um apanha a recarga que nunca aconteceu. Uma verificação diária basta largamente, e é um caso em que aumentar a frequência não traz nada: uma data de expiração não muda de uma hora para a outra.

Dois hábitos que valem a pena

Renovar com margem. Aos sessenta dias num certificado de noventa, uma falha deixa-lhe um mês em vez de uma tarde. É a definição predefinida da maioria dos clientes, e é um dos raros valores predefinidos que não se deve mesmo tocar.

Testar a renovação, não apenas o certificado. O ensaio em seco existe em quase todos os clientes. Lançá-lo uma vez por mês transforma uma avaria silenciosa numa avaria conhecida, meses antes de contar. E porque mais ninguém o avisará, é o seu único alerta antecipado.

Quando já expirou

Não procure primeiro a causa. Renove e recarregue, reponha o site em estado, e faça o inquérito depois: é a mesma ordem dos primeiros quinze minutos de um incidente, pela mesma razão, a saber, que um site bloqueado custa algo a cada minuto enquanto você compreende.

Nada disto muda o seu posicionamento, de passagem: o HTTPS pesa muito menos para os motores do que o pânico sugere. Conta para a pessoa que não consegue abrir o seu site.