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.

É necessário um certificado wildcard para um gateway Sophos ZTNA. O Sophos Central pode gerar este certificado e, depois, geri-lo e renová-lo. Em alternativa, pode ser criado com o Certbot, conforme descrito neste artigo, e carregado como certificado próprio. 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.

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
• para o Sophos Central, permissão para criar e alterar no DNS o registo CNAME necessário
• para o método manual com o Certbot, permissão para criar e alterar os registos DNS TXT do domínio
• para o método manual, um servidor Linux ou estação de administração com o Certbot
• para o método manual, permissão para executar o Certbot com privilégios root
• um plano de renovação, importação e armazenamento da chave adequado ao método escolhido
• acesso ao sistema de destino, como o Sophos ZTNA no Sophos Fusion, um reverse proxy ou uma firewall

Os certificados wildcard são validados através do desafio DNS-01. No método manual com o Certbot, é definido um registo TXT em _acme-challenge.example.com. No método gerido pelo Sophos Central, um registo CNAME delega esta verificação à Sophos. A documentação da Let’s Encrypt sobre tipos de desafios descreve os tipos de desafio básicos.

Para Sophos ZTNA: criar o certificado no Sophos Central

Para um gateway ZTNA, o método gerido no Sophos Central é normalmente mais simples do que um processo manual com o Certbot: a Sophos gera o certificado Let’s Encrypt e passa também a tratar da sua gestão e renovação. É necessário conhecer o domínio utilizado pelo gateway e ter acesso ao respetivo fornecedor DNS.

Se a zona DNS utilizar registos CAA, a Let’s Encrypt tem de estar autorizada como entidade de certificação. Caso contrário, a Let’s Encrypt não pode emitir um certificado, mesmo que a validação do domínio seja bem-sucedida.

1. No Sophos Central, abrir Os meus produtos > ZTNA e clicar em Definições.
2. Abrir Domínios e certificados e clicar em Adicionar domínio. A Sophos permite um máximo de 100 domínios. Introduzir o domínio no formato example.com e adicioná-lo.
3. A Sophos gera um valor CNAME para este domínio. Criá-lo no fornecedor DNS em _acme-challenge.example.com. Substituir example.com pelo domínio do próprio gateway.
4. Voltar a Domínios e certificados, clicar em Validar e confirmar que o registo CNAME foi criado. A Sophos verifica assim o controlo sobre o domínio.
5. Após uma validação bem-sucedida, clicar em Gerar certificado LE, ler e aceitar o Contrato de Subscritor da Let’s Encrypt e iniciar a geração. Segundo a Sophos, demora cerca de 60 segundos; é possível sair da página durante o processo.

⚠️ Se já existir um registo TXT em _acme-challenge.example.com, este tem de ser removido para utilizar o registo CNAME exigido pela Sophos. Primeiro, verificar se outra aplicação precisa desse registo TXT. O registo CNAME tem de permanecer depois no DNS.

Para domínios que já existem no Sophos Central, o procedimento depende do estado de validação:

• Já validado através de um registo DNS TXT:
  1. Em Os meus produtos > ZTNA > Definições > Domínios e certificados, clicar em Gerar certificado LE.
  2. Em Adicionar CNAME, copiar o registo CNAME e criá-lo no fornecedor DNS em _acme-challenge.example.com.
  3. Remover um registo TXT existente nesse local apenas depois da verificação de impacto descrita acima.
  4. Confirmar a criação do registo CNAME.
  5. Aceitar o Contrato de Subscritor da Let’s Encrypt e clicar em Continuar.
  6. Concluir a geração do certificado e verificar em Domínios e certificados se o domínio e o respetivo registo CNAME são apresentados no novo formato.
• Ainda não validado: Remover o domínio existente, voltar a adicioná-lo através de Adicionar domínio, validá-lo com Validar e, depois, voltar a gerar o certificado Let’s Encrypt com Gerar certificado LE.

A Sophos gera apenas um certificado Let’s Encrypt por conta Central. Este contém todos os domínios validados. Se outro domínio for validado mais tarde, é necessário gerar novamente o certificado para o incluir.

Para associar o certificado a um gateway existente, abrir Os meus produtos > ZTNA > Gateways, selecionar o gateway e definir a opção Automático (Let’s Encrypt) em Domínio e certificado. Guardar a alteração e, depois, verificar no gateway a validade e a data de expiração do certificado. Se a validação ou a geração ainda não tiver sido concluída com sucesso, não mudar o gateway para o novo certificado; verificar primeiro o registo CNAME junto do fornecedor DNS autoritativo.

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?

Para o Sophos ZTNA, o certificado criado com o Certbot é atribuído ao gateway no Sophos Central: abrir Os meus produtos > ZTNA > Gateways, clicar no nome do gateway e selecionar Carregar certificado próprio em Domínio e certificado. Carregar o certificado gerado e clicar em Guardar. Em seguida, verificar no gateway a validade e a data de expiração; um certificado prestes a expirar tem de ser renovado, carregado novamente e verificado outra vez no gateway.

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 certificados wildcard geridos externamente, o método 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.
• Para o Sophos Central: acesso DNS e permissão para o registo CNAME necessário disponíveis.
• Para o método manual com o Certbot: acesso DNS e permissão para registos TXT disponíveis.
• Método de emissão através do Sophos Central ou de um cliente ACME externo escolhido conscientemente.
• Certbot corretamente instalado para o método manual.
• Validação do domínio através do CNAME da Sophos ou do desafio DNS-01 manual verificada com sucesso.
• Para o método externo, ficheiros do certificado e chave privada armazenados em segurança.
• Para o método externo, sistema de destino e formato de importação necessário conhecidos.
• Renovação planeada através do Sophos Central ou com um responsável, calendário ou automatização DNS.
• Para o método externo, 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