Visão Geral

Este Guia da comunidade Sophos fornece informações sobre varredura em tráfego HTTPS.

As seguintes seções são cobertas:

O que é HTTPS?
O que é um certificado e uma autoridade de certificação?
O que é HTTPS Decrypt and Scan?
Quais são algumas questões de segurança para varredura HTTPS?
A verificação de AV no proxy da web interfere na verificação de AV no cliente?
Quais são os impactos de ativar a descriptografia e varredura HTTPS?
Posso adquirir uma autoridade de certificação que permite descriptografar e digitalizar sem precisar implantar nada nos clientes?
Não estou fazendo varredura de HTTPS e não tenho o certificado ou autoridade de certificação implantado, por que os usuários às vezes recebem avisos sobre certificados?
Qual é a maneira recomendada de reduzir / remover avisos para páginas servidas pelo firewall?
Qual é a maneira recomendada de reduzir / remover avisos para páginas servidas pelo proxy?
Informação relacionada

Aplica-se aos seguintes produtos e versões
Sophos XG Firewall
Sophos Sophos UTM
Sophos Web Appliance

O que é HTTPS?

HTTPS são mensagens HTTP enviadas por uma conexão criptografada TLS/SSL. Antes que as mensagens HTTP possam ser enviadas, uma conexão TLS/SSL deve ser estabelecida. Isso envolve um handshake que inclui a negociação de detalhes de criptografia, como cifras e o servidor que envia um certificado ao cliente. A maior parte da discussão sobre a descriptografia HTTPS é centrada em torno da conexão TLS/SSL, especialmente o handshake.

Se o cliente e o servidor concordarem com o mecanismo de criptografia, e o cliente tiver certeza de que o servidor é quem diz ser, a conexão é estabelecida. Depois disso, todo o tráfego dentro dessa conexão é criptografado, geralmente chamado de túnel criptografado. Se houver um bisbilhoteiro, ele poderá ver a negociação, mas não conseguirá decodificar o tráfego criptografado.

A única maneira de um bisbilhoteiro descriptografar o tráfego é interferindo no handshake e se inserindo na conversa. No entanto, existem razões criptográficas pelas quais eles não podem fazer isso sem alterar o handshake de uma forma que o cliente notará.

Em uma situação normal, o HTTPS fornece uma garantia ao navegador e ao usuário de que o servidor da web ao qual eles se conectaram é o pretendido e de que ninguém está interceptando o tráfego.

O que é um certificado e uma autoridade certificadora?

Um certificado é um blob de dados que inclui o nome do host do domínio, o proprietário e outras informações. O certificado é então assinado criptograficamente por uma Autoridade Certificadora, que garante que as informações no certificado são precisas. A assinatura também atua como uma soma de verificação, portanto, se alguma informação no certificado for modificada, a assinatura não será mais válida. O navegador do cliente examina o certificado e a autoridade certificadora que o assinou. Se o certificado corresponder ao domínio ao qual está tentando se conectar, e o certificado for assinado por uma autoridade de certificação confiável, ele conclui a negociação TLS/SSL. Depois disso, o resto da conexão é criptografada e o cliente envia a solicitação HTTP.

Uma Autoridade Certificadora (CA) é um termo que pode significar duas coisas diferentes. Pode significar um tipo especial de certificado que tem a capacidade de assinar outros certificados. Uma Autoridade certificadora também pode se referir a um tipo de empresa que controla uma Autoridade certificadora (um tipo de certificado) que pode assinar certificados para outras empresas. Existem muitas empresas de CA que têm seus certificados de CA confiáveis por padrão em todos os navegadores (geralmente chamados de CA de raiz confiável ou CA de raiz pública). Dessa forma, uma empresa pode ir a uma CA pública e fazer com que criem um certificado assinado por uma CA que é automaticamente confiável para todos os navegadores.

Em seu navegador, se você acessar https://www.sninformatica.com.br, poderá examinar o certificado e ver se ele foi assinado pela Autoridade Certificadora Digicert. Seu navegador o pré-instalou para que ele confie em todos os certificados assinados pela digicert, portanto, ele confia que www.sninformatica.com.br é quem diz ser. Se o navegador tentar acessar esse site e receber um certificado assinado por alguém não confiável, ele avisará o usuário. Se o site também usar algo chamado HSTS (HTTP Strict Transport Security), o aviso será aquele que você não pode ignorar.

O firewall vem instalado com um certificado gerado por uma Autoridade Certificadora não confiável e nem mesmo cobre seu próprio nome de host (porque isso é definido após a instalação). Este certificado é usado sempre que um cliente vai para uma página hospedada no próprio firewall (onde o nome do host ou IP do firewall aparece na barra de endereço). A maioria dos administradores desejará regerar ou instalar um novo certificado em vez de usar aquele que vem direto da instalação. Você pode adquirir um certificado de uma Autoridade de Certificação em que seu navegador já confie. Este certificado é usado para várias coisas, independentemente de você estar fazendo uma descriptografia e varredura HTTPS.

A parte do proxy da web do firewall também tem sua própria Autoridade de Certificação que usa, ao fazer a descriptografia e varredura HTTPS man-in-the-middle. Quando um navegador for para https://www.example.com , se você olhar o certificado, verá que ele foi assinado pela CA Sophos. Como o navegador não confia automaticamente na Sophos CA, ele exibirá um aviso.

É importante compreender a diferença entre o certificado do firewall e os certificados criados dinamicamente a partir da Autoridade de Certificação do proxy da web. O certificado do firewall pode ser adquirido para que nenhum usuário veja um aviso. Os certificados gerados pela Autoridade de Certificação apresentarão avisos aos usuários, a menos que a Autoridade de Certificação do firewall esteja instalada (como confiável) no navegador.

As Autoridades de Certificação podem ser uma “CA raiz” (nível superior, não assinado por ninguém) ou uma CA “intermediária” / “folha”. Este último tem a capacidade de assinar certificados, mas ele próprio é assinado por uma CA raiz. Às vezes, a ação de criar e assinar um certificado é chamada de emissão de um certificado. Portanto, é dito que um certificado foi emitido por uma CA em particular. Alguns navegadores também dirão “Verificado por” para significar que o certificado foi assinado por uma CA específica.

O que é HTTPS Decrypt and Scan?

Um man-in-the-middle é quando um bisbilhoteiro finge ser o servidor web (para o cliente) e então finge ser o cliente quando passa a informação para o servidor web real. Quando você ativa a descriptografia e varredura HTTPS, o proxy da web começa a fazer a descriptografia man-in-the-middle do tráfego HTTPS.

Uma sessão TLS/SSL é estabelecida entre o servidor web e o proxy web, e uma segunda sessão TLS/SSL é estabelecida entre o proxy web e o navegador do cliente. O proxy da web usará as informações do certificado real do servidor para criar um novo certificado em tempo real e, em seguida, assiná-lo usando sua própria Autoridade de Certificação. Este novo certificado é passado para o navegador do cliente no handshake TLS/SSL. É importante observar que o proxy da web não pode usar o certificado do próprio firewall porque o nome do host não corresponderia ao site ao qual o navegador está tentando se conectar. Ele não pode reutilizar o certificado real do servidor da web real, porque não seria capaz de descriptografar o tráfego. Ele deve criar um novo certificado que pode ser usado para descriptografia e, em seguida, deve ter esse certificado assinado.

Se o navegador do cliente aceitar o certificado e concluir o handshake TLS/SSL, ele enviará uma solicitação HTTP pela conexão criptografada para o que ele pensa ser o servidor da web, mas o que na realidade é o proxy da web. O proxy personifica o site, descriptografa os dados, faz a varredura e aplica qualquer política. Em seguida, ele criptografa novamente os dados para enviá-los ao servidor da web (agora fingindo ser o navegador). O mesmo acontece na resposta.

Se o navegador do cliente vê um certificado que parece correto, mas é assinado por uma Autoridade de Certificação na qual não confia, ele não concluirá o handshake TLS/SSL. Devido ao design de segurança dos navegadores ao fazer HTTPS, os usuários receberão um aviso. HTTPS é projetado e implementado de forma que ninguém possa espionar a conversa sem que o usuário saiba.

Os navegadores podem ter certificados de sites confiáveis específicos adicionais que evitam avisos apenas para esses sites. Os navegadores podem ter autoridades de certificação adicionais confiáveis, o que evita avisos devido ao certificado ser assinado por uma CA não confiável. Portanto, um administrador de rede pode instalar (confiar) a autoridade de certificação do proxy da web em cada computador / navegador. Agora, quando o proxy da web cria um certificado e o assina com sua CA, o navegador confia nessa CA e estabelecerá a conexão.

Quando a descriptografia e varredura de HTTPS não estão ativadas e um navegador do cliente faz a primeira solicitação HTTPS para um site, o navegador da web começa a negociar uma conexão TLS/SSL com informações SNI que têm o nome de domínio do site. Por exemplo, o navegador pode estar solicitando www.google.com/search, mas o proxy verá apenas uma conexão TLS/SSL com SNI para www.google.com. Ou pode solicitar innocentsite.com/…/malware.exe e o proxy vê apenas innocentsite.com. Depois que a conexão TLS/SSL for totalmente estabelecida e houver um túnel criptografado, o proxy não poderá ver as solicitações e respostas HTTP dentro dele. Portanto, ele só pode executar bloqueios com base na categoria do domínio no SNI enquanto a conexão ainda está sendo estabelecida. Ele não pode categorizar ou bloquear com base no caminho e não pode fazer a varredura de vírus em nenhum arquivo baixado. Ele conhece o total de bytes transmitidos e o tempo de conexão.

Quais são algumas questões de segurança para varredura HTTPS?

A descriptografia HTTPS significa que o proxy da web agora pode ver dentro do tráfego HTTPS criptografado. Qualquer pessoa com acesso de login ao firewall também pode ver esse tráfego. Se você não tiver senhas fortes em seu firewall, se permitir acesso ssh, se deixar seu firewall inseguro, a varredura HTTPS torna os clientes menos seguros. No entanto, se o seu firewall não for seguro, um invasor potencial terá alvos muito mais ricos do que o tráfego HTTPS.

A descriptografia HTTPS significa que o proxy da web verá e registrará os caminhos em uma sessão HTTPS. Isso não afeta a segurança, mas pode afetar a privacidade. Por exemplo, um administrador poderá ver o que seus usuários estão procurando no Google ou quais URLs eles estão acessando em seu banco.

Além da segurança do próprio firewall, ativar a varredura de HTTPS não torna você ou os clientes menos seguros.

A verificação de AV no proxy da web interfere na verificação de AV no cliente?

Se você tiver verificação de AV em seu endpoint, é perfeitamente normal verificar também no XG. Não há problema em digitalizar duas vezes (além de demorar mais) e, na verdade, você pode ativar especificamente dois scanners AV independentes no proxy da web XG e UTM. Algumas pessoas gostam de ter uma varredura única com o mecanismo Avira no proxy da web e, em seguida, Sophos AV no endpoint, com o conceito de que dois fornecedores de varredura diferentes são melhores. Outras pessoas que têm software AV de endpoint de outros fornecedores preferem usar o Sophos AV no proxy da web. Algumas jurisdições e regulamentações exigem varredura dupla.

A menos que você tenha uma rede rigidamente controlada onde administra todos os dispositivos, não há garantia de que todos os dispositivos tenham um antivírus. Portanto, a verificação de vírus no proxy da web no firewall é uma coisa boa.

Existem alguns aplicativos, sites e dispositivos que apresentam problemas com a verificação de vírus ou situações em que as proteções que fazem parte da verificação de vírus interferem no tráfego. Um exemplo seria as solicitações da web para arquivos parciais. Eles não podem ser verificados corretamente e, portanto, estão bloqueados (no modo de proxy UTM e XG). Se você tiver aplicativos ou sites específicos que façam solicitações da Web para arquivos parciais, precisará de uma exceção que desative o antivírus para esse tráfego específico.

Um administrador pode inserir exceções da web que evitam a verificação de vírus para certas fontes ou destinos. Eles também podem desativar a verificação de vírus no tráfego HTTPS, desativando a descriptografia HTTPS para tráfego específico usando exceções da web (XG e UTM), perfis da web (UTM), regras de firewall (XG) ou regras de inspeção SSL/TLS (XG). Eles também podem fazer com que determinado tráfego da web não passe pelo proxy da web (no UTM, esse é o skiplist do modo transparente; no XG, é uma regra de firewall de nível superior).

Quais são os impactos de ativar a descriptografia e varredura HTTPS?

Aqui estão algumas coisas a serem consideradas ao tentar decidir se usará a descriptografia e digitalização HTTPS:

Característica	Requisitos de descriptografia
Bloqueio de categorias	A descriptografia HTTPS não é necessária, embora forneça mais detalhes.
Bloqueio de tipo de arquivo	A descriptografia HTTPS é necessária (somente HTTP é uma proteção limitada).
Bloqueio de vírus	A descriptografia HTTPS é necessária (somente HTTP é uma proteção limitada).
Sandstorm	A descriptografia HTTPS é necessária (somente HTTP é uma proteção limitada).
Filtros de Conteúdo	A descriptografia HTTPS é necessária (somente HTTP é uma proteção limitada).
Proteção Avançada contra Ameaças	A descriptografia HTTPS é necessária (somente HTTP é uma proteção limitada).
Restringir logins para Google Apps	A descriptografia HTTPS é necessária.
Controle de aplicativos	A descriptografia HTTPS não é necessária para alguns aplicativos, embora seja necessária para outros.
Reporting	A descriptografia HTTPS não é necessária, embora forneça mais detalhes.
Proteção Pharming	A descriptografia HTTPS não é necessária.
Restrições do SafeSearch e do YouTube do mecanismo de pesquisa	A descriptografia HTTPS não é necessária.

Alguns computadores e dispositivos terão software de endpoint instalado que também pode fornecer proteção, mas HTTPS e varredura de vírus no firewall é a única maneira de garantir que todo o tráfego seja varrido para todos os dispositivos.

No entanto, há um equilíbrio de coisas a considerar:

O proxy da web é usado para dois propósitos principais: aplicação da política da empresa (não visita a sites adultos) e segurança (verificação de vírus em todo o tráfego) e, às vezes, uma combinação (não permitir download de qualquer executável). O objetivo com o qual você está usando o proxy e o quão forte você precisa dessa aplicação influenciará sua decisão. Se o mais importante são as políticas baseadas na categoria, você pode ficar sem a varredura HTTPS. Se o mais importante for a segurança, é mais provável que você precise dela.

Você pode ter alguns segmentos de rede com varredura HTTPS e outros sem. Por exemplo, você pode fazer com que computadores com fio façam varredura de HTTPS, uma rede sem fio com acesso corporativo para dispositivos corporativos que tenha varredura de HTTPS e uma rede sem fio de convidado que não tenha varredura de HTTPS. Você também pode ter diferentes segmentos de rede com diferentes políticas da web e acesso a diferentes categorias de sites. No XG Firewall em modo proxy, é configurado com várias regras de firewall, no XG Firewall em modo DPI com regras de inspeção SSL/TLS, enquanto no UTM é configurado com vários Perfis de Filtragem da Web.

Se cada computador estiver conectado ao Active Directory, o AD pode ser usado para enviar certificados e autoridades de certificação a esses computadores, facilitando a implantação.

Se cada dispositivo móvel tiver software de controle corporativo, você pode enviar certificados e autoridades de certificação para esses dispositivos, facilitando a implantação.

Se você tiver dispositivos BYOD que não sejam gerenciados corporativamente, será difícil colocar uma Autoridade de Certificação no dispositivo. Dito isso, é menos provável que eles tenham software antivírus e, portanto, é mais provável que façam download ou já contenham malware. Independentemente do HTTPS Decrypt and Scan, você provavelmente não deve tê-los no mesmo segmento de rede que o resto da sua rede corporativa ou dar-lhes acesso à sua rede corporativa. É melhor colocá-los em uma rede de convidados separada.

Qualquer dispositivo móvel que possa se conectar à rede celular pode ignorar qualquer controle de proxy da web que você tenha instalado, conectando-se por meio de dados móveis. No entanto, como não estão na conexão wi-fi e na LAN corporativa, é menos provável que representem um risco de segurança para sua rede, apenas para eles próprios.

Cada administrador precisa equilibrar sua necessidade de percepção das ações de seus usuários, bloqueando o tráfego que não está em conformidade com a política e protegendo o malware contra o trabalho administrativo adicional de implantar uma CA em cada dispositivo.

Outra consideração é que cada vez mais sites em todo o mundo estão usando HTTPS, e há um número crescente de sites que usam apenas HTTPS. A cada ano, a porcentagem do tráfego da web criptografado aumenta. A longo prazo, não realizar a descriptografia HTTPS significará que cada vez menos tráfego será verificado.

Finalmente, a descriptografia HTTPS requer mais recursos da CPU. O rendimento máximo da web diminuirá com a descriptografia HTTPS. No entanto, isso depende muito do seu hardware, do número de usuários, dos recursos habilitados e de muitos outros fatores.

Posso adquirir uma autoridade de certificação que permite descriptografar e analizar sem precisar implantar nada nos clientes?

Não, você não pode. HTTPS é projetado para que você não possa. Considere as implicações se isso não fosse verdade. Se você levasse o telefone a uma cafeteria e se conectasse ao wi-fi gratuito para fazer transações bancárias, gostaria que a cafeteria pudesse ver todas as informações da sua conta bancária? Como seu telefone está se comunicando com o site do banco usando HTTPS e a cafeteria não pode espionar o tráfego sem que você receba um aviso, você sabe que a comunicação é segura. Uma cafeteria (ou sua empresa) não pode usar um proxy da Web Sophos para descriptografar silenciosamente todo o tráfego HTTPS sem que o usuário permita, seja por meio da instalação de uma CA ou por meio de avisos do navegador.

Você deve usar a CA que vem com o firewall ou criar seu próprio certificado CA, que pode ser uma raiz autoassinada. Seu Microsoft Active Directory também tem sua própria Autoridade de Certificação (consulte Serviços de Certificados do Active Directory), onde você pode criar uma CA intermediária / folha que pode ser usada dentro do firewall.

Se fosse possível comprar uma CA de assinatura autenticada por uma CA raiz pública, isso quebraria todo o modelo de confiança no qual a criptografia SSL é baseada. O modelo de confiança depende das organizações que controlam os certificados raiz confiáveis, sendo seletivas e aplicando critérios estritos sobre quando permitem que um certificado seja assinado. Por exemplo, eles só devem assinar um certificado para google.com se a pessoa que está solicitando o certificado puder provar que controla esse domínio.

Mas se eles emitissem um certificado para um terceiro que pudesse ser usado para assinar qualquer certificado que o terceiro goste, eles estariam basicamente delegando a capacidade de criar e assinar certificados para QUALQUER domínio que seria confiável automaticamente por QUALQUER navegador. Isso permitiria que o comprador desse certificado configurasse seu próprio site e fingisse ser google.com, facebook.com, wellsfargo.com ou qualquer pessoa de sua preferência, e os navegadores simplesmente aceitariam.

Houve uma situação genuína em que uma CA do governo francês, amplamente confiável para a maioria dos navegadores da web, emitiu uma CA de assinatura para outro departamento do governo para uso em um produto de filtragem da web HTTP. O perigoso nisso tudo era que esse produto de filtragem da web estava agora efetivamente criando novos certificados à esquerda, à direita e ao centro para todos os tipos de sites que seriam confiáveis por QUALQUER navegador executado por qualquer pessoa no mundo. Veja este artigo sobre o incidente: https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in -france / .

No entanto, você pode comprar um certificado para um nome de host específico ou todos os nomes de host de um domínio assinado por uma CA confiável. Adquirir um certificado e usá-lo no firewall interromperá todos os avisos de usuários que acessam o WebAdmin, Portal do usuário, Portal cativo ou outras páginas exibidas no próprio firewall. Mas os certificados adquiridos não podem ser usados como Autoridade de Certificação para avaliação HTTPS.

Não estou fazendo varredura de HTTPS e não tenho o certificado ou autoridade de certificação implantado, por que os usuários às vezes recebem avisos sobre certificados?

Se você estiver bloqueando uma categoria como Jogos de azar e um usuário acessar https://www.pokerstars.com/, você deseja que essa solicitação seja bloqueada. O proxy da web vê que o cliente está tentando ir a algum lugar que não deveria e deseja exibir uma página de bloqueio. Para fazer isso, eles precisam fazer a descriptografia man-in-the-middle para que possam inserir uma página de bloqueio que finge ser www.pokerstars.com.

No XG 17.5 e posterior, em Web > General Settings, você pode configurar que as conexões HTTPS que são bloqueadas quando a digitalização está desativada sejam simplesmente interrompidas. Nesse caso, se um usuário fosse para www.pokerstars.com, ele apenas obteria uma conexão com falha ao invés de uma página de bloqueio.

Se você estiver impondo a autenticação e um usuário não autenticado estiver navegando, ele precisará ser redirecionado para o AD SSO ou o Captive Portal para se autenticar. Se o site que eles estão tentando acessar for HTTPS, para fazer o redirecionamento, pode ser necessário fazer a descriptografia man-in-the-middle usando a Autoridade de Certificação. Se o usuário for enviado para o Captive Portal, isso será exibido em HTTPS usando o próprio certificado do firewall.

Para ser claro, você pode obter um certificado gerado pela varredura de HTTPS man-in-the-middle para realizar o redirecionamento. Você também pode obter um certificado do próprio firewall.

Se você estiver usando sandstorm e o firewall precisar de tempo para analisar o arquivo, ele exibirá uma mensagem para o usuário e permitirá que ele baixe o arquivo alguns minutos depois. Essas páginas usam o certificado do firewall.

Qual é a maneira recomendada de reduzir / remover avisos para páginas servidas pelo firewall?

Todas as páginas que são servidas pelo firewall (onde a barra de endereço dos navegadores tem seufirewall.suaempresa/ ou o IP) usam o certificado do firewall. Isso inclui WebAdmin, Portal do usuário, Captive Portal (XG Firewall) e Sandstorm.

Você pode ir a uma das várias empresas de autoridade de certificação e adquirir um certificado para seu firewall.suaempresa ou para * .suaempresa. Muitas empresas já terão um certificado adquirido que já usam em seus outros servidores. Uma forma de adquirir um certificado é gerar um CSR (Certificate Signing Request), que é basicamente um certificado não assinado. Em seguida, você envia esse CSR para uma CA pública. As autoridades de certificação públicas são obrigadas a garantir que as informações no CSR estejam corretas e que você seja o proprietário do domínio que está solicitando antes de assiná-lo.
Se você já tem uma Autoridade de Certificação interna (geralmente do Serviço de Certificação do Active Directory), pode usá-la para criar e assinar um certificado.
Se você estiver fazendo a descriptografia HTTPS e implantando a autoridade de certificação em todos os clientes, poderá usar essa CA para emitir um certificado.

Por padrão no XG Firewall, quando o proxy da web redireciona um usuário para o firewall, ele usa o IP do firewall que não pode ser coberto por um certificado. Para redirecionar para o nome do host, consulte o seguinte:

Sophos XG Firewall: Use o nome do host para redirecionamentos de página

No XG 17.5, o nome do host usado nas configurações de redirecionamento pode ser encontrado em Administration > Admin Settings.

É possível configurar o Cptive portal para ser exibido em HTTP em vez de HTTPS e, portanto, não requer um certificado. No entanto, isso não é recomendado porque as senhas seriam enviadas sem criptografia pela rede.

Qual é a maneira recomendada de reduzir / remover avisos para páginas servidas pelo proxy?

A maioria dos clientes usará a Autoridade de Certificação que vem com o sistema por padrão.

Algumas empresas já podem ter uma Autoridade de Certificação que estão usando, que gerou certificados para seus computadores internos e implantou em seus clientes. Um exemplo seria dos Serviços de Certificados do Active Directory. Outro exemplo seria de um proxy da web pré-existente. Se você tiver uma CA que deseja usar, poderá instalá-la no firewall e usá-la no proxy da web. Em vez de usar sua Autoridade de certificação raiz, você pode criar uma Autoridade de certificação intermediária e usá-la. Você ainda precisará instalar a autoridade de certificação raiz (sem chave privada) para que o proxy da web possa construir a cadeia de certificação completa.

No WebAdmin, você pode baixar uma cópia da Autoridade de Certificação que pode ser implantada em todos os clientes usando o Active Directory. Observe que o Windows / Internet Explorer e o Chrome usam o mesmo armazenamento de Autoridade de Certificação; no entanto, o FireFox tem seu próprio armazenamento separado.

Se você tiver vários firewalls, convém criar uma Autoridade de Certificação separada de um firewall e, em seguida, instalar e usar em todos os seus firewalls.

Se você quiser usar um certificado no próprio firewall gerado pela Autoridade de Certificação, é mais fácil começar com uma Autoridade de Certificação separada do firewall e, em seguida, instalá-la.

O Sophos Mobile Control e algumas outras maneiras de gerenciar dispositivos móveis corporativos permitem que você envie o CA para todos os dispositivos gerenciados.