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.

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.

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. Transferir o certificado da CA subordinada emitido.
8. Transferir também o certificado da CA raiz que assinou a CA subordinada.

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. Abrir Certificates > Certificate authorities e procurar a CA importada.

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; carregar novamente o ficheiro noutro local não restabelece a associação de chave em falta.

Adicionar a CA raiz apenas para validação

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 seleção encontra-se em locais diferentes, consoante o caminho de inspeção:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Só uma CA com a finalidade Signing and validation e uma chave privada disponível pode ser utilizada como CA de re-assinatura. Uma CA de assinatura em utilização não deve ser alterada para Validation only, pois o caminho ativo de re-assinatura perderia a chave.

Para o piloto:

1. Documentar a seleção atual e as regras afetadas.
2. Selecionar a nova CA no caminho de inspeção previsto.
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.

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.

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:

1. Desativar a regra piloto ou voltar a selecionar a CA de re-assinatura anterior.
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

Se o certificado não tiver sido importado através do CSR correspondente, o SFOS não consegue associá-lo à chave criada na firewall. Verificar o caminho de associação do CSR e o certificado emitido. 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