SSL Wildcard: como configurar subdomínios no AlmaLinux

SSL Wildcard é um certificado TLS que protege um domínio principal e todos os seus subdomínios de primeiro nível com um único arquivo de certificado. No AlmaLinux, a configuração ideal é realizada através do Certbot utilizando o desafio DNS-01, permitindo que todos os subdomínios sejam protegidos de forma centralizada e segura.

1. Instale o Certbot e o plugin DNS compatível no AlmaLinux 9
2. Configure as credenciais de API do seu provedor de DNS (como Cloudflare)
3. Emita o certificado Wildcard utilizando o DNS-01 challenge
4. Configure o servidor web Nginx para utilizar o certificado nos subdomínios
5. Habilite a renovação automática para evitar a expiração do SSL

Pré-requisitos para configurar SSL Wildcard no AlmaLinux

• Servidor com AlmaLinux 9 com acesso root via SSH
• Domínio próprio registrado e com DNS apontando para o servidor
• Acesso ao painel DNS do domínio (preferencialmente via API — Cloudflare, AWS Route 53, etc.)
• Nginx 1.24+ ou Apache instalado e em execução
• Porta 80 e 443 abertas no firewall (firewalld)
• Python 3.9+ disponível (versão padrão no AlmaLinux 9)

Se ainda não configurou o acesso SSH ao seu servidor, consulte o guia Acessando servidores VPS Linux da AviraHost antes de prosseguir.

Instalando o Certbot e o plugin DNS no AlmaLinux 9

O método mais eficiente para emitir um certificado SSL Wildcard via Let's Encrypt no AlmaLinux é usando o Certbot com um plugin DNS que automatiza o DNS-01 challenge. Sem o plugin, a renovação automática se torna impraticável porque exigiria intervenção manual a cada 90 dias, o que não é recomendado para ambientes profissionais.

Primeiro, atualize o sistema e instale o repositório EPEL:

dnf update -y
dnf install -y epel-release

Em seguida, instale o Certbot e o plugin para Cloudflare (substitua pelo plugin do seu provedor DNS, se diferente):

dnf install -y certbot python3-certbot-dns-cloudflare

Se o seu provedor for AWS Route 53, use:

dnf install -y certbot python3-certbot-dns-route53

Verifique a versão instalada para confirmar o sucesso:

certbot --version

certbot 2.11.0

Configurando as credenciais de API do Cloudflare para DNS-01

A validação DNS-01 do Let's Encrypt Wildcard exige que o Certbot crie automaticamente um registro TXT temporário no seu DNS. Para isso, o plugin precisa de um token de API com permissão de escrita na zona do domínio.

No painel do Cloudflare, gere um API Token com permissão Zone → DNS → Edit restrita ao domínio desejado. Evite usar a Global API Key, pois concede acesso irrestrito à conta inteira.

Crie o arquivo de credenciais com permissões restritas:

mkdir -p /etc/letsencrypt/secrets
nano /etc/letsencrypt/secrets/cloudflare.ini

Adicione o seguinte conteúdo ao arquivo:

dns_cloudflare_api_token = SEU_TOKEN_AQUI

Atenção: restrinja o acesso ao arquivo imediatamente para evitar exposição da credencial:

chmod 600 /etc/letsencrypt/secrets/cloudflare.ini
chown root:root /etc/letsencrypt/secrets/cloudflare.ini

Verifique as permissões aplicadas:

ls -la /etc/letsencrypt/secrets/cloudflare.ini

-rw------- 1 root root 62 Jan 15 10:23 /etc/letsencrypt/secrets/cloudflare.ini

Emitindo o certificado SSL Wildcard com DNS-01 challenge

Com as credenciais configuradas, você pode emitir o certificado Wildcard para proteger múltiplos subdomínios com um único comando. O parâmetro --dns-cloudflare-propagation-seconds define o tempo de espera para que o registro TXT se propague antes da validação — 60 segundos é suficiente para a maioria dos provedores DNS.

Execute o comando de emissão substituindo exemplo.com.br pelo seu domínio real:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d exemplo.com.br \
  -d "*.exemplo.com.br" \
  --agree-tos \
  --email [email protected] \
  --non-interactive

O output esperado ao final de uma emissão bem-sucedida é:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/exemplo.com.br/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/exemplo.com.br/privkey.pem
This certificate expires on 2026-04-15.
These files will be updated when the certificate renews.

Observe que os dois parâmetros -d exemplo.com.br e -d "*.exemplo.com.br" são necessários: o Wildcard cobre apenas subdomínios, não o domínio raiz. Incluir ambos garante que https://exemplo.com.br e https://app.exemplo.com.br sejam cobertos pelo mesmo certificado.

Configurando o Nginx para usar o certificado Wildcard nos subdomínios

Após a emissão, configure o servidor web Nginx para servir os subdomínios com o mesmo certificado. A vantagem do Wildcard é que um único bloco de configuração SSL pode ser reaproveitado para todos os virtual hosts do mesmo domínio.

Crie um arquivo de configuração para o domínio principal e seus subdomínios:

nano /etc/nginx/conf.d/exemplo.com.br.conf

Adicione a configuração base com SSL:

server {
    listen 80;
    server_name exemplo.com.br *.exemplo.com.br;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name exemplo.com.br;

    ssl_certificate /etc/letsencrypt/live/exemplo.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemplo.com.br/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    root /var/www/exemplo.com.br;
    index index.html index.php;
}

server {
    listen 443 ssl;
    server_name app.exemplo.com.br;

    ssl_certificate /etc/letsencrypt/live/exemplo.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemplo.com.br/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    root /var/www/app.exemplo.com.br;
    index index.html index.php;
}

server {
    listen 443 ssl;
    server_name api.exemplo.com.br;

    ssl_certificate /etc/letsencrypt/live/exemplo.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemplo.com.br/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Valide a sintaxe da configuração e recarregue o Nginx:

nginx -t && systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Para entender como o redirect HTTP para HTTPS funciona nas configurações acima, veja o guia Como redirecionar um site http para https?

Abrindo as portas no firewalld do AlmaLinux

O firewalld é o gerenciador de firewall padrão no AlmaLinux e precisa ter as portas HTTPS e HTTP liberadas para que o Nginx responda às requisições externas. Sem essa configuração, o navegador receberá connection refused mesmo com o certificado instalado corretamente.

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

success
success
success

Confirme que as regras estão ativas:

firewall-cmd --list-services

cockpit dhcpv6-client http https ssh

Configurando renovação automática do Wildcard com systemd timer

O Let's Encrypt emite certificados com validade de 90 dias. A renovação automática do Wildcard exige que o plugin DNS esteja disponível no momento da renovação, pois o DNS-01 challenge precisa ser revalidado. O Certbot instala automaticamente um systemd timer que tenta a renovação duas vezes ao dia.

Verifique se o timer está habilitado:

systemctl status certbot-renew.timer

● certbot-renew.timer - Run certbot twice daily
     Loaded: loaded (/usr/lib/systemd/system/certbot-renew.timer; enabled; preset: disabled)
     Active: active (waiting)

Se não estiver ativo, habilite manualmente:

systemctl enable --now certbot-renew.timer

Para testar a renovação sem efetivamente renovar o certificado:

certbot renew --dry-run

Congratulations, all simulated renewals succeeded:

Adicione um hook post-renew para recarregar o Nginx após cada renovação bem-sucedida. Crie o arquivo:

nano /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

#!/bin/bash
systemctl reload nginx

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

Com esse hook, o Nginx carregará automaticamente o novo certificado sem intervenção manual após cada renovação.

DNS-01 manual: como emitir o Wildcard sem API de DNS

Se o seu provedor de DNS não oferece API compatível com os plugins do Certbot, você ainda pode emitir o certificado Wildcard manualmente. No entanto, a renovação precisará ser feita a cada 90 dias com intervenção humana. Atenção: Esta abordagem é altamente desencorajada para produção, pois o esquecimento da renovação manual resultará na queda de todos os seus serviços HTTPS.

certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d exemplo.com.br \
  -d "*.exemplo.com.br" \
  --agree-tos \
  --email [email protected]

O Certbot exibirá o registro TXT que você deve criar manualmente no painel DNS:

Please deploy a DNS TXT record under the name:
_acme-challenge.exemplo.com.br
with the following value:
AbCdEfGhIjKlMnOpQrStUvWxYz1234567890abcd

Acesse o painel DNS do seu domínio, crie o registro TXT com o valor exibido, aguarde a propagação (geralmente 2 a 5 minutos) e pressione Enter para continuar a validação. Para gerenciar registros DNS no painel da AviraHost, consulte Como gerenciar um domínio.

Problemas comuns e como resolver

Sintoma: "DNS problem: NXDOMAIN looking up TXT for _acme-challenge"

Causa: O registro TXT ainda não propagou ou o plugin DNS demorou menos que o esperado para criar o registro. Isso ocorre frequentemente quando o TTL do domínio é alto (acima de 3600 segundos) ou quando o Cloudflare leva mais tempo para confirmar a escrita via API.
Solução: Aumente o parâmetro --dns-cloudflare-propagation-seconds para 90 ou 120 segundos e tente novamente. Verifique se o registro TXT está visível usando dig TXT _acme-challenge.exemplo.com.br @8.8.8.8 antes de reexecutar o Certbot.

Sintoma: "Permission denied" ao ler o arquivo de credenciais

Causa: O arquivo cloudflare.ini tem permissões incorretas ou pertence a um usuário diferente de root. O Certbot rejeita arquivos de credenciais com permissões mais permissivas que 600 por segurança.
Solução: Execute chmod 600 /etc/letsencrypt/secrets/cloudflare.ini && chown root:root /etc/letsencrypt/secrets/cloudflare.ini e tente novamente.

Sintoma: Certificado emitido mas subdomínio ainda retorna "NET::ERR_CERT_COMMON_NAME_INVALID"

Causa: O virtual host do subdomínio no Nginx ainda aponta para um certificado antigo ou não utiliza o caminho correto do Wildcard recém-emitido. O navegador valida o nome no certificado contra o hostname solicitado.
Solução: Confirme que as diretivas ssl_certificate e ssl_certificate_key no bloco do subdomínio apontam para /etc/letsencrypt/live/exemplo.com.br/fullchain.pem e não para um certificado de domínio específico anterior. Rode nginx -t && systemctl reload nginx após corrigir.

Sintoma: "Too many certificates (5) already issued for this exact set of domains"

Causa: O Let's Encrypt limita a 5 certificados por conjunto exato de domínios a cada 7 dias. Isso acontece quando se tenta reemitir repetidamente durante testes.
Solução: Use o flag --staging durante os testes para obter certificados de ambiente de homologação, que não contam para o limite de produção. Aguarde o reset semanal do limite antes de emitir em produção.

Sintoma: Renovação automática falha com "The renewal conf file ... is missing"

Causa: O arquivo de configuração de renovação em /etc/letsencrypt/renewal/exemplo.com.br.conf foi removido ou corrompido.
Solução: Reemita o certificado com os mesmos parâmetros. O Certbot recriará o arquivo de renovação automaticamente. Faça backup regular do diretório /etc/letsencrypt/ para evitar esse problema.

Perguntas frequentes sobre certificado SSL Wildcard

O que é um certificado SSL Wildcard e para que serve?

Um certificado SSL Wildcard é um certificado TLS que protege um domínio principal e todos os seus subdomínios de primeiro nível com um único arquivo de certificado. Por exemplo, um Wildcard para *.exemplo.com.br cobre app.exemplo.com.br, mail.exemplo.com.br e api.exemplo.com.br sem precisar emitir certificados individuais para cada um. Isso simplifica o gerenciamento em ambientes com muitos subdomínios e reduz o risco de um subdomínio ficar sem HTTPS por esquecimento.

O Let's Encrypt emite certificados Wildcard gratuitamente?

Sim, o Let's Encrypt emite certificados Wildcard gratuitos, mas exige obrigatoriamente a validação via DNS-01 challenge — não é possível usar o método HTTP-01 para Wildcards. Isso significa que você precisa ter acesso ao painel DNS do domínio para criar um registro TXT temporário durante a emissão. Para renovação totalmente automática, um plugin DNS com suporte à API do seu provedor é indispensável, conforme demonstrado neste guia.

Qual a diferença entre SSL Wildcard e SSL SAN (multi-domínio)?

O SSL Wildcard cobre todos os subdomínios de um único domínio (*.exemplo.com.br), enquanto o SSL SAN (Subject Alternative Name) lista domínios específicos e distintos no mesmo certificado, como exemplo.com.br, outrodominio.com.br e api.terceiro.com.br. Para múltiplos subdomínios do mesmo domínio, o Wildcard é mais prático e escalável; para domínios completamente diferentes pertencentes à mesma organização, o SAN é a escolha correta.

Como renovar automaticamente um certificado Wildcard do Let's Encrypt?

A renovação automática de Wildcards exige que o plugin DNS do Certbot esteja configurado com as credenciais da sua provedora de DNS. Com o plugin certbot-dns-cloudflare, por exemplo, o comando certbot renew é executado via systemd timer e renova o certificado sem intervenção manual, desde que o arquivo de credenciais da API esteja acessível e com permissões corretas. O hook post-renew garante que o Nginx recarregue o novo certificado após cada renovação.

Um certificado Wildcard cobre subdomínios de segundo nível como sub.app.exemplo.com.br?

Não. Um certificado Wildcard para *.exemplo.com.br cobre apenas subdomínios de primeiro nível, como app.exemplo.com.br. Para proteger sub.app.exemplo.com.br, seria necessário um segundo Wildcard para *.app.exemplo.com.br ou um certificado SAN que liste explicitamente esse subdomínio. Essa limitação é definida pelo padrão RFC 2818 e se aplica a todos os certificados Wildcard, independentemente da autoridade certificadora.

Conclusão

Configurar SSL Wildcard no AlmaLinux com o Let's Encrypt é uma solução robusta para proteger múltiplos subdomínios sem custo e com renovação automática. Para garantir segurança e continuidade, lembre-se dos pontos essenciais:

• Use sempre o plugin DNS compatível com seu provedor para garantir renovação automática dos Wildcards — a intervenção manual a cada 90 dias é inviável em produção e gera riscos desnecessários.
• Proteja o arquivo de credenciais de API com chmod 600 e ownership root:root para evitar exposição de tokens com permissões de escrita no DNS.
• Teste a renovação com --dry-run imediatamente após a configuração para confirmar que o fluxo completo — validação DNS, emissão e hook do Nginx — funciona corretamente antes do primeiro vencimento.

Leia também

• Como Instalar e Configurar o Let's Encrypt Wildcard SSL no VPS Linux
• Checklist de SSL: erros comuns ao renovar certificado no cPanel
• Checklist para configurar SSL Let's Encrypt no VPS Linux

Precisa de ajuda com SSL e infraestrutura Linux?

Um servidor VPS da AviraHost com AlmaLinux pré-instalado reduz o tempo de configuração inicial e oferece recursos dedicados para hospedar múltiplos subdomínios com desempenho consistente. A infraestrutura está disponível com acesso root completo, facilitando a implementação dos passos descritos neste guia.

Conheça os planos de VPS da AviraHost