Criar um certificado wildcard Let's Encrypt

Um certificado wildcard Let’s Encrypt é útil quando vários subdomínios devem ser protegidos com um único certificado, por exemplo app.example.com, vpn.example.com e portal.example.com. Pode ser uma solução prática para Sophos ZTNA, reverse proxies, ambientes de teste ou vários serviços web internos.

É importante partir da expectativa correta: os certificados Let’s Encrypt têm uma validade curta. A vantagem não está numa longa duração, mas na emissão gratuita e na automatização. Se o certificado for criado manualmente através de um registo DNS TXT, a renovação posterior deve ser planeada de forma consciente.

Se o certificado for criado diretamente na Sophos Firewall para WAF, WebAdmin ou portais, o método integrado na firewall é normalmente mais adequado: Configurar certificados Let’s Encrypt na Sophos Firewall. Este artigo descreve o método wildcard externo com Certbot.

Quando um certificado wildcard é adequado

Um certificado wildcard abrange um nível abaixo de um domínio. Assim, *.example.com abrange portal.example.com, mas não abrange automaticamente example.com nem a.b.example.com.

• Muitos subdomínios na mesma zona: Um certificado wildcard pode simplificar a administração.
• Apenas um serviço público: Um certificado para um FQDN específico costuma ser mais claro.
• O certificado será utilizado em vários sistemas: Um certificado wildcard pode ser prático, mas a distribuição da chave privada deve ser rigorosamente controlada.
• É necessária uma renovação totalmente automática: Deve ser previsto um fornecedor DNS com plugin para Certbot ou outro cliente ACME.
• A Sophos Firewall só precisa de proteger WAF, WebAdmin ou portais: Convém verificar o método Let’s Encrypt integrado na firewall.

Um certificado wildcard não é, por si só, mais seguro. Se a mesma chave privada estiver armazenada em vários sistemas, aumenta o impacto de um possível comprometimento. Por isso, deve ficar documentado em que sistemas o certificado foi importado e quem é responsável pela chave privada.

Requisitos

Para obter um certificado wildcard são necessários:

• um domínio próprio ou uma zona de subdomínio delegada
• acesso aos registos DNS TXT do domínio
• um servidor Linux ou estação de administração com Certbot
• permissão para executar o Certbot com privilégios root
• um plano para renovação, importação e armazenamento da chave
• acesso ao sistema de destino, como Sophos Central ZTNA, um reverse proxy ou uma firewall

Os certificados wildcard são validados através do desafio DNS-01. Para isso, é criado um registo TXT em _acme-challenge.example.com. A Let’s Encrypt verifica este registo DNS e emite depois o certificado. A documentação da Let’s Encrypt sobre tipos de desafios explica os métodos de validação básicos.

Instalar o Certbot

A página do projeto Certbot recomenda a instalação através do Snap em muitos ambientes Linux. Num sistema Linux adequado, o procedimento básico é:

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

Se o Certbot já tiver sido instalado através de apt, dnf ou outro gestor de pacotes, é necessário verificar primeiro qual executável está realmente a ser utilizado. Métodos de instalação paralelos podem levar à utilização de uma versão inesperada ou a tarefas de renovação diferentes das previstas.

Criar manualmente o certificado wildcard

Para uma validação DNS manual, o Certbot é executado com --manual e --preferred-challenges dns. Neste exemplo, o certificado deve abranger example.com e *.example.com:

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

O Certbot apresenta depois um ou vários valores TXT. Quando example.com e *.example.com são pedidos em conjunto, são criados dois desafios DNS-01 distintos. Ambos os valores devem ser adicionados como registos TXT separados em _acme-challenge.example.com. O segundo registo deve ser adicionado sem substituir o primeiro.

Antes de continuar no Certbot, pelo menos os servidores de nomes autoritativos do domínio e um resolver externo devem devolver os valores TXT esperados. Um único resolver fornece apenas um indício, porque os fornecedores DNS podem propagar alterações a velocidades diferentes consoante a localização.

Verificação prática:

dig TXT _acme-challenge.example.com @1.1.1.1

Os servidores de nomes autoritativos podem ser identificados com dig NS example.com. Depois, o mesmo registo TXT pode ser consultado diretamente num desses servidores. Após uma validação bem-sucedida, devem ser removidos os valores TXT do desafio que já não sejam necessários. Valores antigos dificultam verificações posteriores e, quando se acumulam, aumentam desnecessariamente a resposta DNS.

• certonly: Obter ou renovar um certificado sem o instalar.
• --manual: Definir manualmente o valor DNS.
• --preferred-challenges dns: Utilizar o desafio DNS-01.
• -d example.com: Incluir o domínio raiz.
• -d '*.example.com': Incluir o domínio wildcard.

O domínio raiz e o domínio wildcard são nomes distintos. Se apenas *.example.com for pedido, example.com não é incluído automaticamente. Quando ambos os nomes são pedidos em conjunto, podem ser necessários vários registos TXT com o mesmo nome. O DNS permite isso, e a validação falha frequentemente porque um valor TXT existente é substituído por engano.

Localizar os ficheiros do certificado

O Certbot apresenta o nome real do certificado, os domínios incluídos, a data de validade e os caminhos dos ficheiros com este comando só de leitura:

sudo certbot certificates

Após uma emissão bem-sucedida, os ficheiros encontram-se normalmente em:

/etc/letsencrypt/live/example.com/

Ficheiros importantes:

• fullchain.pem: Certificado com os certificados intermédios.
• cert.pem: Apenas o certificado do servidor.
• privkey.pem: Chave privada.
• chain.pem: Certificados intermédios.

Muitos sistemas de destino necessitam de fullchain.pem e privkey.pem. Alguns formulários de importação esperam o certificado e a chave em separado, enquanto outros também exigem a cadeia. Antes da importação, deve ser confirmado o formato esperado pelo sistema de destino.

⚠️ privkey.pem é a chave privada. Este ficheiro não deve ser colocado em tickets, chats, e-mails ou armazenamento desprotegido. Quem obtiver a chave privada pode utilizar indevidamente o certificado.

Planear a renovação

O método manual com --manual é simples para testes e operações pontuais, mas é apenas parcialmente adequado para certificados de produção. Sem automatização, é necessário definir um novo valor DNS TXT em cada renovação.

Existem três opções adequadas para produção:

• Plugin DNS para o fornecedor: Adequado quando o Certbot pode atualizar registos DNS através de uma API.
• Outro cliente ACME com automatização DNS: Adequado quando o fornecedor ou a plataforma tem melhor suporte noutro cliente.
• Renovação manual com um responsável e lembrete no calendário: Indicada apenas para testes ou certificados raramente utilizados.

As credenciais da API DNS são particularmente sensíveis. Um token DNS deve ser limitado à zona necessária e, sempre que possível, aos tipos de registo exigidos. Credenciais com direitos amplos de administração do domínio não devem ser armazenadas sem proteção num servidor web.

A renovação é normalmente testada com:

sudo certbot renew --dry-run

Nos certificados criados através de validação DNS manual, este teste só é significativo se o processo DNS estiver automatizado ou se os hooks manuais funcionarem corretamente.

Uma renovação bem-sucedida no sistema Certbot não atualiza automaticamente um certificado já importado na Sophos Firewall, no ZTNA ou num reverse proxy. É necessária uma reimportação documentada ou um processo de implementação testado que seja executado apenas após uma renovação bem-sucedida. Depois de cada implementação, devem ser verificados os nomes, a cadeia e a nova data de validade diretamente no sistema de destino.

Importar em ambientes Sophos

Antes de importar o certificado para Sophos ZTNA, uma firewall, um reverse proxy ou outro sistema relacionado com Sophos, é necessário verificar:

• O nome do certificado corresponde ao hostname público?
• É necessário o domínio raiz para além do wildcard?
• O sistema de destino espera fullchain.pem ou componentes separados?
• Aceita a chave privada ou esta tem de ser convertida para outro formato?
• Existe um procedimento documentado para a próxima renovação?
• Está claro em que sistemas o mesmo certificado foi importado?

Se o certificado for necessário apenas para WAF, WebAdmin ou portais na Sophos Firewall, o processo integrado é frequentemente mais simples, porque a emissão e a renovação são feitas diretamente na firewall. Para verdadeiros certificados wildcard, o método externo com Certbot ou ACME continua a ser relevante. Importar e atribuir certificados na Sophos Firewall explica depois como verificar a chave privada, a cadeia de CA e a atribuição ao serviço.

Erros típicos

• A validação falha: O registo TXT ainda não está visível, o nome da zona DNS está incorreto ou um de vários valores TXT foi substituído. Verificar com dig TXT _acme-challenge.example.com @1.1.1.1.
• O certificado não abrange example.com: Foi pedido apenas *.example.com. Adicionar o domínio raiz com -d example.com.
• O certificado não abrange a.b.example.com: O wildcard só abrange um nível de subdomínio. Planear um certificado separado ou um wildcard adequado para a zona mais profunda.
• A renovação não é executada automaticamente: O método DNS manual não está automatizado. Verificar um plugin DNS adequado ou outro cliente ACME.
• O Certbot renova o certificado, mas o sistema de destino continua a apresentar o antigo: A reimportação ou o processo de implementação não foi executado. Verificar o número de série ou a data de validade diretamente no destino.
• A importação falha: O ficheiro ou o formato está incorreto. Comparar os requisitos de fullchain.pem, cert.pem, privkey.pem e da cadeia de certificados.
• As cópias da chave criam um risco de segurança: A chave privada está armazenada em vários sistemas. Documentar as localizações, as permissões de acesso e os pontos de importação.

Lista de verificação

• Domínio e nível de subdomínio necessário definidos.
• Domínio raiz e wildcard selecionados conscientemente.
• Acesso DNS e permissão para criar registos TXT disponíveis.
• Certbot instalado de forma consistente.
• Desafio DNS-01 validado com sucesso.
• Ficheiros do certificado e chave privada armazenados em segurança.
• Sistema de destino e formato de importação necessário conhecidos.
• Renovação planeada com um responsável, lembrete ou automatização DNS.
• Reimportação ou processo de implementação no sistema de destino testado.
• Certificados e chaves antigos removidos de forma controlada após uma migração bem-sucedida.

Perguntas frequentes