Configurar certificados Let's Encrypt na Sophos Firewall

Com certificados Let’s Encrypt na Sophos Firewall, é possível criar certificados HTTPS públicos diretamente na firewall e renová-los automaticamente. Isto é particularmente útil para publicações WAF, WebAdmin, User Portal, VPN Portal enquanto interface web, Captive Portal, SPX Portal, páginas de início de sessão de hotspots e configurações SMTP TLS.

A funcionalidade reduz o trabalho manual com certificados, mas não substitui um planeamento adequado. DNS, acessibilidade pública, porta 80, nomes dos certificados, regras WAF, acesso aos portais e monitorização têm de estar alinhados. Se uma validação ou renovação falhar sem ser detetada, um portal ou uma aplicação web publicada pode passar a apresentar um aviso de certificado, mesmo que a regra WAF esteja correta.

É importante distinguir entre o certificado do portal e o certificado da VPN: um certificado Let’s Encrypt pode proteger corretamente um VPN Portal no navegador. Para Remote Access VPN, Site-to-Site VPN e Chromebook SSO, a Sophos indica limitações. Estes casos devem ser planeados separadamente.

O percurso de rede também tem um limite claro: a função Let’s Encrypt integrada não é suportada para IPv6 na matriz atual do SFOS 22. Por isso, a emissão e a renovação exigem um percurso IPv4 funcional. Suporte IPv6 e limites na Sophos Firewall com SFOS 22 enquadra os restantes limites do produto.

Para publicar o servidor web propriamente dito, deve consultar-se primeiro Sophos Firewall WAF: publicar servidores web com segurança. Este artigo concentra-se nos certificados e na operação do Let’s Encrypt na firewall.

Quando o Let’s Encrypt faz sentido na firewall

O método Let’s Encrypt integrado faz sentido quando a Sophos Firewall fornece o próprio serviço público ou funciona como Reverse Proxy à sua frente.

• WAF / Web Server Protection: aplicações HTTPS acessíveis publicamente com FQDN próprio.
• WebAdmin: acesso administrativo com um certificado válido quando o WebAdmin é utilizado externamente ou internamente através de um FQDN.
• User Portal / VPN Portal: os utilizadores iniciam sessão num portal HTTPS ou descarregam configurações; isto não é o mesmo que o certificado utilizado pelo próprio túnel VPN.
• Captive Portal / Hotspot: os utilizadores veem uma página de início de sessão HTTPS sem avisos de certificado.
• SMTP TLS: Mail Protection ou configuração SMTP TLS com um certificado público.

Nem todos os serviços são adequados para este método. Para certificados wildcard ou certificados que devam ser utilizados em vários sistemas fora da firewall, costuma ser preferível criar o certificado externamente. A emissão é explicada em Criar um certificado wildcard Let’s Encrypt; a posterior importação e atribuição do certificado na Sophos Firewall é descrita separadamente.

Limites e diferenças importantes

A Sophos Firewall cria certificados Let’s Encrypt para FQDNs específicos. A integração não equivale a um cliente ACME gerido livremente num servidor Linux.

Pontos importantes:

• O domínio tem de ser especificado como FQDN completo.
• Os domínios wildcard não são adequados para o processo integrado da firewall.
• Os endereços IP não são nomes de certificado válidos para a validação HTTP-01.
• A validação HTTP do domínio tem de conseguir alcançar a firewall através da porta 80 e de IPv4.
• Para a validação, a firewall cria temporariamente uma regra WAF e volta a removê-la após a validação bem-sucedida.
• Durante esta validação, as aplicações web existentes protegidas por regras WAF podem ficar temporariamente inacessíveis através da firewall.
• Remote Access VPN, Site-to-Site VPN e Chromebook SSO não devem ser planeados com este método de certificado.
• Os certificados são válidos durante 90 dias; a firewall tenta renová-los automaticamente quando restam menos de 30 dias de validade.
• Se o registo Let’s Encrypt for cancelado na firewall, os certificados existentes deixam de ser renovados.

A Sophos introduziu esta funcionalidade com o SFOS 21. A análise da Avanet às novidades dessa versão encontra-se no artigo Sophos Firewall v21: as principais novidades. As Release Notes mais recentes incluem várias correções relacionadas com WAF e Let’s Encrypt. Em ambientes de produção, isto significa que o firmware, o estado dos certificados e o funcionamento de WAF devem ser verificados em conjunto, não isoladamente.

Pré-requisitos

Antes de criar um certificado, devem estar esclarecidos os seguintes pontos:

• A firewall executa uma versão do SFOS com suporte para Let’s Encrypt.
• Todos os nomes DNS incluídos no certificado podem ser resolvidos publicamente.
• As respostas DNS públicas apontam de forma consistente, em todo o mundo, para o endereço WAN ou para um endereço IP que encaminha a porta 80 para a firewall.
• O DNS não deve devolver destinos diferentes consoante a região. Ferramentas públicas de verificação DNS a partir de várias regiões ajudam a identificar problemas de Split-Brain DNS ou GeoDNS antes do pedido.
• Normalmente, apenas um endereço IP público relevante deve responder por cada nome. Vários A-Records só são adequados se todos os destinos envolvidos encaminharem de forma fiável o tráfego HTTP da porta 80 para a firewall.
• A porta 80 está acessível a partir do exterior para a validação HTTP.
• Não existe uma regra DNAT, WAF ou outra regra ativa no endereço IP público e na porta 80 afetados que intercepte o pedido de validação e o encaminhe para outro sistema.
• Filtros GeoIP, firewalls a montante, filtros do fornecedor e rotas SD-WAN não bloqueiam a validação.
• A própria firewall consegue comunicar com a Internet.
• A data, a hora e o NTP da firewall estão corretos.
• Está definido se o certificado será posteriormente utilizado em WAF, WebAdmin, num portal ou em SMTP TLS.
• Existe um responsável que verifica regularmente a validade do certificado, o estado da renovação e os serviços afetados.

⚠️ O Let’s Encrypt não resolve problemas de acessibilidade pública mal configurada. Se a porta 80 estiver bloqueada por uma regra DNAT antiga, outra regra WAF, GeoIP, um NAT a montante ou um filtro do fornecedor, o pedido ou a renovação do certificado pode falhar.

Planear os nomes dos certificados

Antes da configuração técnica, deve definir-se quais os nomes de host realmente necessários. Um bom planeamento dos certificados evita correções posteriores nas regras WAF, nos portais e no DNS.

Exemplos:

• portal.example.com: User Portal ou VPN Portal.
• vpn.example.com: VPN Portal ou caminho de download de SSL VPN.
• admin.example.com: WebAdmin, quando utilizado externamente ou através de um FQDN de gestão.
• app.example.com: aplicação publicada por WAF.
• mail.example.com: SMTP TLS ou Mail Protection.

Se existirem várias aplicações, não se devem incluir precipitadamente todos os nomes num único certificado. Um certificado com muitos nomes pode ser prático, mas também aumenta as dependências. Quando esse certificado é renovado, substituído ou revertido, todos os nomes de host incluídos são afetados.

Nas regras WAF, é ainda importante que o DNS, o certificado, os domínios da regra WAF e o SNI correspondam. Os princípios básicos encontram-se em Sophos Firewall WAF: publicar servidores web com segurança.

Criar a conta Let’s Encrypt e o certificado

A configuração é efetuada no WebAdmin, na área Certificates. A apresentação exata pode variar ligeiramente consoante a versão do SFOS, mas o processo permanece semelhante.

Registar a conta

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

1. Abrir Certificates > Let’s Encrypt.
2. Verificar o Subscriber Agreement e as condições.
3. Clicar em Register account.
4. Confirmar que o registo está ativo e sem avisos.

Quando o Let’s Encrypt altera as condições, o registo tem de ser confirmado novamente. Caso contrário, os certificados existentes deixam de ser renovados e não podem ser criados novos certificados. Na prática, este aviso deve fazer parte da revisão normal da firewall, em vez de ser adiado.

A Sophos Firewall avisa sobre alterações das condições, entre outros meios, por e-mail ao administrador e no Control Center. Estes avisos não devem ser tratados como simples mensagens informativas: sem nova confirmação, o funcionamento automático dos certificados fica interrompido.

Pedir o certificado

Em seguida, é criado o certificado propriamente dito.

1. Abrir Certificates > Certificates.
2. Clicar em Add.
3. Em Action, selecionar Request Let’s Encrypt certificate.
4. Introduzir um nome descritivo, por exemplo le-app-example-com.
5. Em Domains, introduzir os FQDNs pretendidos, por exemplo app.example.com.
6. Em Hosted address, selecionar o endereço WAN público para o qual estes domínios apontam.
7. Confirmar que a porta 80 encaminha realmente para a firewall a partir do exterior.
8. Clicar em Save.
9. Após alguns minutos, verificar em Certificates > Certificates se o certificado aparece como fidedigno e apresenta uma data Valid until válida.

Durante a validação, a firewall utiliza o mecanismo HTTP Challenge Response. Para isso, os sistemas externos do Let’s Encrypt têm de conseguir alcançar o caminho de validação. Se a firewall estiver atrás de um router, Load Balancer ou NAT do fornecedor, o encaminhamento tem de apontar para a firewall.

Se o nome do domínio for inválido ou não existir, a correção, consoante o estado, não consiste simplesmente em editar o CSR existente. Normalmente é mais seguro eliminar o pedido incorreto e criá-lo novamente com o FQDN corrigido.

Utilizar o certificado

Após a emissão, o certificado apenas está disponível. Só protege um serviço depois de ser selecionado ativamente nesse serviço.

Atribuições típicas:

• WAF: verificar a regra WAF afetada em Rules and policies > Firewall rules.
• WebAdmin: verificar o certificado da consola WebAdmin nas definições relacionadas com Admin/Device Access.
• User Portal / VPN Portal: verificar a configuração do portal ou do VPN Portal.
• Captive Portal / Hotspot: verificar a página de início de sessão e o certificado do portal.
• SMTP TLS: verificar a configuração de e-mail ou SMTP TLS.

Depois da atribuição, não basta guardar a configuração no WebAdmin; o serviço também deve ser testado externamente. Nas publicações WAF, convém testar a partir de fora da própria LAN, porque a vista DNS interna, o NAT Loopback ou a cache do navegador podem dar uma falsa sensação de segurança.

Teste de entrada em produção

Um teste bem-sucedido de entrada em produção abrange DNS, TLS, funcionamento do serviço e logging.

Lista de verificação:

• O FQDN resolve publicamente para o endereço esperado.
• A porta 80 está acessível à firewall durante a validação.
• A porta 443, ou a porta HTTPS utilizada, entrega o novo certificado.
• O navegador não apresenta avisos de certificado.
• O certificado contém o nome de host esperado.
• A data de validade corresponde ao certificado recém-criado.
• Além do certificado do servidor, o serviço também entrega os certificados intermédios necessários.
• A regra WAF, o portal, o WebAdmin ou SMTP TLS utiliza realmente este certificado.
• O Log Viewer não apresenta erros relevantes de WAF, do portal ou do certificado.
• Nas publicações WAF, reverseproxy.log corresponde ao momento do teste.

Um teste TLS externo simples também pode mostrar qual o certificado realmente entregue. É importante executar o teste a partir de fora da rede do cliente, não apenas num cliente interno.

Verificar a cadeia de certificados

Depois de mudar para um novo certificado Let’s Encrypt, não se deve verificar apenas o Common Name ou a entrada SAN. É igualmente decisivo confirmar se o cliente recebe a cadeia de certificados completa. Se um navegador, uma aplicação ou um sistema de monitorização indicar uma cadeia incompleta, a causa pode estar na seleção do certificado, num certificado antigo importado, numa regra WAF incorreta ou num Reverse Proxy intermédio.

Na prática, devem verificar-se os seguintes pontos:

• O teste HTTPS externo mostra o FQDN esperado sem avisos de certificado.
• O certificado entregue é realmente o novo certificado Let’s Encrypt da Sophos Firewall.
• A cadeia de certificados está completa e não é substituída por um certificado antigo do backend ou de um proxy.
• A regra WAF, o portal ou o WebAdmin utiliza o mesmo certificado apresentado no teste externo.
• Se estiver envolvido um Load Balancer, router ou Reverse Proxy a montante, esse sistema não entrega outro certificado.

Esta verificação é particularmente importante se o mesmo domínio tiver sido publicado anteriormente por outro caminho ou se várias regras WAF, regras DNAT ou proxies externos utilizarem o mesmo nome de host. Caso contrário, o WebAdmin pode mostrar um certificado válido, enquanto os clientes externos continuam a receber uma cadeia diferente ou incompleta.

Verificar as cadeias YE e YR após uma renovação

Os certificados Let’s Encrypt emitidos recentemente podem ser assinados através de YE1, YE2, YR1 ou YR2. O SFOS 22.0 MR2 Build 546 adicionou suporte para estes novos certificados raiz e intermédios. Para a entrega incompleta da cadeia registada como NC-181671, a Sophos também confirmou o rollout de um hotfix em todos os appliances, mas não indicou um único número de versão do hotfix. Por isso, continua a ser decisivo verificar a cadeia que é realmente entregue externamente: um certificado válido no WebAdmin não prova que o WAF, um portal ou o WebAdmin envia todos os certificados intermédios necessários.

Um sintoma típico surge imediatamente após uma renovação: o navegador funciona, mas curl, uma aplicação Go, um sistema de monitorização ou um dispositivo móvel mais antigo apresenta unable to get local issuer certificate ou certificate signed by unknown authority. Existem duas causas possíveis:

• A firewall entrega uma cadeia incompleta. Falta pelo menos um certificado intermédio necessário entre o certificado do servidor e a âncora de confiança.
• O cliente não confia na âncora de confiança. A cadeia entregue está completa, mas o truststore do sistema operativo, do contentor ou da aplicação está desatualizado.

A partir de um computador de administração externo, este comando de apenas leitura mostra os certificados que o serviço envia realmente. Substituir app.example.com pelo FQDN a verificar:

openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null

A saída deve incluir o certificado de app.example.com e os certificados intermédios necessários para a respetiva cadeia. A âncora de confiança raiz final normalmente não é enviada pelo servidor; tem de existir no truststore do cliente. Se a saída apresentar apenas o certificado do servidor ou faltar um certificado intermédio, o problema está no lado que entrega o serviço. Se a cadeia estiver completa, mas apenas alguns clientes falharem, devem verificar-se os pacotes CA do respetivo sistema operativo, runtime ou contentor.

Além disso, curl testa o mesmo URL com o truststore desse computador:

curl -Iv https://app.example.com/

Um navegador funcional, por si só, não é prova suficiente, porque os navegadores podem guardar certificados intermédios em cache ou validá-los de outra forma. Se o teste externo devolver um certificado diferente do esperado, devem verificar-se primeiro a atribuição do certificado à regra WAF ou ao portal, bem como eventuais proxies e Load Balancers a montante.

Para a correlação temporal, deve consultar-se primeiro o log do Let’s Encrypt na Advanced Shell. A saída termina com Ctrl+C:

tail -f /log/letsencrypt.log

letsencrypt.log mostra a emissão e a renovação. Para operações gerais de certificados utiliza-se tail -f /log/vpncertificate.log; para o funcionamento de WAF, tail -f /log/reverseproxy.log. Os logs não substituem o teste externo da cadeia, mas ajudam a relacionar temporalmente a renovação, a alteração do certificado e o primeiro acesso com falha.

Se a cadeia continuar incompleta depois de verificar a atribuição do serviço, o firmware atual e os hotfixes disponíveis, deve contactar-se o Sophos Support com a referência NC-181671. Devem ser fornecidos a versão e o build do SFOS, o serviço afetado, o FQDN, o Issuer, a hora, a saída de openssl e a mensagem de erro exata do cliente. Não se devem eliminar ficheiros CA com base numa suspeita, importar indiscriminadamente todos os certificados Let’s Encrypt nem reiniciar o WAF sem um procedimento de rollback documentado.

Monitorizar a renovação em produção

Os certificados Let’s Encrypt são válidos durante 90 dias. A vantagem da integração é que a firewall pode efetuar a renovação automaticamente assim que restarem menos de 30 dias de validade. Ainda assim, o processo não deve decorrer sem controlo.

Numa verificação operacional, devem ser controlados regularmente os seguintes pontos:

• A firewall executa uma versão atual e estável do SFOS?
• O certificado ainda é válido?
• A renovação automática foi concluída com êxito?
• A porta 80 continua acessível para a validação?
• Existem novas regras DNAT ou WAF que possam bloquear a validação?
• O registo Let’s Encrypt continua ativo e as condições alteradas foram confirmadas?
• Os utilizadores ou a monitorização apresentam avisos de certificado?
• Existem erros de WAF ou do portal no Log Viewer?

Esta verificação é particularmente importante após atualizações da firewall, alterações de WAF, mudanças de fornecedor, alterações de DNS e modificações em routers ou Reverse Proxies a montante.

Erros típicos

• O certificado não é criado: o FQDN pode não apontar para a firewall ou a porta 80 pode não estar acessível. Verificar a resolução DNS pública e a porta a partir do exterior.
• O pedido de certificado falha após uma alteração de WAF: uma regra existente interceta a validação HTTP. Verificar as regras DNAT, WAF e de firewall na porta 80.
• A validação falha consoante o país de origem: GeoIP, filtros a montante ou SD-WAN podem bloquear destinos de validação específicos. Para a emissão, a porta 80 não deve estar acessível apenas a partir do próprio país.
• O DNS devolve endereços IP diferentes consoante a região: o Let’s Encrypt não valida necessariamente a partir da região do administrador. As respostas DNS públicas devem apontar mundialmente para um caminho que encaminhe a porta 80 para a firewall.
• Vários A-Records apontam para sistemas diferentes: a validação pode alcançar aleatoriamente um destino que não encaminha o caminho do Challenge para a firewall. Simplificar o DNS ou garantir que todos os destinos encaminham corretamente o caminho do HTTP Challenge.
• A aplicação WAF fica temporariamente inacessível durante a emissão: a firewall utiliza temporariamente mecanismos WAF para a validação. Por isso, as publicações críticas não devem ser alteradas numa janela de produção não planeada.
• O certificado foi criado, mas o navegador mostra o certificado antigo: o serviço ainda utiliza outro certificado. Verificar a seleção do certificado na regra WAF, no portal ou no WebAdmin.
• O navegador ou a monitorização indica uma cadeia de certificados incompleta: está ativo o certificado errado, a cadeia não é entregue por completo ou um proxy a montante entrega outro certificado. Comparar o teste TLS externo, a regra WAF, a atribuição do portal e possíveis proxies.
• O navegador funciona, mas curl, Go ou a monitorização falham após a renovação: verificar externamente se todos os certificados intermédios necessários são entregues. Se a cadeia do servidor estiver completa, atualizar o truststore do cliente afetado; se estiver incompleta, verificar o firmware e os hotfixes e, se necessário, indicar NC-181671 ao Sophos Support.
• A aplicação WAF não funciona corretamente após a mudança de certificado: SNI, domínio, host do backend ou perfil de proteção podem não corresponder. Verificar a regra WAF, os domínios, reverseproxy.log e os logs do backend.
• A renovação não funciona: o caminho de validação foi alterado desde a criação. Verificar DNS, porta 80, NAT a montante e versão do firmware.
• A renovação para após a alteração das condições: se o Let’s Encrypt Subscriber Agreement tiver de ser confirmado novamente, os certificados novos e as renovações permanecem bloqueados até que Register account seja novamente confirmado.
• Os certificados não são renovados após o cancelamento do registo: se a conta Let’s Encrypt tiver sido cancelada na firewall, deve verificar-se primeiro o estado da conta e não apenas o certificado individual.
• O certificado deve ser utilizado para Remote Access VPN ou Site-to-Site VPN: esta integração não suporta essa finalidade. Para certificados VPN deve ser planeado um processo de certificados separado.
• O Control Center apresenta um aviso de WAF ou do certificado: uma regra WAF antiga, um reinício de WAF ou o estado do certificado pode estar a causar o problema. Verificar o Log Viewer, as regras WAF e a lista de certificados.

Se WAF e o certificado apresentarem problemas ao mesmo tempo, não se deve procurar apenas no certificado. WAF Matching, Hosted Address, domínios, SNI e acessibilidade do backend pertencem à mesma cadeia de erros.

Planear o rollback

Antes de alterar um certificado utilizado em portais públicos e aplicações WAF, deve estar claro como reverter a alteração.

Preparação recomendada:

• não eliminar imediatamente o certificado anterior
• documentar a regra WAF afetada e a configuração do portal
• manter disponível um acesso externo para testes
• conhecer o DNS TTL, caso os nomes de host 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 pode voltar a selecionar-se o certificado anterior. No entanto, se a causa for uma validação HTTP bloqueada, o rollback do certificado só resolve o problema a curto prazo. O caminho de validação terá de ser corrigido, caso contrário a próxima renovação voltará a falhar.

Lista de verificação

• FQDNs e serviços documentados.
• Resolução DNS pública verificada.
• Porta 80 verificada para a validação HTTP.
• Conflitos com DNAT, WAF, GeoIP, SD-WAN ou NAT a montante 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 com a cadeia completa e mais de um tipo de cliente.
• Log Viewer e, no caso de WAF, reverseproxy.log verificados.
• Responsabilidade pela renovação e monitorização definidas.
• Certificado antigo removido apenas depois de confirmado o funcionamento correto.

Perguntas frequentes