HTTPS Inspection Troubleshooting Runbook por evidência (CA, QUIC, pinning, proxy e debug wstlsd)

WiliRGasparetto — Mon, 06 Apr 2026 21:09:22 GMT

HTTPS Inspection Troubleshooting Runbook por evidência (CA, QUIC, pinning, proxy e debug wstlsd)

Tese (como fechar RCA rápido)

Quando HTTPS Inspection “quebra”, não é um problema único. Em campo, quase sempre cai em um destes blocos:

Trust chain no endpoint (CA do gateway/CA interna não confiável)
Aplicação incompatível (certificate pinning, mTLS, requisitos específicos)
Transporte fora do esperado (QUIC/HTTP3 via UDP/443)
Interferência de rede (proxy explícito/autenticado, PAC, SSL inspection upstream)
Capacidade/handshake sob carga (CPU/crypto, picos, perfil agressivo)
Bypass inesperado (regra/objeto updatable/limitação) → “parece que não inspeciona”

Regra TAC: só mude configuração depois de coletar evidência mínima e isolar a variável (uma mudança por vez).

0) AVISOS TAC (impacto operacional e governança)

Antes de qualquer alteração (principalmente bypass e debug):

Faça backup do estado/configuração (e documente o baseline do que será alterado).
Execute em janela controlada, preferencialmente com console disponível.
Documente cada mudança (para facilitar rollback).
Se for cluster, planeje a coleta em todos os membros, porque a falha/handshake pode ocorrer em qualquer nó.

1) Fast triage em 10 minutos (sem debug)

1.1 Confirme enforcement no cliente (prova mais rápida)

No browser, abra um site HTTPS e verifique o certificado apresentado:

Issuer = CA do gateway / CA interna → outbound inspection está ativa
Issuer = CA pública do site → bypass/sem inspeção/escopo errado
Erro de certificado → problema de trust chain no endpoint

Boa prática TAC: teste em 2 browsers (Chrome/Edge e Firefox). Firefox pode usar store próprio dependendo do cenário.

1.2 Confirme trust da CA do gateway/CA interna

A CA do gateway deve estar confiável no endpoint:

Windows: Trusted Root Certification Authorities
macOS: Keychain (System)

Sinais típicos: NET::ERR_CERT_AUTHORITY_INVALID, alertas de chain, “connection not private”.

Evidência recomendada: screenshot do certificado (Issuer/Subject/Validity) e do erro.

2) Outbound vs Inbound (muita falha nasce aqui)

2.1 Outbound inspection

Requer a CA do gateway confiável no endpoint.
O gateway reassina certificados dinamicamente.

2.2 Inbound inspection (serviços publicados)

Requer que o certificado do servidor (e chave privada correspondente, quando aplicável ao método) esteja importado/associado corretamente no fluxo de certificados da inspeção (SmartConsole → HTTPS Inspection → Certificates, conforme modelo do seu ambiente).
Sintoma comum: serviço interno publicado “quebra” somente quando inbound inspection é habilitada.

3) QUIC ≠ Pinning (separe as causas)

3.1 QUIC/HTTP3 (transporte)

QUIC/HTTP3 usa UDP/443.
Pode causar comportamento diferente do TCP/443 e atrapalhar troubleshooting.

Teste TAC (isolamento):

Bloqueie UDP/443 temporariamente (força TCP/443) e compare:
- se “resolve”, você isolou QUIC como variável.
- se “não muda”, prossiga.

3.2 Certificate pinning (mecanismo do app)

O app valida um certificado/CA esperado e recusa a CA do gateway.
Sintoma: quebra consistente em domínios específicos (não “a internet inteira”).

Tratamento TAC:

Bypass por domínio (escopo mínimo + governança: owner/justificativa/review date).
Evite bypass global.

4) Nota crítica: proxy explícito/autenticado e SSL inspection upstream

Se há proxy explícito, proxy autenticado, PAC ou SSL inspection upstream, você pode ter:

reescrita de certificado (dupla inspeção → sintomas “parecidos com trust failure”)
loops de autenticação
timeouts e resets em pico
comportamento inconsistente por grupo/subnet (PAC)

TAC tip: compare o mesmo teste em:

rede corporativa (com proxy/PAC) vs hotspot/4G (sem proxy)

5) Tabela TAC de triagem rápida (Sintoma → Prova → Ação)

Sintoma	Causa provável	Como provar (evidência)	Ação recomendada
Erro de certificado no browser	CA do gateway não confiável	Issuer não confiável / screenshot	Distribuir CA via GPO/MDM; validar stores
“Não inspeciona” (Issuer público)	bypass/escopo/limitação	certificado visto no client + regra/objeto	revisar policy/ordem; procurar bypass inesperado
App/domínio específico quebra	pinning/mTLS/requisitos	falha sempre no mesmo domínio	bypass por domínio com governança
Intermitente (Chrome/Edge)	QUIC/HTTP3	bloqueia UDP/443 e compara	manter UDP/443 bloqueado ou tratar exceções
Lento após habilitar	CPU/crypto/handshake sob carga	cpview + correlação de horário	rollout gradual; tuning e capacidade
Funciona no 4G mas não na corp	proxy/PAC/SSL upstream	diferença de comportamento	ajustar proxy/SSL upstream, trust chain

6) Logs: onde olhar e como extrair evidência

6.1 Logs principais

$FWDIR/log/wstlsd.elg* (TLS handshake / inspeção)
/var/log/messages (daemon/system errors)
SmartLog/Logs no Management (eventos correlacionáveis)

6.2 Acompanhar em tempo real (útil durante reprodução)

tail -f $FWDIR/log/wstlsd.elg*

6.3 “Padrões” úteis para buscar no `wstlsd.elg*`

Sempre correlacione com o timestamp exato do teste.

Exemplos do que procurar (em termos práticos):

Handshake failure / negotiation mismatch (versão/cipher/protocolo)
Certificate validation failures (chain/trust/tempo/OCSP/CRL)
Timeouts / resets para destinos específicos (padrão de incompatibilidade)
Bypass inesperado (quando o tráfego não está sendo interceptado como esperado)

Importante: marque o horário do teste e filtre o log por janela (ex.: “últimos 5–10 minutos”) para reduzir ruído.

7) Debug avançado do `wstlsd` (quando você já isolou a camada)

Aviso TAC: alto volume de logs e impacto potencial. Faça em janela.

7.1 START (habilitar debug em todos os PIDs do wstlsd)

for PROC in $(pidof wstlsd); do fw debug $PROC on TDERROR_ALL_ALL=5; done

Reproduza o problema (anote URL + timestamp).

7.2 STOP (corrigido, completo)

for PROC in $(pidof wstlsd); do fw debug $PROC off TDERROR_ALL_ALL=0; done

7.3 Coleta mínima pós-debug

tail -n 2000 $FWDIR/log/wstlsd.elg* > /var/log/wstlsd_last2k.txt
tail -n 2000 /var/log/messages > /var/log/messages_last2k.txt

8) Boas práticas operacionais (o que evita incidentes)

Rollout gradual (pilot → waves) com KPIs: tickets, falhas, performance.
Governança de exceções: owner + justificativa + review date + registro em change control (planilha/sistema).
Mudança única por vez e documentação para rollback.
Auditar bypass periodicamente para detectar “exceções esquecidas”.
Em ambientes com proxy: documentar e validar cadeia completa e evitar dupla inspeção quando possível.

9) Template de coleta (para tópico CheckMates / TAC)

Versão gateway + Jumbo take
Browser(s) + versão (Chrome/Edge/Firefox)
URL(s) + timestamp exato
Sintoma (cert error / timeout / app quebra / lento / não inspeciona)
CA do gateway instalada? (sim/não)
Método de distribuição da CA: GPO / MDM / manual
Ambiente usa proxy/PAC/autenticação? (sim/não + detalhes)
QUIC testado? bloqueou UDP/443? (sim/não + resultado)
Logs: trecho de wstlsd.elg* na janela do teste + /var/log/messages

Referências oficiais (links diretos)

sk108202 — Best Practices — HTTPS Inspection
https://support.checkpoint.com/results/sk/sk108202
sk112066 — How to troubleshoot an HTTPS Inspection issue
https://support.checkpoint.com/results/sk/sk112066
sk111754 — QUIC/HTTP3 considerations with HTTPS Inspection (UDP/443)
https://support.checkpoint.com/results/sk/sk111754
sk163595 — Updatable object / bypass list (serviços com incompatibilidades/pinning)
https://support.checkpoint.com/results/sk/sk163595

topic HTTPS Inspection Troubleshooting Runbook por evidência (CA, QUIC, pinning, proxy e debug wstlsd) in Brazil

HTTPS Inspection Troubleshooting Runbook por evidência (CA, QUIC, pinning, proxy e debug wstlsd)