Solução de Problemas de Inspeção TLS

Introdução

Este artigo cobre cenários de solução de problemas avançados para Inspeção TLS. Antes de prosseguir, é recomendável revisar a configuração de Inspeção TLS e o comportamento para entender como o tráfego é processado e aplicado.

Em condições normais, a Inspeção TLS não é visível para os usuários finais. Para verificar se o tráfego está sendo inspecionado, verifique o campo Inspeção TLS nos Eventos de Contas (1 = inspecionado, 0 = ignorado), reveja o emissor do certificado no navegador (Cato Networks) ou utilize relatórios de Inspeção TLS.

O Cato inclui um conjunto de regras de bypass padrão para aplicativos, dispositivos e domínios bem conhecidos. Essas regras geridas pelo sistema não são editáveis e devem sempre ser revisadas antes de criar regras personalizadas. Para detalhes adicionais, consulte Regras de Bypass Padrão

Sintomas

Causas possíveis

A maioria dos problemas de Inspeção TLS está relacionada a algumas condições comuns.

  • Alguns aplicativos não são compatíveis com Inspeção TLS. Aplicativos usando fixação de certificado, validação de TLS rigorosa ou TLS mútuo rejeitarão interceptação e falharão na conexão.

  • Problemas de confiança em certificados no cliente são outra causa frequente. Se o certificado raiz do Cato estiver faltando, não for confiável ou implantado inconsistemente, o tráfego inspecionado falhará mesmo que a política esteja correta.

  • Em outros casos, o problema origina-se do servidor de destino. Problemas como certificados expirados, cadeias incompletas, incompatibilidades de nome de host ou autoridades de certificado desconhecidas podem não ser sempre visíveis no navegador quando a Inspeção TLS está ativada, mas ainda são aplicados pelo PoP.

  • Sistemas legados podem falhar devido a incompatibilidade de protocolo TLS ou cifra. Aplicativos usando versões desatualizadas do TLS ou suítes de cifras fracas podem não atender aos requisitos definidos na política de Inspeção TLS.

  • Sites modernos também podem introduzir problemas devido a múltiplos domínios dependentes. Se apenas o domínio principal for permitido ou ignorado enquanto domínios de suporte são bloqueados ou inspecionados de maneira diferente, os usuários podem experimentar lentidão no carregamento ou ausência de conteúdo.

  • Finalmente, o comportamento específico da plataforma desempenha um papel. Dispositivos móveis, endpoints BYOD e sistemas Linux podem se comportar de maneira diferente devido a limitações de confiança de certificados, validação específica de aplicativo ou regras de bypass padrão.

Solução de Problemas Inicial

Ao investigar problemas relacionados ao TLS, o objetivo principal é determinar se o problema origina-se do cliente, da rede (Inspeção TLS) ou do servidor de destino.

1. Isolar o Escopo

Comece validando se o problema é específico do cliente. Teste o mesmo URL:

  • A partir de um navegador diferente
  • A partir de outro dispositivo na mesma rede
  • A partir do mesmo dispositivo em uma rede diferente (por exemplo, hotspot)

Se o problema estiver limitado a um navegador ou dispositivo específico, isso geralmente indica um problema de confiança local ou de configuração. Se funcionar fora da rede, o problema provavelmente está relacionado à Inspeção TLS ou aplicação de política.

2. Verificar Inspeção TLS / Emissor de Certificado

Pelo navegador:

  • Abra o DevTools → aba Segurança ou clique no ícone de cadeado
  • Inspecionar a cadeia de certificados

Verifique o Emissor:

  • Proxy/CA Empresarial (por exemplo, Cato) → Inspeção TLS está ativa
  • CA Pública (por exemplo, DigiCert, Let’s Encrypt) → Sessão TLS direta

3. Validar Confiança de Certificado no Cliente

  • Garanta que o certificado raiz do Cato esteja devidamente instalado no endpoint.

  • Verifique se o certificado raiz está no repositório de confiança do SO:
    • No Windows, abra o Gerenciador de Certificados do Computador digitando certlm.msc e procure o certificado raiz em Autoridades de Certificação Raiz Confiáveis
    • No Mac, abra Acesso às Chaves e procure o certificado raiz no Sistema de Chaves
  • Verifique o tempo e data do sistema
  • Se o certificado raiz do Cato estiver ausente do endpoint, faça o download e instale-o conforme explicado em Instalação do Certificado Cato em Dispositivos

  • Configuração de confiança ausente ou incorreta causará falhas imediatas no TLS.

4. Testar o Handshake TLS do Cliente

Use ferramentas no lado do cliente para simular uma conexão TLS e identificar exatamente onde e porque o handshake falha. Essas ferramentas expõem erros que muitas vezes estão ocultos atrás de mensagens genéricas do navegador.

Execute o seguinte ou similares do endpoint afetado:

curl.exe -v https://

Se o OpenSSL estiver disponível:

openssl s_client -connect :443 -servername

Saída Esperada (Sucesso)

* Conexão SSL usando TLS1.2 / TLS1.3
* Certificado do servidor:
*  subject: CN=www.google.com
*  issuer: CN=GTS CA 1C3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

É importante primeiro determinar se o problema está relacionado ao cliente, ao servidor de destino ou à própria configuração de Inspeção TLS. 

Solução de Problemas de Problemas Comuns

Nota:
Os problemas listados abaixo representam cenários comuns observados em implantações de Inspeção TLS. Muitos destes erros são genéricos e podem ou não se aplicar diretamente ao seu ambiente específico.
Se os sintomas ou resoluções descritos não se alinham com o seu caso, recomenda-se coletar dados diagnósticos (por exemplo, SSS, HAR e PCAP) da máquina do cliente e abrir um ticket de suporte para uma análise mais profunda.

Solução de Problemas ao Falhar Aplicação 

Problema: Certas aplicações falham ao estabelecer conexões seguras ou param de funcionar após a Inspeção TLS ser ativada.

Expectativa Comportamental:
Aplicações com controles de segurança rigorosos (por exemplo, aplicativos bancários, ferramentas de segurança de endpoint) podem falhar imediatamente em conexões, travar silenciosamente ou repetir conexões. Isso ocorre porque a Inspeção TLS introduz um certificado de homem no meio (MITM), que essas aplicações são especificamente projetadas para detectar e rejeitar.

Resolução:
Valide ignorando a Inspeção TLS para um único usuário ou IP de origem usando uma regra no topo da política. Se o aplicativo funcionar quando ignorado, crie uma exclusão direcionada (baseada em domínio/FQDN) e evite regras amplas. Além disso, o Assistente de Configuração de Inspeção TLS de Cato pode ser usado para ignorar domínios sensíveis com uma configuração mínima. 

Se o aplicativo ou servidor aplica pinagem de certificado ou requisitos estritos de TLS, a Inspeção TLS não pode ser aplicada. Nesses casos, a abordagem correta é ignorar permanentemente esse tráfego.

Exemplo:
Se um aplicativo financeiro falhar ao fazer login e funcionar imediatamente após ignorar a Inspeção TLS para esse usuário, isso confirma incompatibilidade - adicione o domínio do aplicativo à lista de bypass. 

Solução de Problemas de Aviso de Certificado no Navegador

Problema: Usuários recebem avisos de certificado ou aplicativos falham após habilitar a Inspeção TLS.

Expectativa Comportamental:
Os usuários podem encontrar avisos no navegador (por exemplo, \"conexão não segura\") ou falhas completas na conexão. O comportamento pode variar entre dispositivos dependendo de como o certificado Cato está instalado.

Resolução:
Garanta que o certificado raiz de Inspeção TLS do Cato esteja instalado e confiável em todos os endpoints. Implante usando GPO/MDM e verifique a cadeia completa de certificados no cliente.

Se certificados privados/internos forem usados, garanta que sejam devidamente confiáveis ou siga procedimentos relevantes de controle de certificado de Inspeção TLS.

Se o comportamento for inconsistente, valide ignorando a Inspeção TLS para um único usuário ou dispositivo para confirmar o impacto relacionado ao certificado.

Consulte Protegendo o Tráfego com Inspeção TLS Usando Certificados Privados se utilizar certificados privados em sua organização. 

Solução de Problemas de Incompatibilidade de Nome de Host

Problema: Usuários encontram erros de certificado ou conexões bloqueadas devido à incompatibilidade de nome de host ao acessar determinados websites, especialmente quando a Inspeção TLS está habilitada.

Expectativa Comportamental:
Quando um servidor apresenta um certificado cujo Nome Comum (CN) ou SAN não corresponde ao nome de host solicitado, a conexão é considerada inválida.

Sem Inspeção TLS, o navegador detecta diretamente essa incompatibilidade e exibe um aviso de certificado.

Com a Inspeção TLS habilitada, o navegador estabelece a sessão TLS com o PoP do Cato em vez do servidor de origem. O PoP re-assina o certificado usando o CA raiz do Cato, fazendo com que pareça válido ao cliente. Como resultado, nenhuma incompatibilidade é mostrada no navegador, embora o problema ainda exista no back-end.

Resolução:
Valide o comportamento ignorando a Inspeção TLS para um usuário ou IP de origem específico. Se o navegador então mostrar um erro de incompatibilidade de nome de host, isso confirma que o problema origina-se do servidor de destino.

Como a incompatibilidade é causada pela configuração de certificado do servidor, não pode ser corrigida pela Inspeção TLS. A ação apropriada é:

  • Permitir acesso ignorando a Inspeção TLS para o domínio específico, ou
  • Bloquear o tráfego com base na política se a incompatibilidade for considerada um risco de segurança

Evite regras amplas de bypass e use exclusões de domínio/FQDN direcionadas, quando necessário.

Exemplo:
Ao acessar https://www.testingmcafeesites.com/, o servidor apresenta um certificado para platformsplat1.mcafee.com.

Sem Inspeção TLS, o navegador imediatamente sinaliza uma incompatibilidade de nome de host.

Com a Inspeção TLS habilitada, o navegador vê um certificado válido emitido pelo CA raiz do Cato para www.testingmcafeesites.com, então nenhum erro é exibido. No entanto, o PoP do Cato detecta a incompatibilidade nos bastidores e aplica a política configurada (bloqueio ou aviso).

Solução de Problemas de Carregamento de Website ou Aplicação

Problema: Websites falham ao carregar, são parcialmente renderizados ou se comportam inesperadamente quando a Inspeção TLS está habilitada.

Expectativa Comportamental:

  • Páginas podem parar, carregar indefinidamente ou renderizar parcialmente
  • Fluxos de login/autenticação podem falhar ou entrar em loop
  • Alguns sites podem parecer lentos devido à sobrecarga de descriptografia/reencriptação TLS
  • O comportamento pode ser inconsistente (por exemplo, funciona em uma rede, falha via Cato)

Isso é tipicamente observado com aplicativos web modernos usando controles de segurança rigorosos ou dependências complexas de TLS.

Resolução:
Validar ignorando a Inspeção TLS para um usuário específico ou IP de origem. Se o site funcionar quando ignorado, crie uma exclusão de domínio/FQDN direcionada.

Evite regras de ignorância amplas — limite as exclusões somente aos domínios necessários.

Se a aplicação depender de mecanismos de segurança estritos (por exemplo, certificados fixados ou tratamento avançado de TLS), a inspeção pode não ser suportada, e ignorar é a abordagem correta.

Cenário – Aplicações Web Modernas (SaaS):
Algumas plataformas SaaS (por exemplo, aplicativos com múltiplos domínios backend/CDNs) podem carregar parcialmente (IU funciona, APIs falham). Nestes casos, identifique todos os domínios obrigatórios via HAR/DevTools e garanta cobertura completa na regra de ignorância.

Solucionando Erros de Validação de Certificado Cato

Problema: Erros relacionados ao TLS do Cato aparecem durante navegação ou uso de aplicação.

Expectativa Comportamental:

Os usuários podem encontrar erros genéricos como: 

  • “Conexão segura falhou”
  • “Certificado não confiável”
  • Redefinições inesperadas de conexão ou quedas

Esses erros normalmente são inespecíficos e não indicam claramente se o problema se origina do cliente, servidor ou processo de Inspeção TLS.

Resolução:
Validar o comportamento ignorando temporariamente a Inspeção TLS para um único usuário ou IP de origem.

  • Se o problema for resolvido quando ignorado, isto confirma uma falha de validação de certificado durante a inspeção
  • Em casos onde CAs intermediárias ou emissoras não são reconhecidas, isso pode ser devido ao certificado ainda não estar incluído no pacote de certificados confiáveis do Cato.

Como solução temporária, é recomendado ignorar a Inspeção TLS para o domínio/aplicação afetado enquanto abre um caso de suporte.

Cato atualiza continuamente seu pacote de certificados confiáveis em linha com os padrões da indústria e as autoridades certificadoras mais usadas. Se o certificado for válido e amplamente confiável, é provável que seja adicionado em uma atualização futura.

A remediação permanente deve focar em:

  • Garantir que o servidor apresente uma cadeia de certificados completa e válida
  • Usar certificados emitidos por CAs bem conhecidas e confiáveis

Se o servidor apresentar uma cadeia de certificados inválida ou incompleta, a Inspeção TLS bloqueará corretamente a conexão. A remediação deve ser realizada no lado do servidor, ou ignorar a Inspeção TLS se necessário.

Novamente Confiáveis / Domínios Recém-Publicados

Domínios que são recém-publicados, recentemente atualizados ou reclassificados na internet podem ainda não ser consistentemente reconhecidos por todos os motores de reputação, autoridades certificadoras ou lojas de confiança.

Isso pode levar a cenários onde o tráfego é bloqueado ou sinalizado — não devido a uma falha de TLS apenas, mas como resultado da aplicação de segurança por políticas de firewall da Internet ou confiança incompleta no certificado.

Expectativa Comportamental:
Esses domínios podem:

  • Ser mal classificados ou categorizados de maneira inconsistente em motores de segurança
  • Apresentar certificados que não são totalmente propagados ou confiáveis globalmente
  • Disparar erros de TLS durante a inspeção devido a cadeias de confiança incompletas
  • Ser bloqueados com base em política, ao invés de um problema real de conectividade

Este comportamento é comum logo após um domínio se tornar ativo ou passar por alterações.

Resolução:

  • Valide o certificado diretamente do endpoint para confirmar a legitimidade
  • Se o domínio for verificado como seguro:
    • Re-categorize-o para uma categoria permitida com base nos requisitos da política, ou
    • Crie uma regra de permitir/ignorar direcionada (evite exclusões amplas)
  • Trate regras de ignorância como temporárias sempre que possível
  • Reavalie o domínio após algum tempo, uma vez que sua reputação e confiança no certificado sejam totalmente estabelecidas globalmente

Nota-Chave:
Mesmo se um domínio for legítimo, a propagação incompleta do certificado ainda pode causar erros relacionados ao TLS. Nesses casos, o comportamento é esperado e deve ser tratado através de ajustes de política controlados em vez de assumir uma configuração incorreta.

Cenário – Cadeia de Certificados Incompleta:
Um site pode funcionar diretamente em um navegador (devido a intermediários em cache) mas falhar na Inspeção TLS. Isso indica que o servidor não está apresentando a cadeia completa de certificados. A resolução é corrigir a configuração do servidor ou ignorar o domínio.

Protocolos Não Suportados e Sistemas Legados

Problema:
Conexões falham para aplicações ou sistemas usando versões de TLS desatualizadas ou suites de cifra fracas que não são suportadas sob Inspeção TLS.

Expectativa Comportamental:
Falhas tipicamente ocorrem durante o handshake TLS e são visíveis diretamente no navegador ou cliente.

Erros comuns de navegador incluem:

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Bad Request
Nenhum certificado SSL necessário foi enviado

Em alguns casos:

  • A página pode falhar totalmente ao carregar
  • A conexão pode ser redefinida imediatamente
  • Clientes robustos ou apps legadas podem falhar silenciosamente ou mostrar erros de conexão genéricos

Isso acontece porque o cliente ou servidor não pode negociar uma versão de TLS ou suite de cifra compatível com o Cato PoP agindo como MITM.

Nos eventos, você também notará o campo de Descrição de Erro TLS preenchido com informações específicas 

Para mais informações sobre os erros visite Entendendo erros TLS 

Resolução:

  • Ignore temporariamente a Inspeção TLS para um usuário específico ou IP de origem para validar comportamento
  • Se a aplicação funcionar quando ignorada → confirma um desajuste na negociação TLS durante a inspeção

Em seguida, valide as capacidades do TLS usando ferramentas externas como https://www.ssllabs.com/ssltest/

Compare resultados com sua política de Inspeção TLS:

  • Versão mínima permitida do TLS
  • Nível de aplicação da suite de cifra

Se confirmado:

  • Atualize ou faça upgrade da aplicação ou servidor para suportar versões modernas de TLS e suites de cifra fortes
  • Se upgrades não forem viáveis, configure uma ignorância de Inspeção TLS direcionada para a aplicação ou domínio afetado

Nota:
Por padrão, Cato permite uma ampla gama de versões de TLS e suites de cifra. No entanto, os administradores podem impor controles mais rigorosos na política de Inspeção TLS (por exemplo, versão mínima de TLS ou força de cifra), o que pode fazer com que aplicações legadas falhem. Para mais informações leia aqui

 

Cenário – Aplicação Interna Legada:
Uma aplicação interna ou de terceiro legada pode falhar apenas quando roteada via Cato com Inspeção TLS habilitada, mas funcionar quando ignorada. Isso normalmente indica dependência de versões de TLS obsoletas, exigindo atualização da aplicação ou ignorância permanente.

Solucionando Problemas de TLS Específicos do SO (Limitações Esperadas)

Problema: Problemas de conectividade, comportamento inconsistente ou falta de visibilidade de Inspeção TLS em certos sistemas operacionais e tipos de dispositivos (por exemplo, mobile, BYOD, Linux).

Expectativa Comportamental:

O comportamento varia significativamente dependendo do sistema operacional e design da aplicação.

Para dispositivos Android e Linux, a Inspeção TLS é ignorada por padrão devido a limitações de confiança no certificado e comportamento da aplicação. No entanto, configurações recentes (via Configurações Avançadas no CMA) permitem que os administradores imponham a Inspeção TLS nessas plataformas, desde que a confiança no certificado possa ser devidamente estabelecida.

Para dispositivos iOS, a Inspeção TLS é suportada, mas vários aplicativos (por exemplo, plataformas de mídia social como Instagram, Facebook e aplicativos similares) são ignorados por padrão devido a fixação de certificados e incompatibilidades conhecidas. Outros aplicativos que impõem validação estrita podem falhar e exigir configuração de ignorância manual.

Em geral:

  • Navegadores podem funcionar conforme esperado uma vez que o certificado Cato é instalado
  • Aplicativos nativos/móveis podem falhar imediatamente devido a fixação de certificados ou lojas de confiança restritas
  • O comportamento pode diferir por aplicação, mesmo no mesmo dispositivo

Resolução:

Esses comportamentos geralmente são esperados e impulsionados pela plataforma, não indicativos de configuração incorreta.

  • Aplique Inspeção TLS principalmente a dispositivos gerenciados onde o deploy do certificado é controlado
  • Use soluções MDM para instalar o certificado Cato em nível de sistema (onde suportado)
  • Esteja ciente das regras de ignorância padrão para aplicativos e plataformas bem conhecidos
  • Para aplicativos que falham devido à fixação de certificados ou validação estrita, configure uma ignorância de Inspeção TLS direcionada
  • Ao impor Inspeção TLS em plataformas como Android ou Linux, valide a compatibilidade cuidadosamente antes de amplos rollouts

Cenário – Falha de Aplicativo Móvel:
Um aplicativo móvel (por exemplo, aplicativo bancário ou de segurança) falha ao conectar sobre Cato enquanto o navegador funciona. O aplicativo impõe fixação de certificados e não confia no certificado Cato. Isso é esperado — a ação correta é ignorar a Inspeção TLS para aquele aplicativo ou serviço.

Levantando casos para Suporte Cato

Caso a inspeção TLS seja obrigatória para uma aplicação devido a razões de conformidade ou regulatórias ou caso você acredite que o bloqueio TLS seja inesperado, por favor, envie um ticket de suporte com os resultados dos passos de solução de problemas acima. Por favor, inclua as seguintes informações no ticket:

  • Detalhes do problema experimentado e impacto geral nos usuários. Timestamp/Fuso horário do usuário que está vivenciando o problema. 
  • Eventos relacionados e configuração de Regras de Firewall/TLS.
  • Reproduza o problema e execute o Suporte Auto-Serviço. Inclua o número do ticket gerado pela ferramenta.

 

Esse artigo foi útil?

Usuários que acharam isso útil: 0 de 0

0 comentário