Criar certificado curinga Let's Encrypt

Um Certificado Let’s Encrypt Wildcard é útil se vários subdomínios precisarem ser protegidos com um certificado comum, por exemplo app.example.com, vpn.example.com e portal.example.com. Isso pode ser útil para Sophos ZTNA, proxies reversos, ambientes de teste ou vários serviços web internos.

O importante é a expectativa: os certificados Let’s Encrypt têm vida curta. A vantagem não está no longo prazo, mas na emissão gratuita e na automação. Se o certificado for criado manualmente usando uma entrada DNS TXT, a renovação subsequente deverá ser planejada conscientemente.

Se o certificado for criado diretamente em um Sophos Firewall para WAF, WebAdmin ou portais, o método de firewall integrado geralmente é melhor: Configure o Sophos Firewall Vamos criptografar certificados. Este artigo descreve a rota curinga externa com Certbot.

Quando um certificado curinga faz sentido

Um certificado curinga cobre um nível abaixo de um domínio. Portanto, *.example.com se ajusta a portal.example.com, mas não automaticamente para example.com em si e também não para a.b.example.com.

• Muitos subdomínios na mesma zona: Certificado curinga pode simplificar a administração.
• Apenas um único serviço público: único certificado FQDN costuma ser mais limpo.
• O certificado deve ser usado em vários sistemas: O certificado curinga pode ser prático, mas controla estritamente a distribuição de chaves.
• É necessária renovação totalmente automática: Agende provedor de DNS com plugin Certbot ou outro cliente ACME.
• O Sophos Firewall destina-se apenas a proteger WAF/WebAdmin/Portais: Firewall integrado Vamos criptografar verificação.

Um certificado curinga não é um ganho de segurança por si só. Na verdade, se a mesma chave privada estiver em vários sistemas, o impacto da perda de uma chave aumenta. Portanto, deve ser documentado onde o certificado foi importado e quem gerencia a chave privada.

Requisitos

Para um certificado curinga, você precisa de:

• seu próprio domínio ou zona de subdomínio
• Acesso aos registros DNS TXT do domínio
• um servidor Linux ou computador administrativo com Certbot
• Permissão para executar Certbot com privilégios de root
• um plano de renovação, importação e armazenamento de chaves
• Acesso ao sistema de destino, por exemplo Sophos Central ZTNA, proxy reverso ou firewall

Os certificados curinga são validados por meio do Desafio DNS-01. Um registro TXT é definido em _acme-challenge.example.com. Let’s Encrypt verifica esta entrada DNS e então emite o certificado. Let’s Encrypt descreve os tipos básicos de desafios na Documentação de tipos de desafio.

Instale o Certbot

A Página do projeto Certbot recomenda a instalação via Snap para diversos ambientes Linux. Em um sistema Linux adequado, o processo básico é assim:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Se o Certbot já foi instalado via apt, dnf ou outro pacote, você deve verificar previamente qual Certbot está realmente sendo usado. Caso contrário, vários caminhos de instalação paralelos levarão rapidamente a versões incorretas ou trabalhos de renovação inesperados.

Crie certificado curinga manualmente

Para validação manual de DNS, o Certbot pode ser iniciado com --manual e --preferred-challenges dns. No exemplo, o certificado deve ser aplicado a example.com e *.example.com:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

O Certbot apresenta então um ou mais valores TXT. Se example.com e *.example.com forem pedidos ao mesmo tempo, o Certbot cria dois desafios DNS-01 separados. Ambos os valores TXT devem ser adicionados como registos TXT separados em _acme-challenge.example.com. Por isso, adicione o segundo registo além do primeiro e não o substitua.

Só quando todos os registos DNS estiverem visíveis globalmente se deve confirmar no Certbot e continuar a validação.

Verificação prática:

dig TXT _acme-challenge.example.com @1.1.1.1

• certonly: Solicite ou renove um certificado sem instalá-lo.
• --manual: O valor DNS é definido manualmente.
• --preferred-challenges dns: Use o Desafio DNS-01.
• -d example.com: Adicionar domínio raiz adicional.
• -d '*.example.com': Incluir domínio curinga.

O domínio raiz e o domínio wildcard são nomes separados. Se apenas *.example.com for solicitado, o próprio example.com não será incluído automaticamente. Se ambos os nomes forem pedidos ao mesmo tempo, podem ser necessários vários registos TXT com o mesmo nome. Isto é permitido em DNS e é precisamente aqui que as validações falham muitas vezes, porque um valor TXT existente é substituído por engano.

Encontre arquivos de certificado

Após a emissão bem-sucedida, os arquivos normalmente ficam localizados em:

/etc/letsencrypt/live/example.com/

Arquivos importantes:

• fullchain.pem: Certificado incluindo certificados intermédios.
• cert.pem: apenas o certificado do servidor.
• privkey.pem: chave privada.
• chain.pem: Certificados intermediários.

Muitos sistemas alvo requerem fullchain.pem e privkey.pem. Algumas máscaras de importação exigem o certificado e a chave separadamente, outras também exigem a corrente. Antes de importar, deve ficar claro qual formato o sistema de destino espera.

⚠️ privkey.pem é a chave privada. Este arquivo não deve acabar em tickets, chats, e-mails ou armazenamento inseguro. Qualquer pessoa que possua a chave privada pode fazer uso indevido do certificado.

Renovação do plano

O método manual --manual é fácil para testes e ações individuais, mas é apenas parcialmente adequado para certificados produtivos. Sem automação, um novo registro DNS TXT deve ser definido sempre que for renovado.

Existem três variantes limpas para uso produtivo:

• Plug-in DNS para o provedor DNS: se o Certbot tiver permissão para definir registros DNS via API.
• mais um cliente ACME com automação DNS: se o provedor ou plataforma é melhor suportado.
• renovação manual com calendário e proprietário: apenas para testes ou certificados raramente utilizados.

Quando o acesso à API DNS é usado, as credenciais da API são particularmente críticas. Um token DNS só deve ter permissão para alterar a zona necessária e, se possível, apenas os tipos de registro necessários. O amplo acesso de administrador de domínio não pertence desprotegido a um servidor web.

Um teste de renovação geralmente é verificado com Certbot assim:

sudo certbot renew --dry-run

Para certificados DNS criados manualmente, esse teste só será significativo se o processo DNS também for automatizado ou se os ganchos manuais funcionarem corretamente.

Importe para ambientes Sophos

Se o certificado for usado para Sophos ZTNA, um firewall, um proxy reverso ou outro sistema relacionado ao Sophos, você deverá verificar estes pontos antes de importar:

• O nome do certificado corresponde ao nome do host público?
• O domínio raiz é necessário além do curinga?
• O sistema de destino espera fullchain.pem ou componentes de certificado separados?
• A chave privada é aceita ou precisa ser convertida para outro formato?
• Existe um processo documentado para a próxima renovação?
• Está claro em quais sistemas o mesmo certificado foi importado?

Quando se trata apenas de WAF, WebAdmin ou portais no Sophos Firewall, o processo de firewall integrado costuma ser mais simples porque a criação e a renovação ocorrem diretamente no firewall. No entanto, a rota externa Certbot ou ACME permanece relevante para certificados curinga reais.

Erros típicos

• A validação falha: Registo TXT ainda não visível, nome de zona DNS incorreto ou um dos vários valores TXT foi substituído. dig TXT _acme-challenge.example.com @1.1.1.1 verificar.
• O certificado não se aplica a example.com: apenas *.example.com solicitado. Adicione o domínio raiz adicionalmente com -d example.com.
• O certificado não se aplica a a.b.example.com: O curinga cobre apenas um nível de subdomínio. planeje seu próprio certificado ou curinga adequado para uma zona mais profunda.
• A renovação não funciona automaticamente: maneira DNS manual sem automação. Verifique o plugin DNS ou outro cliente ACME.
• A importação falha: arquivo ou formato errado. fullchain.pem, cert.pem, privkey.pem e compare solicitação de cadeia.
• Risco de segurança devido a cópias de chaves: chave privada está em vários sistemas. Locais de armazenamento, acesso e importação de documentos.

Lista de verificação

• Conjunto de níveis de domínio e subdomínio.
• Domínio raiz e curinga selecionados deliberadamente.
• Acesso DNS e permissão de registro TXT disponíveis.
• Certbot instalado de forma limpa.
• Desafio DNS-01 verificado com sucesso.
• Arquivos de certificado e chave privada armazenados com segurança.
• Sistema de destino e formato de importação necessário conhecidos.
• Renovação agendada com Proprietário, Calendário ou automação de DNS.
• Certificados e chaves antigos são removidos de maneira controlada após a conversão bem-sucedida.

Perguntas frequentes