Configurar certificados Let's Encrypt na Sophos Firewall

Com certificados Let’s Encrypt na Sophos Firewall, podem ser criados certificados HTTPS públicos diretamente na firewall e renovados automaticamente. Isto é particularmente útil para publicações WAF, WebAdmin, User Portal, VPN Portal, Captive Portal, SPX Portal, páginas de login de hotspot e configurações SMTP TLS.

A função reduz o trabalho manual com certificados, mas não substitui o planeamento adequado. DNS, acessibilidade pública, porta 80, nomes de certificados, regras WAF, acesso ao portal e monitorização devem estar alinhados. Se a validação ou a renovação falhar sem ser notada, um portal ou uma aplicação web publicada pode passar a apresentar avisos de certificado, mesmo que a regra WAF esteja correta.

Para a publicação propriamente dita de um servidor web, o ponto de partida é Sophos Firewall WAF: publicar servidores web com segurança. Este artigo concentra-se no lado do certificado e na operação do Let’s Encrypt na firewall.

Quando Let’s Encrypt faz sentido na firewall

O método Let’s Encrypt integrado faz sentido se o próprio Sophos Firewall fornecer o serviço público ou estiver na frente dele como um proxy reverso.

WAF / Web Server Protection: aplicações HTTPS publicamente acessíveis com FQDN próprio.
WebAdmin: acesso administrativo com certificado limpo se o WebAdmin for usado externamente ou internamente via FQDN.
User Portal / VPN Portal: utilizadores autenticam-se num portal HTTPS ou descarregam configurações; isto não é o mesmo que o certificado do túnel VPN em si.
Captive Portal / Hotspot: utilizadores veem uma página de login HTTPS sem aviso de certificado.
TLS SMTP: Configuração Mail Protection ou SMTP TLS com certificado público.

Nem todos os serviços se enquadram neste caminho. Para certificados wildcard ou certificados que serão usados em vários sistemas fora da firewall, um certificado gerado externamente é frequentemente melhor. Para isso existe o artigo Criar certificado wildcard Let’s Encrypt.

Limites e diferenças importantes

O Sophos Firewall cria certificados Let’s Encrypt para FQDNs específicos. A integração não é a mesma que um cliente ACME gerenciado gratuitamente em um servidor Linux.

Pontos importantes:

O domínio deve ser especificado como um FQDN completo.
Domínios curinga não são o caminho certo para o processo de firewall integrado.
Os endereços IP não são nomes de certificados válidos.
A validação do domínio HTTP deve ser capaz de alcançar o firewall através da porta 80.
O firewall cria um servidor web temporário ou componentes WAF para validação.
Após a emissão bem-sucedida, os componentes de validação temporários são removidos novamente.
Os certificados têm vida curta e devem ser renovados automaticamente.

A Sophos introduziu o recurso com o SFOS 21. A classificação da Avanet das inovações da época pode ser encontrada na postagem do blog Sophos Firewall v21: as inovações mais importantes. Várias correções do WAF e do Let’s Encrypt estão listadas nas notas de versão recentes. Para ambientes produtivos, isso significa: o status do firmware, o status do certificado e a operação do WAF devem ser verificados em conjunto, e não isoladamente.

Requisitos

Antes de criar um certificado, estes pontos devem ser esclarecidos:

O firewall funciona em uma versão SFOS com suporte Let’s Encrypt.
O nome DNS público aponta para o endereço WAN ou endereço hospedado do firewall.
A porta 80 pode ser acessada externamente para validação HTTP.
Não há DNAT ativo, WAF ou outra regra interceptando a solicitação de validação na porta 80.
O firewall pode se comunicar pela própria Internet.
A data, hora e NTP do firewall estão corretos.
Para atendimento posterior fica claro se o certificado é utilizado em WAF, WebAdmin, Portal ou SMTP TLS.
O proprietário verifica regularmente a expiração do certificado, o status da renovação e os serviços afetados.

⚠️ Let’s Encrypt não é uma solução alternativa para acessibilidade pública impura. Se a porta 80 for bloqueada por uma regra DNAT antiga, outra regra WAF, um NAT upstream ou um filtro de provedor, a solicitação ou renovação do certificado poderá falhar.

Planear nomes de certificados

Antes da configuração técnica, deve ficar claro que hostnames são realmente necessários. Um bom planeamento de certificados evita correções posteriores em regras WAF, portais e DNS.

Exemplos:

portal.example.com: User Portal ou VPN Portal.
vpn.example.com: Portal VPN ou caminho de download do SSL VPN.
admin.example.com: WebAdmin, se usado externamente ou via gerenciamento FQDN.
app.example.com: aplicação publicada via WAF.
mail.example.com: SMTP TLS ou proteção de correio.

Com várias aplicações, não se deve colocar tudo precipitadamente num único certificado. Um certificado com muitos nomes pode ser prático, mas também aumenta as dependências. Quando um certificado é renovado, substituído ou revertido, todos os hostnames nele incluídos são afetados.

Para regras WAF, também é importante que o DNS, o certificado, os domínios na regra WAF e o SNI correspondam. Os princípios básicos do WAF são descritos em Sophos Firewall WAF: servidores públicos web com segurança.

Criar conta e certificado Let’s Encrypt

A configuração é feita no WebAdmin na área Certificados. Dependendo da versão do SFOS, a representação exata pode variar um pouco, mas o processo permanece semelhante.

Registar conta

Primeiro, a firewall é registada no Let’s Encrypt.

Processo básico:

Abra Certificados.
Abra a área Let’s Encrypt ou solicitação de certificado.
Prepare a conta Let’s Encrypt no firewall.
Insira os FQDNs desejados.
Selecione interface WAN ou endereço público para validação HTTP.
Verifique se a porta 80 aponta para o firewall de fora.
Solicite certificado.

Pedir certificado

Depois é criado o certificado propriamente dito.

Abrir Certificates > Certificates.
Clicar em Add.
Em Action, selecionar Request Let’s Encrypt certificate.
Atribuir um nome claro, por exemplo le-app-example-com.
Em Domains, inserir os FQDNs pretendidos, por exemplo app.example.com.
Em Hosted address, selecionar o endereço WAN público para o qual estes domínios apontam.
Verificar se a porta 80 aponta realmente para a firewall a partir do exterior.
Clicar em Save.
Após alguns minutos, verificar em Certificates > Certificates se o certificado aparece como confiável e tem uma data Valid until válida.

Durante a validação, o firewall usa o mecanismo HTTP de resposta a desafios. Para fazer isso, os sistemas Let’s Encrypt externos devem ser capazes de alcançar o caminho de validação. Se o firewall estiver atrás de um roteador, balanceador de carga ou provedor NAT, o redirecionamento deverá apontar para o firewall.

Usar certificado

Uma vez emitido, o certificado só existe. Ele só protege um serviço depois de ele ter sido selecionado ativamente.

Atribuição típica:

WAF: regra WAF afetada em Regras e políticas > Regras de firewall.
WebAdmin: Certificado para o console WebAdmin nas configurações relacionadas ao acesso ao administrador/dispositivo.
Portal do Usuário / Portal VPN: Configuração do portal ou portal VPN.
Portal cativo/ponto de acesso: Página de login e certificado do portal.
TLS SMTP: Configuração de e-mail ou SMTP TLS.

Após a atribuição, você não deve apenas salvar no WebAdmin, mas também testar o serviço externamente. Para publicações WAF, um teste fora da sua própria LAN é adequado porque a visualização interna do DNS, o loopback NAT ou o cache do navegador podem fornecer falsa segurança.

Teste de entrada em operação

Um teste de entrada em operação bem-sucedido consiste em DNS, TLS, funcionalidade de serviço e registro.

Lista de verificação:

O FQDN resolve publicamente para o endereço esperado.
A porta 80 está acessível ao firewall durante a validação.
A porta 443 ou a porta HTTPS utilizada entrega o novo certificado.
O navegador não mostra aviso de certificado.
O certificado contém o nome do host esperado.
A data de validade corresponde ao certificado recém-criado.
A regra WAF, portal ou WebAdmin realmente usa este certificado.
O Log Viewer não mostra nenhum erro perceptível de WAF, portal ou certificado.
Para versões WAF, reverseproxy.log corresponde ao horário do teste.

Um simples teste TLS externo também pode mostrar qual certificado é realmente entregue. É importante realizar o teste fora da rede do cliente e não apenas do cliente interno.

Verifique a cadeia de certificados

Depois de mudar para um novo certificado Let’s Encrypt, não apenas o nome comum ou a entrada SAN devem ser verificados. Também é crucial que o cliente veja toda a cadeia de certificados. Se um navegador, aplicativo ou sistema de monitoramento relatar uma cadeia incompleta, a causa pode ser a seleção do certificado, um certificado importado antigo, uma regra WAF incorreta ou um proxy reverso intermediário.

Na prática, devem ser verificados estes pontos:

O teste HTTPS externo mostra o FQDN esperado sem aviso de certificado.
O certificado entregue é realmente o novo certificado Let’s Encrypt do Sophos Firewall.
A cadeia de certificados está completa e não é substituída por um back-end antigo ou certificado proxy.
Regra WAF, portal ou WebAdmin utilizam o mesmo certificado que está visível no teste externo.
Se um balanceador de carga, roteador ou proxy reverso upstream estiver envolvido, nenhum outro certificado será entregue lá.

Essa verificação é particularmente importante se o mesmo domínio passou anteriormente por uma publicação diferente ou se várias regras WAF, regras DNAT ou proxies externos usarem o mesmo nome de host. Caso contrário, você verá um certificado válido no WebAdmin, enquanto os clientes externos ainda receberão uma cadeia diferente ou incompleta.

Monitorizar a renovação em operação

Os certificados Let’s Encrypt têm validade curta. O ponto forte da integração é que a firewall pode realizar a renovação automaticamente. Ainda assim, o processo não deve correr às cegas.

Estes pontos devem ser verificados regularmente em uma auditoria da empresa:

O firewall está sendo executado em uma versão SFOS atual e estável?
O certificado ainda é válido?
A renovação automática foi bem-sucedida?
A porta 80 ainda está acessível para validação?
Existem novas regras DNAT ou WAF que possam bloquear a validação?
Os usuários ou o monitoramento mostram avisos de certificado?
Existem erros de WAF ou de portal no visualizador de log?

Essa verificação é particularmente importante após atualizações de firewall, alterações de WAF, alterações de provedor, alterações de DNS e alterações em roteadores upstream ou proxies reversos.

Erros típicos

O certificado não foi criado: FQDN não aponta para o firewall ou a porta 80 não está acessível. Verifique a resolução de DNS público e teste de porta externa.
A solicitação de certificado falha após alteração do WAF: regra existente intercepta validação HTTP. Verifique as regras de DNAT, WAF e Firewall na porta 80.
O certificado é criado, mas o navegador mostra o certificado antigo: Serviço usa outro certificado. Verifique a regra WAF, portal ou seleção de certificado WebAdmin.
Relatórios de navegador ou monitoramento cadeia de certificados incompleta: Certificado errado ativo, a cadeia não é entregue completamente ou o proxy upstream entrega um certificado diferente. Compare teste TLS externo, regra WAF, mapeamento de portal e possíveis proxies.
Aplicativo WAF não funciona corretamente após alteração de certificado: SNI, domínio, host de back-end ou perfil de proteção não correspondem. Verifique regras WAF, domínios, reverseproxy.log e logs de back-end.
Renewal doesn’t work: O caminho de validação mudou desde a criação. Verifique DNS, porta 80, NAT upstream e status de firmware.
Control Center mostra WAF ou aviso de certificado: regra WAF antiga, reinicialização do WAF ou status do certificado problemático. Verifique o visualizador de log, regras WAF e lista de certificados.

Se o WAF e o certificado estiverem juntos, você não deve apenas olhar para o certificado. Correspondência de WAF, endereço hospedado, domínios, SNI e acessibilidade de back-end pertencem à mesma cadeia de erros.

Planear rollback

Para portais públicos e aplicações WAF, deve ficar claro como voltar antes de alterar um certificado.

Preparação útil:

não eliminar imediatamente o certificado anterior
documentar a regra WAF afetada e a configuração do portal
manter acesso externo de teste disponível
conhecer o DNS TTL, caso hostnames sejam alterados
escolher uma janela de manutenção para portais críticos
preparar a comunicação aos utilizadores, se um portal for afetado

Se o novo certificado tiver sido criado, mas um serviço funcionar incorretamente, normalmente você poderá selecionar o certificado anterior novamente. No entanto, se a causa for uma validação HTTP bloqueada, uma reversão do certificado só ajudará no curto prazo. Em seguida, o caminho de validação deve ser corrigido, caso contrário a próxima renovação falhará novamente.

Lista de verificação

FQDNs e serviços documentados.
Resolução de DNS público verificada.
Porta 80 verificada para validação HTTP.
Conflitos com DNAT, WAF, GeoIP, SD-WAN ou NAT upstream verificados.
Conta Let’s Encrypt registada e condições alteradas confirmadas.
Certificado Let’s Encrypt criado.
Certificado atribuído ao serviço correto.
Teste HTTPS externo realizado.
Log Viewer e WAF reverseproxy.log verificados.
Responsabilidade e monitoramento de renovação definidos.
Certificado antigo removido somente após operação bem-sucedida.

Perguntas frequentes

O Sophos Firewall Let's Encrypt pode renovar certificados automaticamente?

Sim. O firewall pode renovar automaticamente os certificados Let’s Encrypt. No entanto, você deve verificar regularmente a data de validade, o status da renovação, a acessibilidade da porta 80 e os serviços afetados.

Quando é que a Sophos Firewall renova um certificado Let's Encrypt?

Os certificados Let’s Encrypt são válidos por 90 dias. A Sophos Firewall pede a renovação quando o certificado tem menos de 30 dias restantes. Para isso, o caminho de validação pela porta 80 tem de continuar funcional.

A Sophos Firewall suporta certificados wildcard Let's Encrypt?

Para certificados wildcard, o processo integrado da firewall não é o caminho certo. Se for necessário um certificado wildcard, este deve ser criado externamente e depois importado.

Por que o Let's Encrypt precisa da porta 80?

A integração do firewall Sophos usa validação de domínio HTTP. Para fazer isso, o caminho de validação deve estar acessível de fora do firewall através da porta 80.

Pode-se usar um certificado Let's Encrypt para WAF?

Sim. WAF é um dos usos típicos. É importante que o certificado, o FQDN, os domínios na regra WAF, o endereço hospedado e o SNI correspondam.

Pode-se usar o certificado para Remote Access VPN?

Não para o túnel VPN em si. A Sophos suporta certificados Let’s Encrypt desta integração para portais e vários serviços da firewall, mas indica restrições para Remote Access VPN e Site-to-Site VPN. Um VPN Portal no browser e a ligação VPN propriamente dita devem, por isso, ser vistos separadamente.

O que você verifica se a renovação falhar?

Primeiro verifique DNS, porta 80, conflitos upstream NAT, DNAT ou WAF, status do certificado e visualizador de log. Para publicações do WAF, reverseproxy.log também é relevante.