Certbot renew sem reload do nginx: o navegador ainda vê o certificado vencido

O certbot renew terminou com “Congratulations, all renewals succeeded” e mesmo assim o navegador acusa certificado expirado. O arquivo novo está no disco, mas o nginx leu o certificado uma vez, quando subiu, e continua servindo aquela cópia da memória. Quem instalou pelo plugin --nginx nem vê esse problema; ele pega quem emitiu com certonly --webroot e nunca configurou o reload.

Confirme que é isso mesmo

Compare a data que está no disco com a data que o servidor entrega na porta 443:

openssl x509 -noout -dates -in /etc/letsencrypt/live/exemplo.com.br/fullchain.pem

openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br </dev/null 2>/dev/null 
  | openssl x509 -noout -dates

Se o notAfter do arquivo é de daqui a três meses e o da conexão é de semana passada, o diagnóstico está fechado. Um sudo systemctl reload nginx resolve na hora, sem derrubar conexão: o master relê os arquivos e troca os workers antigos pelos novos conforme eles terminam de responder.

Para não repetir daqui a 60 dias

O certbot executa tudo que estiver em /etc/letsencrypt/renewal-hooks/deploy/ depois de cada renovação bem-sucedida, para todos os domínios. Crie o script ali e dê o bit de execução:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
/usr/sbin/nginx -t && /usr/bin/systemctl reload nginx
EOF

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Sem o chmod +x o certbot ignora o arquivo em silêncio e você volta ao mesmo problema no próximo ciclo. Para conferir que ele enxergou o script, rode sudo certbot renew --dry-run e procure em /var/log/letsencrypt/letsencrypt.log a linha Dry run: skipping deploy hook command com o caminho do seu arquivo. O dry run não executa deploy hook nenhum, então essa linha é a única prova que ele te dá.

Se travou nisso e precisa de ajuda, me chama aqui.