Distribuir o certificado CA do Sophos Firewall para Inspeção TLS

Quando o Sophos Firewall descriptografa conexões HTTPS por meio de Inspeção TLS ou escaneamento HTTPS, ele cria um novo certificado para a conexão inspecionada e o assina com uma CA local. Os clientes precisam confiar nessa CA; caso contrário, o navegador mostra avisos ou os aplicativos interrompem a conexão.

O Sophos Firewall inclui, por padrão, a CA SecurityAppliance_SSL_CA. Seu certificado pode ser baixado em Certificates > Certificate authorities e distribuído aos clientes gerenciados. Porém, não basta instalar qualquer CA da Sophos: o certificado distribuído precisa corresponder à CA realmente usada para reassinar as conexões na configuração de Inspeção TLS.

Um ambiente com PKI empresarial própria pode emitir uma CA subordinada dedicada para a Inspeção TLS do Sophos Firewall. Essa abordagem mantém a chave de assinatura no firewall e vincula a confiança à CA raiz da empresa, mas exige um processo controlado de PKI e implantação piloto.

Além da CA integrada, é possível importar uma CA de assinatura gerada externamente ou criar uma Certificate Signing Request (CSR) no firewall e solicitar a uma CA externa, como Active Directory Certificate Services, a emissão de uma CA de assinatura subordinada. Nesse caso, importe no firewall tanto a CA subordinada quanto sua CA raiz. Os clientes precisam da âncora de confiança pública correspondente e da cadeia pública necessária, nunca da chave privada de assinatura. A orientação de PKI vinculada explica a emissão; os passos a seguir tratam da seleção, distribuição e verificação.

SecurityAppliance_SSL_CA não é a CA integrada Default, usada para certificados assinados localmente. Se essa outra âncora de confiança precisar ser substituída, siga o procedimento Renovar de forma controlada a Default CA do Sophos Firewall. Não substitua os dois objetos CA ao mesmo tempo apenas por suspeita.

A seleção da CA é verificada em pontos diferentes conforme o modo de operação. Nas SSL/TLS Inspection Rules baseadas em DPI, verifique Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Um Decryption Profile atribuído à regra pode sobrescrever esses valores globais. No Web Proxy, a CA de escaneamento HTTPS fica em Web > General settings > HTTPS decryption and scanning. Se o caminho ativo usar uma CA diferente daquela em que os clientes confiam, haverá erros de certificado mesmo que uma CA da Sophos já tenha sido distribuída.

O artigo Implementar corretamente a Inspeção TLS do Sophos Firewall descreve toda a implantação. Este guia se concentra na distribuição do certificado CA para Windows, macOS e Firefox.

O que este certificado faz

O certificado CA do Sophos Firewall não é um certificado de servidor para WebAdmin, WAF ou VPN Portal. Ele estabelece a confiança necessária para que os clientes aceitem as conexões HTTPS reassinadas pelo firewall.

É importante distinguir os componentes:

• CA do firewall: assina os novos certificados criados durante a Inspeção TLS.
• Re-Signing CA ou HTTPS Scanning CA: a CA especificamente selecionada para uso no modo DPI ou Web Proxy.
• Armazenamento de confiança do cliente: determina se navegadores e aplicativos confiam nessa CA.
• Regra de inspeção SSL/TLS: determina qual tráfego será descriptografado.
• Perfil de descriptografia: define o rigor do tratamento de certificados, versões TLS e erros.
• Lista de exclusão: impede a descriptografia de destinos problemáticos ou excluídos intencionalmente.

Distribuir a CA não ativa, por si só, a Inspeção TLS. A distribuição evita avisos de certificado nos clientes gerenciados quando o tráfego HTTPS é descriptografado. A descriptografia efetiva depende das regras de firewall, da política web, das SSL/TLS Inspection Rules, dos Decryption Profiles e das exceções.

A distribuição também não substitui o controle adequado dos protocolos. As SSL/TLS Inspection Rules se aplicam ao tráfego TCP. Se o tráfego web usar QUIC ou HTTP/3 sobre UDP 443, a inspeção seguirá outro caminho e precisará ser tratada separadamente.

Antes da implantação

Antes de distribuir o certificado, defina quais clientes usarão a Inspeção TLS. A CA não deve ser instalada indiscriminadamente em todos os dispositivos, mas apenas nos clientes corporativos gerenciados que fazem parte do escopo.

Preparação:

• Defina um grupo de teste ou uma OU de teste.
• Determine o modo de operação: DPI, Web Proxy ou ambos.
• Documente a CA selecionada em SSL/TLS inspection settings, nos Decryption Profiles usados e em Web General settings.
• Documente os procedimentos de reversão e de tratamento de exceções.
• Baixe o certificado CA somente do seu próprio firewall.
• Teste primeiro a distribuição em poucos dispositivos.
• Verifique navegadores, aplicativos empresariais e atualizações após a distribuição.
• Avalie separadamente dispositivos móveis e aplicativos com armazenamento de confiança próprio ou Certificate Pinning.
• Remova dos clientes as CAs antigas ou que não são mais usadas.

⚠️ Atenção: Se a CA ou a chave privada tiver sido comprometida, redistribuir o certificado não basta. Será necessário regenerar a CA no firewall, distribuir o novo certificado e remover a CA antiga dos clientes.

Escolher o método de distribuição

O método adequado depende de como os dispositivos são gerenciados.

• Clientes de domínio Windows: use GPO para distribuir o certificado em Trusted Root Certification Authorities. É o método recomendado para ambientes tradicionais de Active Directory.
• Windows sem domínio: use MDM, Intune ou importação local. A importação local é mais adequada para testes ou dispositivos individuais.
• macOS: use um perfil MDM ou o chaveiro System. A instalação manual é mais adequada para testes ou ambientes pequenos.
• Firefox: use o armazenamento de confiança do Windows ou as políticas empresariais da Mozilla. Verifique separadamente o comportamento do Firefox.
• BYOD ou dispositivos pessoais: normalmente, não distribua a CA para esses dispositivos. A Inspeção TLS deve ser aplicada a dispositivos corporativos gerenciados.
• Servidores: distribua apenas para cargas de trabalho cuja inspeção tenha sido avaliada. O tráfego de saída dos servidores pode envolver outros riscos e exigir outras exceções.

Em produção, a implantação também precisa poder ser revertida. Quem distribui a CA por GPO, MDM ou política deve testar como remover a CA antiga pelo mesmo mecanismo.

Baixar a CA do Sophos Firewall

Preparar a regra Web Proxy e a CA

Para uma implantação piloto de Web Proxy, abra Rules and policies > Firewall rules, escolha IPv4 ou IPv6 e crie uma regra em Add firewall rule > New firewall rule. Use um nome livre, como TLS-CA-Pilot, defina Source zones como LAN, Source networks and devices como a rede piloto, Destination zones como WAN e Destination networks como os destinos previstos. Adapte as zonas, redes e destinos ao caminho real do tráfego; não libere todos os clientes indiscriminadamente apenas para testar um certificado.

Antes das alterações, registre os valores anteriores da regra e a CA selecionada para a reversão. Verifique separadamente HTTPS scanning certificate authority (CA) em Web > General settings > HTTPS decryption and scanning, distribua primeiro seu certificado público a todos os dispositivos piloto afetados e confirme a confiança pelo fingerprint. A CA compartilhada do Web Proxy é global: alterá-la não é um piloto de CA por regra, afeta todos os clientes Web Proxy e exige confiança prévia nesses dispositivos e uma janela de manutenção.

Só depois, na regra de firewall selecionada, escolha a política web adequada em Security features > Web filtering, ative Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine e explicitamente Decrypt HTTPS during web proxy filtering, e salve com Save. A opção de escaneamento sozinha não descriptografa; selecionar a CA em Web > General settings não substitui o controle de descriptografia da regra de firewall.

Na configuração inicial, verifique em Certificates > Certificate authorities > Default se todos os parâmetros da Default CA estão configurados. Essa é uma verificação de configuração, não uma instrução para regenerar a CA ou distribuir Default no lugar da SecurityAppliance_SSL_CA realmente usada.

Baixar o certificado público da CA

No Sophos Firewall, o certificado é baixado pela interface web:

1. Entre no Sophos Firewall como administrador.
2. Abra Certificates > Certificate authorities.
3. Localize a CA SecurityAppliance_SSL_CA ou a CA própria escolhida para o ambiente.
4. Baixe o certificado pelo ícone de download.
5. Verifique se a mesma CA está selecionada na configuração ativa de Inspeção TLS.

O arquivo normalmente é salvo como SecurityAppliance_SSL_CA.pem. Ele contém a parte pública da CA e pode ser distribuído aos clientes. A chave privada nunca deve ser distribuída aos clientes.

Para um piloto manual, disponibilize o arquivo público verificado na intranet da empresa ou por uma distribuição controlada de e-mail. Os usuários devem salvá-lo localmente e comparar sua identidade com os dados do certificado documentados separadamente antes de conceder confiança. Para grupos maiores, prefira GPO ou MDM.

No SFOS 22, também é possível baixar a CA realmente selecionada diretamente no ponto em que ela é usada. No caminho DPI, o ícone de download fica ao lado de Re-sign RSA with e Re-sign EC with. Se houver duas CAs diferentes selecionadas, os clientes afetados precisam confiar em ambas. No caminho Web Proxy, o ícone fica ao lado de HTTPS scanning certificate authority (CA). Baixar o certificado no ponto de uso reduz o risco de distribuir um objeto CA com nome parecido, mas que não está ativo.

Trate o arquivo como um elemento de configuração de segurança. A parte pública não é uma senha, mas define em qual CA os clientes confiarão. Por isso, o arquivo deve vir do firewall de produção, ter sua versão controlada ou ao menos ser armazenado de forma rastreável, e não ser reaproveitado de projetos antigos. Antes da distribuição, registre Subject, Issuer, número de série, período de validade e fingerprint exibidos nos detalhes do certificado. Após a importação, compare esses valores em pelo menos um cliente piloto; o nome exibido, sozinho, não comprova a identidade.

Há dois caminhos adicionais para verificar a CA ativa:

• Modo DPI: abra Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings e compare a CA selecionada com o arquivo baixado. Se a regra ativa usar um Decryption Profile, verifique também a CA de reassinatura desse perfil.
• Web Proxy: abra Web > General settings > HTTPS decryption and scanning e verifique a CA de escaneamento HTTPS.

Essa verificação evita um erro comum de implantação: distribuir a CA padrão aos clientes enquanto o firewall já usa outra CA em um Decryption Profile ou no Web Proxy.

Distribuir o certificado no Windows via GPO

Em ambientes de Active Directory, use uma política de grupo. Edge, Chrome e muitos aplicativos do Windows usam o armazenamento de certificados do Windows para verificar a confiança na CA.

Caminho recomendado no Gerenciamento de Política de Grupo:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procedimento:

1. Abra o Gerenciamento de Política de Grupo em um controlador de domínio ou computador administrativo.
2. Use uma GPO existente para a configuração básica dos clientes ou crie uma nova GPO para o grupo de teste de Inspeção TLS.
3. Acesse Trusted Root Certification Authorities > Certificates.
4. Clique com o botão direito na lista de certificados.
5. Selecione All Tasks > Import.
6. Importe SecurityAppliance_SSL_CA.pem.
7. Vincule a GPO à OU de teste prevista. Se necessário, use um grupo de segurança no filtro de segurança, não como destino do vínculo da GPO.
8. Execute gpupdate /force em um cliente de teste ou aguarde a atualização normal.

Em produção, não aplique a GPO diretamente a todos os computadores. Uma OU de teste reduz o risco de uma importação incorreta ou de uma reação inesperada de um aplicativo.

Instalar o certificado localmente no Windows

Para dispositivos individuais de teste, o certificado pode ser importado localmente. Há duas opções:

• Armazenamento do computador local: vale para todos os usuários do dispositivo e costuma ser a escolha correta para clientes gerenciados.
• Armazenamento do usuário atual: vale somente para o usuário conectado e pode ser suficiente para testes.

Para o computador local:

1. Entre como administrador local.
2. Inicie certlm.msc.
3. Abra Trusted Root Certification Authorities > Certificates.
4. Clique com o botão direito na lista de certificados.
5. Selecione All Tasks > Import.
6. Importe SecurityAppliance_SSL_CA.pem.

Para o usuário atual, use certmgr.msc como alternativa.

Depois da importação, reinicie os navegadores e aplicativos. Alguns aplicativos podem exigir que o usuário saia e entre novamente ou que o cliente seja reiniciado.

Confiar no certificado no chaveiro do macOS

No macOS, o certificado é importado pelo Keychain Access, o aplicativo de gerenciamento de chaveiros.

Para um único usuário, também é possível usar o chaveiro login: abra o arquivo baixado com um clique duplo no Keychain Access, verifique sua identidade e selecione Always Trust. O Safari também usa essa confiança do macOS. Para uma implantação gerenciada que cubra todo o dispositivo, use System ou MDM; não confunda o escopo do usuário com o escopo do sistema.

Procedimento:

1. Copie SecurityAppliance_SSL_CA.pem para o Mac.
2. Abra o certificado com um clique duplo.
3. Importe-o no chaveiro System ou distribua-o por um perfil MDM gerenciado.
4. Abra o certificado e, em Trust, selecione Always Trust.
5. Confirme a alteração com uma conta de administrador.
6. Reinicie os navegadores e aplicativos afetados.

Em ambientes macOS maiores, distribua o certificado por MDM. A instalação manual é mais adequada para testes ou dispositivos individuais.

Dispositivos móveis com Sophos Mobile

⚠️ Android: instalar o certificado não autoriza a descriptografia. A Sophos documenta a importação da CA, mas também recomenda excluir todos os dispositivos Android da inspeção SSL/TLS em modo DPI devido a erros de certificado. Por isso, este guia adota a exclusão de DPI para todos os dispositivos Android como padrão. Os passos Android de importação e teste HTTPS abaixo se aplicam somente a um piloto gerenciado, restrito e aprovado separadamente: uma necessidade empresarial documentada deve justificar a exceção para dispositivos e aplicativos identificados. Antes da aprovação, verifique o armazenamento de confiança realmente usado e cada aplicativo afetado; em caso de falha, reverta o piloto e restaure a exclusão. A instalação por MDM não corrige Certificate Pinning nem garante a confiança de todos os aplicativos. A recomendação DPI não é uma afirmação geral sobre compatibilidade com Web Proxy; esse caminho também exige validação separada dos aplicativos.

Piloto móvel manual

Se o dispositivo não aceitar o arquivo PEM, pode ser necessário convertê-lo para um formato compatível, como .der, .cer ou .crt. A extensão, sozinha, não determina a codificação; nunca use um arquivo de chave privada. Os nomes dos menus variam conforme a versão do Android e o fabricante. Um exemplo para Pixel usa Settings > Security & location > Advanced > Encryption & credentials:

1. Em Credential storage, selecione Install from storage ou Install from SD card.
2. No seletor de arquivos, escolha o local em Menu > Open from e abra o arquivo público do certificado.
3. Digite o PIN do dispositivo, atribua um nome reconhecível ao certificado e escolha VPN and apps para esse piloto de aplicativos. Wi-Fi é a outra categoria oferecida. Confirme com OK.
4. Verifique a identidade e a importação em User credentials e teste uma requisição HTTPS descriptografada. Uma importação bem-sucedida não garante que todos os aplicativos Android confiem no armazenamento de certificados do usuário.

Para um piloto manual de iOS, disponibilize e importe o arquivo público da CA no dispositivo. Em Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates, conceda confiança somente ao certificado raiz identificado e teste HTTPS. Não ative várias CAs raiz desconhecidas.

Distribuir pela política do dispositivo

Para um número maior de dispositivos Android, iOS e iPadOS gerenciados, distribua a CA por uma política MDM. O Sophos Mobile pode adicionar o certificado raiz diretamente à política já atribuída aos dispositivos. A Apple recomenda MDM ou Apple Configurator; com Apple Configurator, primeiro crie um perfil de configuração no macOS. Depois, conecte um ou mais dispositivos iOS ao Mac para instalar o perfil que contém o certificado da CA.

Os certificados raiz instalados em dispositivos iOS e iPadOS por MDM ou Apple Configurator são automaticamente confiáveis. Isso difere da importação manual; a verificação abaixo não é uma instrução para alterar uma configuração de confiança que já esteja ativada.

Exemplo para iOS e iPadOS no Sophos Mobile:

1. Abra Policies > iOS & iPadOS.
2. Selecione a política já atribuída aos dispositivos previstos.
3. Na página Edit policy, selecione Add > Root certificate.
4. Em Root certificate, use Upload a file para enviar somente o certificado público da CA em que os dispositivos precisam confiar conforme a cadeia planejada. Para SecurityAppliance_SSL_CA, essa é a parte pública baixada do SFOS.
5. Salve com Apply e, depois, Save.
6. Na lista de políticas, use a seta e selecione Update devices. Se essa opção não estiver disponível, a alteração será distribuída na próxima sincronização automática.

No Android, adicione o certificado raiz a uma política Android da mesma forma. Depois, não verifique apenas o status da política. No iOS, a verificação fica em Settings > General > About > Certificate Trust Settings; no Android, em Settings > Security > Advanced > Encryption & credentials > User credentials. Uma requisição HTTPS realmente descriptografada continua sendo a comprovação final.

No iOS, verifique nessa tela a confiança no certificado raiz previsto, depois de confirmar sua identidade pelo fingerprint documentado. Se a confiança ainda estiver desativada, ative-a em Enable full trust for root certificates somente para esse certificado raiz. Se ele já for confiável, deixe a configuração inalterada. Em seguida, repita a requisição HTTPS descriptografada para verificar o resultado.

A chave privada da CA de reassinatura nunca deve ser enviada ao Sophos Mobile ou a um dispositivo cliente. Distribua somente o certificado público da CA. Comece com um grupo piloto pequeno e teste também a remoção da CA.

Verificar o certificado em dispositivos gerenciados

Após a distribuição, verifique pelo menos um dispositivo de teste de cada plataforma para confirmar que a CA foi importada no armazenamento de confiança correto.

• Armazenamento do computador Windows: abra certlm.msc e procure em Trusted Root Certification Authorities > Certificates.
• Armazenamento do usuário atual do Windows: abra certmgr.msc e verifique o armazenamento de confiança do usuário.
• macOS: abra o Keychain Access e verifique a confiança no chaveiro System.
• Firefox: abra Settings > Privacy & Security > Certificates > View Certificates.

Se um certificado estiver apenas no armazenamento do usuário, mas um aplicativo exigir o armazenamento do computador, o navegador poderá funcionar enquanto o aplicativo continua mostrando erros. Por outro lado, navegadores com armazenamento próprio podem ignorar a distribuição pelo Windows ou macOS se não estiverem configurados para usá-la.

Firefox no Windows

Para um único perfil de teste, também é possível importar manualmente: abra Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, selecione o arquivo público da CA e clique em Open. Em Downloading Certificate, ative somente Trust this CA to identify websites para a CA cuja identidade já foi verificada e clique em OK. Reinicie o Firefox e teste o caminho HTTPS descriptografado. Essa importação no perfil não substitui a distribuição centralizada.

As versões atuais do Firefox no Windows procuram, por padrão, CAs raiz instaladas adicionalmente no armazenamento de certificados do sistema operacional. Se a CA do Sophos Firewall for distribuída por GPO ao armazenamento do computador Windows, normalmente não será necessário importá-la novamente em uma base separada do Firefox. Esse comportamento é controlado por Allow Firefox to automatically trust third-party root certificates you install, pela preferência security.enterprise_roots.enabled ou pela política empresarial ImportEnterpriseRoots.

Há duas opções adequadas para ambientes Windows gerenciados:

• Usar o armazenamento de confiança do Windows: é o método recomendado quando a CA já é distribuída por uma GPO de computador. O uso automático das CAs do sistema operacional deve permanecer ativo na configuração gerenciada do Firefox.
• Importar o certificado diretamente por uma Mozilla Enterprise Policy: é a alternativa quando a confiança do Firefox é gerenciada separadamente de propósito ou quando o armazenamento do sistema operacional não deve ser usado.

Na primeira opção, a CA herdada do Windows pode funcionar sem aparecer como uma entrada importada separadamente no gerenciador de certificados do Firefox. Nesse caso, o armazenamento do computador Windows e um teste HTTPS real são os critérios de verificação. As instruções de GPO a seguir descrevem a segunda opção, com Install Certificates.

Baixar modelos de GPO do Firefox

A Mozilla disponibiliza os modelos de política no GitHub. São necessários, entre outros:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Os arquivos podem ser baixados do Repositório de Modelos de Política da Mozilla ou como policy_templates.zip.

Importar modelos

Copie firefox.admx e mozilla.admx diretamente para a pasta PolicyDefinitions escolhida. Os arquivos correspondentes firefox.adml e mozilla.adml devem ficar na subpasta específica do idioma, não ao lado dos arquivos ADMX.

Caminho local típico:

C:\Windows\PolicyDefinitions

Para o Central Store do domínio, use \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Substitua as duas ocorrências de <domain> pelo nome DNS do seu domínio AD. Se houver um Central Store, coloque os modelos da Mozilla nele; uma cópia apenas na pasta local não basta para editar as GPOs do domínio.

Mantenha as pastas de idioma do pacote baixado e use arquivos ADMX e ADML da mesma versão dos modelos. Por exemplo, coloque os ADML em inglês em C:\Windows\PolicyDefinitions\en-US ou, ao usar o Central Store, em \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Copie os demais idiomas necessários para as respectivas subpastas do pacote. en-US é um exemplo de idioma dos modelos, não uma exigência relacionada ao idioma deste artigo.

Reabra o editor de Política de Grupo e verifique se Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates aparece sem erros de recursos. Se a política não aparecer, corrija a pasta de destino, a subpasta de idioma e a correspondência das versões antes de configurar a política do certificado.

Configurar a política do Firefox

Na política de grupo, configure o certificado nas políticas do Firefox:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedimento:

1. Ative a política Install Certificates.
2. Insira o nome do arquivo do certificado, por exemplo, SecurityAppliance_SSL_CA.pem.
3. Copie o arquivo por GPO ou distribuição de software para o diretório esperado do perfil do usuário.

Dependendo da versão do Firefox e da configuração da política, os certificados são lidos destes diretórios:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Na próxima sessão do Firefox, o certificado deverá aparecer no gerenciador de certificados.

Verificar o funcionamento

Após a distribuição, não basta confirmar que o certificado está presente. É necessário verificar se a Inspeção TLS realmente funciona.

Testes recomendados:

1. Reinicie o cliente de teste ou saia e entre novamente com o usuário.
2. Abra o navegador e acesse uma página HTTPS cujo tráfego seja descriptografado pelo Sophos Firewall.
3. Exiba o certificado do site no navegador.
4. Verifique se a cadeia passa por SecurityAppliance_SSL_CA ou exatamente pela CA Sophos escolhida.
5. Correlacione a nova requisição no firewall por origem, destino e horário, identifique o modo de operação real e use as verificações correspondentes abaixo.
6. Teste aplicativos empresariais importantes, serviços de atualização, ferramentas de colaboração e provedores de identidade.

DPI: Em Rules and policies > SSL/TLS inspection rules, verifique a regra de inspeção correspondente, a ação, o Decryption Profile e a CA de reassinatura. Em Log Viewer > SSL/TLS inspection, correlacione a mesma nova requisição por origem, destino e horário e confirme a descriptografia e a regra ou ação aplicada. Verifique também as exclusões DPI.

Web Proxy: Confirme a regra de firewall que realmente corresponde, sua política web e Decrypt HTTPS during web proxy filtering. Verifique a HTTPS scanning certificate authority (CA) compartilhada em Web > General settings e as exceções aplicáveis em Web > Exceptions. Em Log Viewer, correlacione os logs relevantes de filtragem web/proxy para a mesma nova requisição por origem, destino e horário; o emissor e a cadeia do certificado no navegador precisam corresponder à CA selecionada. As regras de inspeção SSL/TLS não controlam a descriptografia do Web Proxy. Aqui, uma entrada de descriptografia DPI não é garantida nem exigida; uma entrada de filtragem web sozinha não comprova a descriptografia.

Se o navegador ainda mostrar o certificado público original do site, a conexão não foi descriptografada. Em DPI, verifique a regra de inspeção e suas exclusões; em Web Proxy, a regra de firewall correspondente, o controle de descriptografia e as exceções web. Outro caminho de tráfego ou QUIC/HTTP/3 também pode contornar o caminho TCP esperado.

Se o aviso do navegador desaparecer, mas os aplicativos ainda apresentarem erros, a causa muitas vezes não é o certificado. Pode ser Certificate Pinning ou armazenamento de confiança próprio. Em DPI, verifique também Decryption Profile, regra de inspeção e exclusões TLS; em Web Proxy, a regra de firewall e as exceções web conforme as verificações acima.

Para tráfego web, verifique também se QUIC ou HTTP/3 está contornando a inspeção esperada. O artigo Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall explica por que Block QUIC protocol continua relevante para filtragem web, escaneamento de malware e Inspeção TLS.

Erros comuns

• O navegador ainda mostra avisos de certificado: a CA pode estar no armazenamento de confiança errado. Verifique o armazenamento de certificados do Windows, macOS ou Firefox.
• Chrome funciona, Firefox não: verifique se o Firefox pode usar as CAs raiz instaladas adicionalmente no sistema operacional ou se há uma Mozilla Enterprise Policy separada. Reinicie o Firefox e teste o caminho HTTPS real.
• Alguns aplicativos interrompem a conexão: Certificate Pinning ou verificação própria de certificados são causas prováveis. Em DPI, verifique logs SSL/TLS e exclusões TLS; em Web Proxy, logs de filtragem web/proxy e Web > Exceptions, sempre para a mesma requisição.
• Somente alguns clientes funcionam: a GPO pode não estar sendo aplicada ou pode estar vinculada à OU errada. Verifique gpresult e o vínculo da GPO.
• A CA está instalada, mas o aviso permanece: a CA distribuída pode não corresponder à CA do Decryption Profile, de SSL/TLS inspection settings ou de Web General settings.
• DPI funciona, mas Web Proxy não, ou vice-versa: Use as verificações do modo real acima: regra de inspeção, perfil e logs SSL/TLS em DPI; regra de firewall, controle de descriptografia, CA compartilhada, exceções web e logs de filtragem web/proxy em Web Proxy.
• Há avisos após regenerar a CA: a nova CA ativa pode estar ausente nos clientes. Distribua primeiro seu certificado público e verifique o fingerprint. Remova uma CA antiga não comprometida somente quando nenhum caminho ativo ainda a usar; em caso de comprometimento, siga a emergência.
• Feeds de URL ou filtragem web não funcionam como esperado: o caminho HTTPS pode não estar sendo descriptografado. Verifique a Inspeção TLS e a política web.
• O certificado está presente, mas o tráfego não é descriptografado: Em DPI, pode faltar uma regra de inspeção correspondente; em Web Proxy, pode faltar o controle de descriptografia da regra de firewall ou haver uma exceção web. Use as verificações específicas do modo e confirme o caminho real do tráfego.
• Somente aplicativos móveis ou alguns clientes falham: Considere armazenamento de confiança próprio, Certificate Pinning e validação específica de cada aplicativo. Exclua Android de DPI por padrão; um piloto Android aprovado separadamente deve voltar à exclusão em caso de falha. Avalie outras exceções de forma restrita, em vez de desativar a inspeção globalmente.

Rotação da CA e emergência

Uma CA não deve ser usada por anos sem acompanhamento de sua validade, origem e distribuição. Em produção, mantenha um processo simples de gerenciamento do ciclo de vida da CA.

A CA integrada SecurityAppliance_SSL_CA pode ser regenerada. Porém, isso não é uma preparação sem riscos: a CA antiga e a nova não se tornam automaticamente confiáveis ao mesmo tempo em todos os clientes. Para uma transição DPI planejada com sobreposição, prepare uma CA de assinatura separada e teste-a em um Decryption Profile de escopo restrito. Já o Web Proxy tem somente a configuração global HTTPS scanning certificate authority (CA). Alterá-la afeta todo o caminho Web Proxy e exige uma janela de manutenção. Antes da alteração, todos os clientes afetados precisam confiar na nova CA pública. Em ambos os casos, a chave privada permanece no firewall.

Mudança planejada:

1. Registre a seleção da CA ativa, os fingerprints e todas as referências. Prepare uma CA de assinatura separada sem começar pela regeneração da CA integrada.
2. Distribua somente o certificado público ou a cadeia pública necessária: primeiro ao grupo piloto DPI ou a todos os clientes afetados antes de uma alteração global do Web Proxy.
3. No modo DPI, ative a nova CA em um Decryption Profile de escopo restrito e verifique o Issuer, a entrada no log e os aplicativos do grupo piloto.
4. Após o sucesso do piloto DPI, distribua o certificado público a todos os dispositivos gerenciados afetados e confirme a importação pelo fingerprint.
5. Altere os campos DPI restantes ou a CA global do Web Proxy. Use novas conexões para confirmar que a nova CA as assina e que a regra esperada é aplicada.
6. Remova a CA antiga dos armazenamentos de confiança dos clientes somente quando nenhum caminho de inspeção ainda fizer referência a ela e todos os dispositivos afetados tiverem recebido a nova CA.

Emergência em caso de comprometimento:

1. Restrinja ou desative temporariamente a Inspeção TLS de forma controlada, se necessário.
2. Substitua a CA afetada no firewall.
3. Distribua a nova CA pelo método definido.
4. Remova a CA antiga de todos os armazenamentos de confiança.
5. Verifique as exceções, o Log Viewer e os aplicativos afetados.
6. Documente a alteração no sistema de incidentes ou de gestão de mudanças.

Uma CA comprometida não é um problema comum de certificado. Se um invasor controlar a chave privada, os clientes poderão confiar em certificados falsificados. Por isso, a CA antiga precisa ser removida de todos os locais afetados.

Em uma reversão normal, primeiro restaure a CA documentada anteriormente no caminho de inspeção ou desative a regra piloto. Remova a CA distribuída somente para o piloto apenas depois que uma nova conexão mostrar o Issuer antigo ou o caminho original sem descriptografia. Retirar a confiança dos clientes enquanto o firewall ainda reassina com essa CA causa erros de certificado. Não exclua CAs compartilhadas ou ainda referenciadas.

Operação e manutenção

Inclua o certificado CA no processo operacional:

• Documente a data de validade e os responsáveis.
• Regenere a CA somente em uma intervenção planejada.
• Remova a CA antiga dos clientes após a migração.
• Verifique regularmente a distribuição por GPO ou MDM.
• Documente as exceções TLS e revise-as periodicamente.
• Inicie os processos de incidente e substituição da CA se houver suspeita de comprometimento da chave privada de assinatura ou do firewall. Perder um cliente que contém apenas o certificado público da CA não compromete a chave de assinatura.

Ao alterar a Inspeção TLS, verifique também as regras de firewall, os perfis de descriptografia e as listas de exclusão afetados. Caso contrário, o cliente poderá confiar na CA enquanto o firewall continua sem descriptografar o tráfego desejado.

FAQ