Configurar uma CA subordinada para a inspeção TLS da Sophos Firewall

Para a inspeção TLS, a Sophos Firewall tem de voltar a assinar os certificados dos destinos HTTPS visitados. Em vez de utilizar a CA integrada SecurityAppliance_SSL_CA, pode ser usada uma CA empresarial subordinada dedicada. Os clientes geridos continuam assim a confiar na CA raiz da própria organização, enquanto a chave privada da CA subordinada permanece na firewall.

O processo seguro é composto por seis passos:

1. Gerar na Sophos Firewall um CSR para a nova CA subordinada.
2. Fazer com que uma Enterprise CA do Microsoft AD CS assine o CSR com o modelo Subordinate Certification Authority.
3. Importar o certificado de CA emitido diretamente no CSR existente.
4. Adicionar a CA raiz correspondente à firewall como Validation only.
5. Selecionar a CA subordinada como CA de re-assinatura e utilizá-la inicialmente apenas numa regra piloto.
6. Verificar a cadeia de certificados, o tráfego HTTPS real, os logs e o rollback.

⚠️ Uma CA de re-assinatura pode emitir certificados para domínios de terceiros. A sua chave privada é, por isso, especialmente sensível. A CA só pode ser utilizada no caminho de inspeção previsto e não pode ser exportada nem partilhada em tickets. Não deve ser ativada em produção sem um caminho de recuperação testado.

Este processo é descrito para AD CS no modo Enterprise CA. A Sophos indica expressamente que o procedimento documentado não se aplica a uma Standalone CA. Outra PKI interna também pode emitir uma CA subordinada, mas necessita de um processo próprio revisto pelo responsável da PKI.

Em alternativa, o CSR e as CAs podem ser gerados com uma ferramenta externa como OpenSSL. As CAs subordinada e raiz geradas externamente são carregadas em Certificates > Certificate authorities; uma CA de assinatura sem um CSR correspondente na firewall também requer a sua chave privada através do processo PKI aprovado. A raiz permanece sem chave privada. Trata-se de um caminho diferente de transferência de chaves, não da importação de CSR descrita abaixo. A CA subordinada também pode ser utilizada para configurações TLS de e-mail; a ativação e validação seguintes dizem respeito apenas ao tráfego Web e não ativam uma configuração TLS de correio.

Quando uma CA subordinada é útil

Uma CA subordinada própria é especialmente adequada para redes empresariais geridas onde os clientes já confiam numa CA raiz interna. Assim, não é necessário distribuir por todos os dispositivos uma trust anchor adicional e independente da Sophos. A rotação, revogação e responsabilidade podem ser integradas na governação da PKI existente.

No entanto, a solução não é automaticamente mais simples. A firewall recebe uma chave com a qual pode assinar certificados para a inspeção TLS. Por isso, a CA precisa de uma finalidade estritamente definida, responsáveis documentados, uma validade limitada e procedimentos testados de revogação e renovação.

Para ambientes mais pequenos sem PKI própria, a CA integrada da Sophos é frequentemente o caminho mais simples. Distribuir o certificado de CA da Sophos Firewall para a inspeção TLS explica a seleção e distribuição aos clientes. Introduzir corretamente a inspeção TLS da Sophos Firewall descreve todo o processo de piloto e exceções.

Preparar o design da CA e o caminho de recuperação

Antes de gerar o CSR, são definidos a finalidade, os nomes e as dependências. Um exemplo possível é:

• nome do objeto SFOS: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• CA raiz emissora: Example Enterprise Root CA
• utilização prevista: exclusivamente inspeção TLS e desencriptação HTTPS em FW01
• rede piloto: 10.20.30.0/24

Estes valores são exemplos de documentação e devem ser substituídos pela convenção de nomes, PKI e grupo piloto da organização. Uma CA separada por firewall ou cluster de inspeção claramente delimitado simplifica posteriormente a atribuição, revogação e rotação.

Antes da alteração, devem estar disponíveis:

• uma cópia de segurança atual da configuração e um acesso de gestão independente funcional,
• documentação da CA de re-assinatura atual e da sua distribuição aos clientes,
• acesso a uma Enterprise CA do AD CS e aprovação do responsável da PKI,
• um pequeno grupo de teste gerido com um caminho de recuperação funcional,
• um plano de revogação, renovação e retorno controlado à CA anterior.

Criar e restaurar uma cópia de segurança da Sophos Firewall explica o processo de backup e restauro. Uma cópia de segurança não substitui a documentação da CA de re-assinatura atualmente selecionada nem dos clientes que confiam nela.

Gerar o CSR na Sophos Firewall

O CSR é gerado na firewall para que a chave privada seja criada no dispositivo e não tenha de ser transportada entre o AD CS, o computador de administração e a firewall.

1. Abrir Certificates > Certificates.
2. Selecionar Add.
3. Em Action, selecionar Generate certificate signing request (CSR).
4. Introduzir um nome inequívoco, por exemplo SFOS-TLS-Inspection-SubCA-2026.
5. Escolher o tipo e comprimento da chave ou a curva, bem como o secure hash, de acordo com a política de PKI da organização. No exemplo, a Sophos mostra RSA, 2048 bits e SHA-256; são exemplos do produto, não requisitos universais.
6. Introduzir os atributos de subject e os Subject Alternative Names aprovados pela PKI interna.
7. Guardar o CSR e abri-lo através do ícone de download.
8. Utilizar Copy to clipboard e entregar o CSR exclusivamente através do processo autorizado do AD CS.

O CSR não contém a chave privada. Ainda assim, faz parte do processo controlado de PKI porque define a identidade, a chave pública e a finalidade de CA solicitada.

Em Subject name attributes, o formulário CSR contém Country name, State, Locality name, Organization name, Organization unit name, Common name e Email address. Introduzem-se os dados de identidade aprovados pela PKI, não os de um site visitado arbitrariamente. Subject Alternative Names aceita nomes DNS ou endereços IP, por exemplo web.exampleorg.com, fd12:3456:789a:1:: ou 203.0.113.10. Estes valores do exemplo do produto não são requisitos para uma CA de inspeção; os SAN são definidos com o responsável da PKI.

Emitir a CA subordinada com o AD CS

O CSR da Sophos é submetido na página de inscrição Web da Enterprise CA do AD CS responsável:

1. Abrir Request a certificate.
2. Selecionar Advanced certificate request.
3. Colar o CSR completo.
4. Em Certificate template, selecionar Subordinate Certification Authority.
5. Rever o pedido de acordo com o processo interno de aprovação e emiti-lo com Submit.
6. Em Certificate Issued, escolher um formato adequado, por exemplo Base 64 encoded.
7. Selecionar Download certificate para transferir o certificado da CA subordinada emitido.
8. Na página inicial do AD CS, abrir Download a CA certificate, selecionar a CA raiz que assinou a subordinada e escolher Download CA certificate e Save.

Limite importante da EKU: Se o certificado de CA emitido contiver uma secção Extended Key Usage, esta tem de incluir TLS Web Server Authentication para esta finalidade de assinatura. Se o valor estiver em falta, o certificado não deve ser usado como CA de re-assinatura em produção. O responsável da PKI deve corrigir o modelo da CA e emitir um novo certificado.

Antes da importação, verificar no visualizador de certificados o issuer, subject, validade, Basic Constraints e, quando exista, Extended Key Usage. Os ficheiros da raiz e da subordinada recebem nomes inequívocos para não serem confundidos com certificados de servidor.

Importar as CAs subordinada e raiz

Importar a CA subordinada no CSR existente

1. Abrir Certificates > Certificates.
2. Selecionar a ação de importação no CSR criado anteriormente.
3. Selecionar o certificado de CA subordinada emitido pelo AD CS.
4. Selecionar Certificate authority only. O SFOS reconhece o tipo de CA e apresenta as respetivas opções.
5. Verificar o nome e selecionar Import certificate.
6. Em Certificates > Certificate authorities, abrir o filtro junto de Name, introduzir o nome da CA e selecionar Apply.

O SFOS associa automaticamente à CA subordinada a chave privada correspondente ao CSR. Por isso, o ícone da chave privada deve estar visível para esta CA na lista. Se estiver em falta, a CA não está pronta para assinar. A importação geral em Certificates > Certificate authorities > Add também pode detetar um CSR existente correspondente. A importação diretamente no CSR descrita aqui torna a associação explícita, mas não é o único caminho documentado. Sem um CSR correspondente ou uma chave privada, carregar novamente o certificado não cria uma chave de assinatura.

Adicionar a CA raiz apenas para validação

O exemplo passo a passo da Sophos chama à finalidade Validation, enquanto a referência do campo CA lhe chama Validation only. A função segura pretendida aqui é a mesma: certificado raiz apenas para validação, sem a chave privada da raiz; não selecionar Signing and validation para a raiz. Para o carregamento, escolher o ficheiro em Certificate através de Browse.

1. Abrir Certificates > Certificate authorities e selecionar Add.
2. Carregar o certificado da CA raiz que emitiu a CA subordinada.
3. Em Use certificate for, manter Validation only.
4. Comparar o nome e o fingerprint com a documentação aprovada da CA raiz.
5. Guardar e voltar a verificar a cadeia da CA subordinada.

A firewall não necessita da chave privada da CA raiz. Signing and validation destina-se exclusivamente à CA subordinada cuja chave privada já está na firewall devido ao CSR. Importar e atribuir certificados na Sophos Firewall explica as diferenças gerais entre certificado, CSR, chave privada e cadeia de CA.

Selecionar a CA para a inspeção TLS

A importação, por si só, não altera o tráfego. A nova CA é primeiro ativada num piloto estritamente limitado. A DPI tem uma seleção global e uma possível substituição por regra; o Web Proxy tem uma seleção independente:

• DPI, global: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, por regra: o Decryption Profile atribuído em Profiles > Decryption profiles pode herdar ou substituir a seleção global.
• Web Proxy: Web > General settings > HTTPS decryption and scanning

As definições de DPI têm campos separados Re-sign RSA with e Re-sign EC with. Estes referem-se ao facto de o certificado original do site ter sido assinado com RSA ou EC. Em qualquer dos campos, o SFOS aceita uma CA RSA ou EC. Normalmente, é portanto possível selecionar a mesma CA subordinada em ambos. Uma segunda CA EC é particularmente útil quando uma aplicação só aceita um tipo específico de certificado; todos os endpoints afetados também têm de confiar nessa CA.

Um Decryption Profile atribuído a uma Inspection Rule pode herdar intencionalmente a seleção global com Use CAs defined in SSL/TLS settings. Se forem definidos no perfil valores próprios para Re-sign RSA with e Re-sign EC with, estes substituem as definições globais para essa regra. Antes do piloto, devem ser verificadas tanto a seleção global da CA como o perfil efetivamente atribuído à regra.

Só uma CA com a finalidade Signing and validation e uma chave privada disponível pode ser utilizada como CA de re-assinatura. Não alterar uma CA de assinatura em utilização para Validation only; deixaria de ser utilizável para a re-assinatura ativa. Isto não permite afirmar se o SFOS elimina a chave armazenada.

Garantir primeiro o âmbito do piloto: Uma alteração da CA global de DPI também afeta as regras existentes cujos perfis herdam a seleção global. Para um piloto DPI isolado, utilizar um Decryption Profile dedicado com valores de CA explícitos e atribuí-lo apenas à regra piloto já limitada ao grupo de teste. Não editar um perfil partilhado com a produção. Uma nova regra piloto não isola a seleção global de CA do Web Proxy; se a análise proxy já estiver ativa, é necessária uma alteração aprovada separadamente para todos os clientes afetados. Até lá, manter a CA global existente inalterada.

Para o piloto:

1. Documentar a seleção atual e as regras afetadas.
2. Selecionar a nova CA para certificados RSA e EC no caminho de inspeção previsto e, para DPI, confirmar se o Decryption Profile atribuído herda ou substitui a seleção global.
3. Limitar a regra ao grupo de teste ou à rede piloto definidos.
4. Verificar a cadeia de CA nos clientes piloto. Num domínio AD, a Enterprise Root CA já deverá ser de confiança, mas a cadeia completa até à nova CA subordinada tem de continuar a ser construída com êxito.
5. Gerar um pedido HTTPS real e verificar em conjunto os detalhes do certificado, a Inspection Rule, o Decryption Profile e a entrada de log.

A alteração alargada em produção só é efetuada depois de o piloto ser aprovado. A seleção da CA não ativa automaticamente uma Inspection Rule e a confiança do cliente não prova que o tráfego esteja realmente a ser desencriptado.

Verificação da API: separar a seleção de CA dos comutadores globais

Quem verifica ou automatiza a seleção de CA através da API XML tem de distinguir os campos do objeto SSLTLSInspectionSettings. As referências para o SFOS 22.0 e 23.0 indicam os mesmos campos; isso não comprova que uma firewall concreta já tenha aplicado uma alteração com êxito.

• RSACA e ECCA selecionam as CAs utilizadas para voltar a assinar certificados de servidor RSA e EC, respetivamente, correspondendo a Re-sign RSA with e Re-sign EC with. O valor é o nome do objeto CA previsto, por exemplo, SFOS-TLS-Inspection-SubCA-2026, e não um caminho para um ficheiro de certificado, uma chave privada ou um valor de ativação. A seleção não cria nem importa uma CA e não distribui confiança aos clientes. Os requisitos anteriormente descritos relativos à finalidade de assinatura, à chave privada, à cadeia e às substituições de perfil continuam a aplicar-se; se forem utilizadas duas CAs diferentes, os clientes afetados têm de conseguir validar ambas as cadeias.

• SSLTLSEngine ativa ou desativa o motor TLS, e SSLTLSInspection ativa ou desativa a inspeção SSL/TLS global; ambos aceitam Enabled ou Disabled. Estes campos não correspondem à seleção de CA nem ao estado da regra-piloto individual. Uma rotação de CA não justifica alterar estes comutadores globais. A referência da API indica Enabled como valor predefinido para ambos; contudo, para a alteração, o que conta é o estado atual lido, e não um valor predefinido da documentação.

• TLS13Decryption define o tratamento global das ligações TLS 1.3: Decrypt as 1.3 ou Downgrade to TLS 1.2 and decrypt, sendo Decrypt as 1.3 o valor predefinido documentado. O campo não seleciona uma CA de assinatura nem uma ação de uma regra de inspeção individual. Por conseguinte, a redução da versão do protocolo não é uma forma de corrigir a falta de uma cadeia de CA ou de uma chave de assinatura; numa alteração exclusivamente de CA, a definição de TLS 1.3 aprovada mantém-se inalterada.

Também SSLv2SSLv3, SSLCompression e SSLConnectionsExceeded são decisões globais distintas relativas a protocolos antigos, à compressão SSL e à ultrapassagem da capacidade de ligações SSL, respetivamente. Cada um aceita Allow without decryption, Drop ou Reject; a API indica Allow without decryption como valor predefinido para cada um, e não como recomendação de segurança. Estas decisões não devem ser repostas incidentalmente em valores de exemplo durante uma rotação de CA.

Antes de uma alteração através da API, guardar os valores globais efetivamente armazenados, os nomes de ambos os objetos CA, as substituições de perfil e as regras afetadas, e definir o procedimento exato de reposição do estado anterior. A referência identifica os campos mencionados como opcionais; isso não comprova que os campos omitidos permaneçam inalterados em todas as versões de firmware. Não executar nenhuma chamada de escrita automatizada sem confirmação do comportamento de atualização e de reposição para a compilação específica. Uma resposta da API documentada como 200 significa êxito da operação, e 500 significa erro da operação; mesmo uma mensagem de êxito não substitui a releitura dos valores armazenados nem o teste com novas ligações HTTPS. Um valor inesperado ou um estado pouco claro obriga a interromper a expansão do piloto.

Validar o funcionamento e a segurança

Um teste bem-sucedido inclui várias evidências:

1. Em Certificates > Certificate authorities, a CA raiz está presente como Validation only.
2. A CA subordinada tem Signing and validation atribuído e apresenta o ícone da chave privada.
3. Um cliente piloto confia na CA raiz e consegue construir a cadeia completa.
4. Um site HTTPS desencriptado de forma deliberada apresenta um certificado de servidor assinado pela nova CA subordinada.
5. O hostname, o destino original e o estado do browser estão corretos e não surge nenhum aviso de certificado inesperado.
6. O Log Viewer mostra a SSL/TLS Inspection Rule e a ação esperadas para este teste específico.
7. Uma origem fora do piloto permanece no caminho anterior.

As aplicações com certificate pinning, trust stores próprios ou caminhos de atualização sensíveis também devem ser testadas separadamente. Um único pedido bem-sucedido no browser não é suficiente para aprovar todo o rollout.

Para a aceitação, testar tanto um certificado de servidor RSA como um certificado de servidor EC no percurso DPI previsto e, em cada caso, comparar o emissor apresentado, a cadeia completa de CA raiz e subordinadas, a confiança dos clientes, o perfil efetivamente atribuído e a ação registada nos logs. Se as CAs de assinatura forem diferentes, verificar separadamente ambas as cadeias de confiança. Confirmar também que os comutadores globais, o tratamento de TLS 1.3 e as restantes decisões globais correspondem ao respetivo estado anterior documentado e que uma origem fora do piloto permanece inalterada. Trata-se de uma tarefa de verificação a executar no próprio ambiente, e não de um teste de equipamento realizado aqui.

Rotação e rollback

A CA subordinada deve ser renovada antes de expirar. Durante uma transição controlada, as CAs nova e antiga devem permanecer claramente distinguíveis. A nova CA é primeiro emitida, importada e verificada nos clientes piloto; só depois é selecionada gradualmente no caminho de inspeção.

Em caso de erro, utiliza-se o caminho de recuperação preparado:

Para reverter a CA, preferir restaurar a CA ou o perfil anterior. Desativar uma regra piloto, por si só, não garante nem a CA nem a desencriptação anteriores: uma regra posterior pode assumir o tráfego. Verificar previamente o caminho real de contingência e voltar a verificar o certificado e os logs após a alteração.

Uma reversão de CA repõe apenas as alterações de CA e de perfil decorrentes do piloto no estado anterior guardado. Definir indiscriminadamente SSLTLSEngine ou SSLTLSInspection como Disabled, ou alterar TLS13Decryption, não repõe nem a CA anterior nem o percurso de proteção anterior. Em seguida, voltar a ler a seleção e as substituições armazenadas, e verificar a cadeia de certificados e os logs com novas ligações. Se não existir um procedimento comprovado de reposição do estado anterior, não prosseguir com a implementação.

1. Repor a CA anteriormente utilizada para voltar a assinar os certificados ou o perfil de desencriptação anterior, conforme aplicável. Desativar a regra-piloto apenas se o percurso subsequente previamente verificado repuser o estado anterior aprovado; não desativar indiscriminadamente o motor ou a inspeção globais.
2. Verificar num novo processo do browser que o caminho de certificados anterior voltou a ser utilizado.
3. Não eliminar a nova CA enquanto regras, Decryption Profiles ou definições do Web Proxy fizerem referência a ela.
4. Envolver o responsável da PKI se a EKU, cadeia, modelo ou estado de revogação não forem claros.
5. Não continuar a utilizar chaves comprometidas; revogar a CA, emitir uma nova e limpar os trust stores de forma controlada.

Uma CA só é eliminada quando nenhuma configuração lhe faz referência, o caminho anterior já não é necessário e os requisitos de retenção e auditoria estão cumpridos.

Delimitar erros específicos

O ícone da chave privada está em falta

Verificar o CSR existente, o certificado emitido para esse CSR e a associação automática da chave. A importação em Certificates > Certificate authorities > Add também depende de o SFOS encontrar um CSR correspondente. Se o CSR correspondente estiver em falta ou o certificado não lhe corresponder, a associação não está demonstrada. Não importar chaves privadas a partir de tickets, e-mails ou armazenamento não controlado.

Não é possível selecionar a CA para re-assinatura

Verificar a finalidade da CA, o ícone da chave privada e as extensões do certificado. Se existir Extended Key Usage, tem de incluir TLS Web Server Authentication. Uma CA raiz com Validation only não está intencionalmente disponível para re-assinatura.

Um cliente comunica uma cadeia não fidedigna

Verificar as CAs raiz e subordinada, os respetivos fingerprints e o trust store do cliente afetado. Em seguida, comparar o issuer efetivamente apresentado no browser com a CA selecionada no SFOS. A mera presença da CA raiz na firewall ou no cliente não prova que esteja ativa a CA de re-assinatura correta.

O browser funciona, mas uma aplicação não

A aplicação pode utilizar um trust store próprio ou certificate pinning. Primeiro, documentar o destino, o cliente, a Inspection Rule e a hora do erro. Não criar uma exceção global Don't decrypt; delimitar o problema no pequeno piloto e aprovar apenas a exceção necessária com uma justificação documentada.

FAQ