Configuração de certificado SSL: renovação automática com Let's Encrypt e gerenciamento de vários domínios

O e-mail de monitoramento acordou toda a equipe. O site estava fora do ar, e as ligações de usuários reclamando não paravam de chegar ao atendimento. Ao abrir o navegador, apareceu a página vermelha de alerta: “O certificado de segurança deste site expirou”. Pronto, tínhamos um problema sério.

Levantei, conectei ao servidor e descobri que o certificado SSL havia vencido na noite anterior. A renovação manual só terminou às cinco da manhã. Depois de dormir duas horas, já era hora de trabalhar novamente.

Depois disso, fiquei pensando: seria possível eliminar de vez o risco de um certificado expirar? Quando conheci o Let’s Encrypt, percebi que a renovação automática de certificados SSL gratuitos já era uma solução madura. Muitos desenvolvedores, inclusive eu naquela época, ainda estavam presos à antiga rotina de gerenciamento manual.

O objetivo deste artigo é bem claro: impedir que certificados SSL expirem e evitar confusão ao gerenciar vários domínios. Seja para um blog pessoal ou para serviços de uma empresa, você poderá aplicar a configuração diretamente depois da leitura.

O que é o Let’s Encrypt? Primeiro, entenda como ele funciona

Sinceramente, muita gente usa o Let’s Encrypt sem entender como ele funciona. Conhecer o princípio por trás dele ajuda a localizar rapidamente a causa de um problema.

O papel de uma autoridade certificadora (CA)

O Let’s Encrypt é uma autoridade certificadora, também chamada de CA. Sua proposta é clara: ser gratuito, automatizado e aberto. Desde o lançamento, em 2016, ele impulsionou a adoção do HTTPS em poucos anos — hoje são mais de 200 milhões de certificados ativos e 100% de confiança entre os navegadores do mundo.

As CAs tradicionais, como DigiCert e GeoTrust, cobram caro, têm processos trabalhosos e ainda exigem análise manual. O Let’s Encrypt é diferente: tudo é automatizado. Você solicita, ele valida e emite o certificado. A validade é de 90 dias, o que pode parecer pouco, mas, com a renovação automática, torna o processo mais seguro. Por quê? Quanto menor a duração do certificado, menor o período de exposição.

Protocolo ACME: o núcleo da automação

O Let’s Encrypt usa o protocolo ACME (Automated Certificate Management Environment), padronizado pela RFC 8555. Esse protocolo define como validar automaticamente a propriedade de um domínio e como emitir o certificado.

Há três métodos de validação:

1. Validação HTTP-01: é a mais comum. A CA acessa um caminho específico no domínio (/.well-known/acme-challenge/) e verifica se ele contém o token de validação, comprovando que você controla o domínio.
2. Validação DNS-01: obrigatória para certificados wildcard. A CA verifica se há um token de validação em um registro DNS TXT. Não exige servidor web, mas requer acesso à API do DNS.
3. Validação TLS-ALPN-01: menos comum e indicada para cenários específicos.

O HTTP-01 é o método mais simples, desde que a porta 80 esteja acessível. O DNS-01 é mais flexível e funciona bem para serviços internos ou certificados wildcard.

Certbot: o cliente recomendado oficialmente

O Certbot é a ferramenta cliente recomendada oficialmente pelo Let’s Encrypt. Ele cuida de todo o processo: solicita o certificado, configura o servidor web e prepara a renovação automática.

Principais recursos do Certbot:

• Compatibilidade com vários métodos de validação
• Alteração automática da configuração do Nginx/Apache por meio de plugins
• Configuração automática de um systemd timer ou cron job
• Comando para testar a renovação (dry-run)

Depois de entender esses princípios, você saberá onde procurar quando surgir um problema durante a configuração.

Configuração de certificado SSL para um domínio: do zero

Vamos começar pelo cenário mais simples: um domínio e um servidor. Depois de entender o fluxo básico, gerenciar vários domínios fica muito mais natural.

Instalar o Certbot

O método de instalação varia de acordo com o sistema. No Ubuntu/Debian, a opção mais simples é usar o Snap — também é o método recomendado oficialmente e recebe atualizações rapidamente.

Ubuntu/Debian (via Snap):

# Instalar o Snap (se ainda não estiver instalado)
sudo apt update
sudo apt install snapd

# Instalar o Certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

CentOS/RHEL:

sudo yum install certbot
# ou
sudo dnf install certbot

Depois da instalação, faça um teste:

certbot --version
# A saída deve ser parecida com: certbot 2.11.0

Obter o certificado: três métodos

O Certbot oferece três formas de obter um certificado. Escolha conforme a sua necessidade.

Método 1: configuração automática com o plugin do Nginx (recomendado para iniciantes)

É a opção mais prática. O Certbot altera automaticamente a configuração do Nginx, solicita o certificado, configura o HTTPS e prepara o redirecionamento. Tudo com um único comando:

sudo certbot --nginx -d example.com -d www.example.com

Durante a execução, algumas perguntas serão feitas:

• Endereço de e-mail para notificações urgentes
• Aceitação dos termos de serviço
• Se deseja compartilhar o e-mail (escolha No)
• Se deseja redirecionar HTTP para HTTPS (escolha Yes, por ser mais seguro)

Ao terminar, a configuração do Nginx já estará atualizada. Os caminhos do certificado serão exibidos:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem

Método 2: configuração automática com o plugin do Apache

Funciona como no Nginx, mas usando o plugin do Apache:

sudo certbot --apache -d example.com -d www.example.com

Método 3: obter apenas o certificado (configuração manual)

Se você não quiser que o Certbot altere a configuração ou usar outro servidor web, como Caddy ou Node.js, pode utilizar o modo certonly:

sudo certbot certonly --webroot \
  -w /var/www/html \
  -d example.com \
  -d www.example.com

O parâmetro -w informa o diretório raiz do site, onde o Certbot colocará o arquivo de validação. Depois de obter o certificado, você configura o servidor web manualmente.

Verificar se o certificado está funcionando

Depois de solicitar o certificado, confirme se ele funciona corretamente.

Verificar os arquivos do certificado

sudo ls -la /etc/letsencrypt/live/example.com/

Você deve encontrar quatro arquivos:

• cert.pem: o certificado
• chain.pem: a cadeia intermediária de certificados
• fullchain.pem: a cadeia completa de certificados (use este arquivo no Nginx)
• privkey.pem: a chave privada (use este arquivo no Nginx)

Teste do SSL Labs

Acesse https://www.ssllabs.com/ssltest/ e informe o domínio. O teste atribui uma nota de A+ a F. O objetivo é alcançar pelo menos A.

Problemas comuns:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

• B ou C: versão antiga do TLS ou conjunto de cifras fraco. Mais adiante, veremos como otimizar isso.
• F: cadeia de certificados incompleta. Verifique se o Nginx usa fullchain.pem, e não cert.pem.

Acesso pelo navegador

Abra https://example.com. A barra de endereço deve mostrar o ícone de cadeado. Ao clicar nele, você poderá consultar os detalhes do certificado e verá “Let’s Encrypt” como emissor.

Configuração da renovação automática: não se preocupe mais com vencimentos

Os certificados do Let’s Encrypt são válidos por apenas 90 dias. Pode parecer pouco, mas, com a renovação automática, isso se torna uma vantagem: os certificados são trocados com frequência e o período de exposição é menor.

Como funciona a renovação automática do Certbot

Ao instalar o Certbot, ele configura automaticamente um mecanismo de renovação. A forma varia conforme o sistema:

Systemd Timer (Linux moderno):

Depois da instalação, o Certbot cria certbot.timer e certbot.service. O Timer é executado duas vezes por dia e verifica se algum certificado vencerá em até 30 dias. Se for o caso, ele aciona o Service para renovar.

Verifique o estado do Timer:

sudo systemctl list-timers | grep certbot

A saída será parecida com:

NEXT                         LEFT          LAST                         PASSED       UNIT           ACTIVATES
Thu 2026-04-02 12:00:00 UTC  1h left       Thu 2026-04-02 00:00:00 UTC  11h ago      certbot.timer  certbot.service

É possível ver os horários da próxima e da última execução.

Cron Job (método tradicional):

Se o sistema não tiver systemd, como em versões antigas do CentOS, o Certbot configura um cron job. Verifique com:

sudo crontab -l
# ou
cat /etc/cron.d/certbot

Configuração típica:

0 0,12 * * * root certbot renew --quiet

A verificação de renovação é executada todos os dias à meia-noite e ao meio-dia.

Verificar se a renovação automática funciona

Não basta ver o Timer ou o Cron. É preciso confirmar que a renovação realmente pode ser executada.

Teste Dry Run

O Certbot oferece um comando de teste que simula o processo sem renovar o certificado de verdade:

sudo certbot renew --dry-run

A saída será parecida com:

Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
...
The dry run was successful.

Se aparecer “successful”, a renovação automática está configurada corretamente.

Verificar o arquivo de configuração da renovação

Cada certificado tem seu próprio arquivo de configuração de renovação:

cat /etc/letsencrypt/renewal/example.com.conf

Esse arquivo registra os parâmetros usados na solicitação do certificado e o método de validação. A configuração será lida durante a renovação.

Recarregar automaticamente o servidor web depois da renovação

Depois que o certificado é renovado, o servidor web ainda pode estar usando o certificado antigo. É preciso recarregar a configuração para ativar o novo arquivo.

Deploy Hook (recomendado)

Execute automaticamente um comando após uma renovação bem-sucedida:

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

Ou adicione ao arquivo de configuração da renovação:

# Editar /etc/letsencrypt/renewal/example.com.conf
# Adicionar ao final:
deploy_hook = systemctl reload nginx

Post Hook (executado sempre)

É executado independentemente de a renovação ter sido bem-sucedida:

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

A diferença é que o Deploy Hook só é acionado após uma renovação bem-sucedida, enquanto o Post Hook é executado sempre. O Deploy Hook costuma ser a escolha mais adequada.

O que fazer quando a renovação falha?

A renovação automática não é infalível e pode falhar ocasionalmente. Veja as causas mais comuns e como resolvê-las.

Problema de resolução DNS

O DNS do domínio foi alterado, mas a CA ainda encontra o IP antigo durante a validação. Aguarde a propagação do DNS, de acordo com o TTL, ou force a renovação manual:

sudo certbot renew --force-renewal

Problema de firewall ou porta

A validação HTTP-01 exige que a porta 80 esteja acessível. Verifique o firewall:

sudo ufw status
sudo iptables -L -n

Libere temporariamente a porta 80:

sudo ufw allow 80/tcp

Problema de permissão

Verifique se as permissões dos arquivos do certificado estão corretas:

sudo ls -la /etc/letsencrypt/live/
sudo ls -la /etc/letsencrypt/archive/

Garanta que o usuário do servidor web, como www-data, consiga ler o certificado.

Consultar o log de renovação

Quando houver uma falha, consulte o log detalhado:

sudo tail -f /var/log/letsencrypt/letsencrypt.log

O log registra a causa da falha. Resolva o problema conforme a mensagem apresentada.

Gerenciamento de certificados SSL para vários domínios: estratégias centralizadas e separadas

Quando há vários domínios, a estratégia de gerenciamento dos certificados é importante. Sem organização, tudo vira uma confusão: datas de renovação diferentes, arquivos espalhados e configurações sujeitas a erros.

Um certificado para vários domínios (modo SAN)

A abordagem mais recomendada é incluir vários domínios em um único certificado. Basta informar todos eles ao solicitar com o Certbot:

sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  -d api.example.com \
  -d admin.example.com

Vantagens:

• Renovação unificada: uma única renovação atualiza todos os domínios
• Arquivos centralizados: há apenas um diretório de certificado
• Configuração simples: o servidor web precisa referenciar apenas um caminho de certificado

Extensão SAN (Subject Alternative Names): é um campo do certificado que lista todos os domínios incluídos. O navegador verifica se o domínio acessado está na lista SAN.

Veja quais domínios estão incluídos no certificado:

sudo certbot certificates

A saída será parecida com:

Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com api.example.com admin.example.com
    Expiry Date: 2026-07-01 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem

Certificado wildcard

Um certificado wildcard usa um curinga para cobrir todos os subdomínios: *.example.com. Um único certificado cobre blog.example.com, api.example.com, admin.example.com e outros.

A validação DNS-01 é obrigatória: o HTTP-01 não oferece suporte a certificados wildcard. O Certbot precisa acessar a API do DNS para adicionar o registro TXT.

Configurar o plugin de DNS

Cada provedor de DNS usa um plugin diferente. O Cloudflare é um dos mais comuns:

# Instalar o plugin do Cloudflare
sudo snap install certbot-dns-cloudflare

# Criar o arquivo de credenciais
sudo nano /root/.secrets/certbot/cloudflare.ini

Conteúdo do arquivo de credenciais:

dns_cloudflare_api_token = your_cloudflare_api_token

Gere o API Token no painel do Cloudflare e atribua a permissão “DNS:Edit”.

Solicitar o certificado wildcard

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d example.com

Observação: solicite *.example.com e example.com juntos. O wildcard não cobre o domínio raiz.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Limitações do certificado wildcard

Cobre apenas subdomínios de primeiro nível: *.example.com cobre sub.example.com, mas não cobre sub.sub.example.com.

Se houver subdomínios de segundo nível, solicite-os separadamente:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d "*.api.example.com" \
  -d example.com

Assim, o certificado cobre api.example.com e v1.api.example.com.

Estratégias para gerenciar vários certificados

Quando usar um único certificado para vários domínios? Quando usar vários certificados?

Agrupar por serviço (recomendado)

Grupo de serviços web: site principal, blog e documentação

sudo certbot --nginx -d example.com -d www.example.com -d blog.example.com -d docs.example.com

Grupo de serviços de API: endpoints de API e painel administrativo

sudo certbot --nginx -d api.example.com -d admin.example.com -d v1.api.example.com

Grupo de serviços internos: monitoramento, logs e ferramentas internas

sudo certbot certonly --dns-cloudflare -d "*.internal.example.com"

Vantagens:

• Escopo controlado da renovação: renovar o serviço de API não afeta o serviço web
• Isolamento de permissões: as permissões dos certificados de serviços internos podem ser gerenciadas separadamente
• Isolamento de falhas: um problema em um certificado não afeta os outros serviços

Agrupar por nível de domínio

Combine certificados wildcard e de domínio único:

# O wildcard cobre todos os subdomínios
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Certificado separado para um subdomínio especial (quando precisar de configuração específica)
sudo certbot --nginx -d secure.example.com

Entenda os caminhos dos arquivos de certificado

Compreender a estrutura dos diretórios evita confusão ao gerenciar vários certificados.

Diretório dos certificados em uso: /etc/letsencrypt/live/[nome-do-certificado]/

Os links simbólicos apontam para o certificado mais recente. A cada renovação, os links são atualizados para os novos arquivos.

sudo ls -la /etc/letsencrypt/live/example.com/
lrwxrwxrwx 1 root root  42 Apr  2 12:00 cert.pem -> ../../archive/example.com/cert2.pem
lrwxrwxrwx 1 root root  43 Apr  2 12:00 chain.pem -> ../../archive/example.com/chain2.pem
lrwxrwxrwx 1 root root  44 Apr  2 12:00 fullchain.pem -> ../../archive/example.com/fullchain2.pem
lrwxrwxrwx 1 root root  40 Apr  2 12:00 privkey.pem -> ../../archive/example.com/privkey2.pem

Diretório de arquivamento dos certificados: /etc/letsencrypt/archive/[nome-do-certificado]/

Ele guarda o histórico dos certificados de cada renovação. Os nomes dos arquivos incluem um número, como cert1.pem e cert2.pem.

Diretório de configuração da renovação: /etc/letsencrypt/renewal/[nome-do-certificado].conf

Registra os parâmetros usados na solicitação do certificado. Esse arquivo é lido durante a renovação.

# Ver a configuração de renovação de um certificado
cat /etc/letsencrypt/renewal/example.com.conf

A configuração inclui:

• Método de validação (webroot, nginx ou dns-cloudflare)
• Lista original de domínios
• Deploy Hook e outros parâmetros

Configuração avançada e otimização: equilibrando segurança e desempenho

Depois de concluir a configuração básica, você pode fazer outras otimizações. O objetivo é equilibrar segurança e desempenho.

HTTP/2 e OCSP Stapling

O HTTP/2 melhora o desempenho, enquanto o OCSP Stapling reduz a latência da validação.

Configurar HTTP/2 no Nginx

server {
    listen 443 ssl http2;  # Adicionar http2
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... Outras configurações
}

Adicione http2 depois da diretiva listen. Em seguida, recarregue o Nginx:

sudo nginx -t
sudo systemctl reload nginx

Configurar OCSP Stapling

O OCSP (Online Certificate Status Protocol) verifica o estado do certificado. Com Stapling, o servidor obtém antecipadamente o resultado da validação, e o cliente não precisa consultar a CA separadamente.

server {
    # ... Configuração SSL

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

Depois da configuração, o teste do SSL Labs mostrará “OCSP Stapling: Yes”.

Reforço de segurança: desative versões antigas do TLS

TLS 1.0 e 1.1 já não são seguros. Desde 2020, os principais navegadores deixaram de oferecer suporte a eles.

server {
    # Manter apenas TLS 1.2 e 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # Conjunto de cifras recomendado (equilíbrio entre segurança e compatibilidade)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    ssl_prefer_server_ciphers on;

    # Cache de sessão SSL (melhora o desempenho)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
}

Depois da configuração, o teste do SSL Labs deve alcançar A ou A+.

Configurar o cabeçalho HSTS

O HSTS (HTTP Strict Transport Security) obriga o navegador a acessar o site apenas por HTTPS. Depois de configurado, o navegador memoriza que o domínio deve usar HTTPS e, mesmo que o usuário digite http://, faz o redirecionamento automaticamente.

server {
    # ... Configuração SSL

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

Significado dos parâmetros:

• max-age=31536000: validade de um ano, em segundos
• includeSubDomains: inclui todos os subdomínios
• preload: permite incluir o domínio na lista de pré-carregamento dos navegadores

Atenção: depois de configurar o HSTS, o navegador pode recusar o acesso se você precisar usar HTTP temporariamente, por exemplo, em um teste. Use com cuidado.

Monitoramento e alertas: descubra problemas com antecedência

A renovação automática não é infalível. Se ela falhar, você precisa saber antes que o certificado expire. Um alerta com uma semana de antecedência dá tempo para resolver o problema manualmente.

Script simples de monitoramento

Crie um script para verificar quantos dias restam até o vencimento do certificado:

#!/bin/bash
# /usr/local/bin/check-ssl-expiry.sh

DOMAIN="example.com"
EXPIRY_DAYS=$(openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)

EXPIRY_DATE=$(date -d "$EXPIRY_DAYS" +%s)
CURRENT_DATE=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_DATE - $CURRENT_DATE) / 86400 ))

if [ $DAYS_LEFT -lt 7 ]; then
    echo "WARNING: SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
    # Enviar um alerta por e-mail (é preciso configurar o serviço de e-mail)
    mail -s "SSL Certificate Expiry Warning" [email protected] <<< "SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
fi

Adicione ao cron para executar a verificação diariamente:

0 6 * * * /usr/local/bin/check-ssl-expiry.sh

Notificações automáticas do Certbot

Quando uma renovação falha, o Certbot envia uma mensagem para o e-mail usado na solicitação do certificado. Verifique se o endereço está correto e se você consegue receber as mensagens.

Problemas comuns e soluções

Vários problemas podem surgir durante a configuração. Veja a seguir os erros mais frequentes e como resolvê-los.

Falha ao solicitar o certificado

Causa 1: o DNS do domínio não aponta para o servidor

Ao solicitar o certificado, a CA precisa validar a propriedade do domínio. A validação HTTP-01 exige acesso ao domínio. Se o DNS ainda não estiver configurado, a validação falhará.

Verificar o DNS:

dig example.com +short
# ou
nslookup example.com

Confirme se o IP retornado é o IP do servidor.

Solução: aguarde a propagação do DNS. Tente novamente após o TTL, que normalmente varia de alguns minutos a algumas horas.

Causa 2: a porta 80 está ocupada ou bloqueada pelo firewall

A validação HTTP-01 usa a porta 80. Se outro processo estiver ocupando a porta ou se o firewall bloquear o acesso, a validação falhará.

Verificar o uso da porta:

sudo netstat -tulpn | grep :80
sudo lsof -i :80

Se a porta não estiver sendo usada pelo Nginx/Apache, interrompa o processo responsável:

sudo systemctl stop nome-do-serviço

Verificar o firewall:

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

sudo ufw status
# ou
sudo iptables -L -n

Libere as portas 80 e 443:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Causa 3: problema de permissão no diretório webroot

Ao usar certonly --webroot, o Certbot precisa criar o arquivo de validação no diretório raiz do site. Se não houver permissão suficiente, a operação falhará.

Verificar as permissões do diretório:

ls -la /var/www/html/.well-known/

Garanta que o usuário do Certbot, normalmente root, possa gravar no diretório.

Criar o diretório manualmente:

sudo mkdir -p /var/www/html/.well-known/acme-challenge
sudo chown -R www-data:www-data /var/www/html/.well-known

Como lidar com falhas na renovação

A renovação automática pode falhar de vez em quando. Não entre em pânico: primeiro consulte o log e depois corrija a causa específica.

Consultar o log do Certbot

sudo tail -100 /var/log/letsencrypt/letsencrypt.log

O log mostrará a causa da falha. Erros comuns:

• Connection refused: problema de porta
• DNS problem: NXDOMAIN: problema de resolução DNS
• Rate limit exceeded: limite de solicitações excedido

Forçar a renovação manual

Se a renovação automática falhar, renove manualmente:

sudo certbot renew --force-renewal

--force-renewal força a renovação, mesmo quando o certificado ainda não está próximo do vencimento.

Verificar a configuração da renovação

Um arquivo de configuração de renovação corrompido também pode causar falhas. Verifique-o:

cat /etc/letsencrypt/renewal/example.com.conf

Confirme se a configuração está correta. Se estiver corrompida, exclua o certificado e solicite outro:

sudo certbot delete --cert-name example.com
sudo certbot --nginx -d example.com -d www.example.com

Conflito entre vários certificados

Quando há vários certificados, o servidor web pode apontar para o arquivo errado.

Caminho incorreto do certificado no Nginx

Verifique a configuração do Nginx:

sudo nginx -T | grep ssl_certificate

Confirme se cada server block usa o caminho correto do certificado.

Erros comuns:

• Usar cert.pem em vez de fullchain.pem, deixando a cadeia de certificados incompleta
• Referenciar o diretório de certificado errado, quando o nome do certificado não coincide com o domínio

Nome do certificado diferente do domínio

O Certbot usa o primeiro domínio como nome do certificado. Por exemplo:

sudo certbot --nginx -d api.example.com -d example.com

O nome do certificado será api.example.com, e o caminho será /etc/letsencrypt/live/api.example.com/.

Se a configuração do Nginx apontar para /etc/letsencrypt/live/example.com/, o certificado não será encontrado.

Ver o nome do certificado:

sudo certbot certificates

Confirme se o nome e o caminho do certificado correspondem.

Limitações dos certificados wildcard

Os certificados wildcard são práticos, mas têm limitações.

Cobrem apenas subdomínios de primeiro nível

*.example.com cobre sub.example.com, mas não cobre sub.sub.example.com.

Se houver subdomínios de segundo nível, será preciso obter outro certificado:

# Certificado wildcard (primeiro nível)
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Certificado para subdomínios de segundo nível
sudo certbot certonly --dns-cloudflare -d "*.api.example.com"

Não cobrem o domínio raiz

*.example.com não cobre example.com, o domínio raiz. É obrigatório adicionar -d example.com separadamente.

Exemplo incorreto:

# Incorreto: o domínio raiz não estará acessível
sudo certbot certonly --dns-cloudflare -d "*.example.com"

Exemplo correto:

# Correto: inclui também o domínio raiz
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

Conclusão: a evolução do processo manual para o automático

Configurar certificados SSL é, na prática, uma evolução do trabalho manual para a automação. O processo manual das CAs tradicionais se torna simples e confiável com o sistema automatizado do Let’s Encrypt.

Resumo dos pontos principais:

1. Entenda o princípio: o protocolo ACME define o fluxo automático de validação e emissão. HTTP-01 e DNS-01 são dois métodos de validação, cada um adequado a cenários diferentes.
2. Renovação automática: depois de instalado, o Certbot configura automaticamente um systemd timer ou cron job. A renovação é acionada 30 dias antes do vencimento, com duas verificações por dia.
3. Gerenciamento de vários domínios: o modo SAN, com vários domínios em um certificado, facilita o gerenciamento unificado; certificados wildcard são indicados para muitos subdomínios. Agrupar certificados por serviço é a estratégia recomendada.
4. Otimização de segurança: HTTP/2, OCSP Stapling, desativação de versões antigas do TLS e HSTS ajudam a alcançar a nota A+ no SSL Labs.
5. Monitoramento e alertas: a renovação automática não é infalível. Monitore proativamente os dias restantes do certificado para identificar problemas com antecedência.

Próximos passos de otimização:

Se você gerencia vários servidores e muitos domínios, considere:

• Plataformas de automação: como Cert Manager para Kubernetes e Traefik com SSL automático
• Serviços de monitoramento de certificados: como SSL Monitor e Uptime Robot
• Integração com CI/CD: verifique automaticamente o estado do certificado durante a implantação

Depois de automatizar o gerenciamento dos certificados, você não precisa mais se preocupar com isso. O site fica seguro, ganha a confiança dos usuários e agrada aos mecanismos de busca. Os alertas às três da manhã finalmente ficam no passado.