Um site protegido por HTTPS que não carrega através do WAF, ou que funciona bem por HTTP mas quebra assim que o TLS é ativado, quase sempre falha em algum ponto dentro do handshake SSL/TLS. Esta é a ordem de verificação que encontra em qual lado do handshake a falha realmente está — versão do protocolo, conjunto de cifras, cadeia de certificados ou autenticação do cliente — e os casos de campo por trás de cada um.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
As falhas de site HTTPS em um WAF parecem misteriosas até você perceber que elas só vêm de três lugares.
Um site protegido inacessível por HTTPS quase sempre se divide em três categorias: um problema de configuração (a descriptografia nem sequer está ativada, ou o arquivo de certificado errado foi para o slot errado), um problema de protocolo/algoritmo SSL (o cliente e o WAF não conseguem concordar em uma versão de protocolo ou conjunto de cifras), ou um problema de certificado (a chave pública, a chave privada ou a cadeia enviada na verdade não corresponde ao que o servidor apresenta). Classificar primeiro o sintoma em uma dessas três categorias economiza a maior parte da ida e volta.
A seguir está a ordem de verificação para cada categoria, os comandos de captura de pacotes e OpenSSL que mostram exatamente onde a negociação está falhando, as pegadinhas que respondem pela maioria desses chamados, e 5 respostas de perguntas frequentes tiradas de implantações reais.
O WAF fica no meio de duas negociações TLS independentes — cliente-para-WAF e WAF-para-servidor — e a falha quase nunca está nas duas ao mesmo tempo.
Colocar primeiro a falha neste mapa indica se você deve continuar lendo a configuração ou partir direto para uma captura de pacotes.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Depois de saber que o site está falhando durante a negociação SSL e não depois, as caixas da esquerda — descriptografia não configurada, versão do protocolo, conjunto de cifras, incompatibilidade de certificado/chave — cobrem quase tudo o que realmente está errado. As duas da direita mostram como uma falha no nível de negociação parece vista de fora, ou uma limitação estrutural, e não um erro de configuração.
Configuração, negociação de protocolo e certificados deixam cada um uma assinatura diferente — aqui está onde procurar em cada caso, e os comandos exatos.
Antes de mais nada, confirme se o site protegido realmente está configurado para terminar o TLS.
$ openssl x509 -in leaf.crt -noout -subject -issuer
subject=CN=www.example.com
issuer=CN=ExampleCA-Intermediate
// a CN with the site's own domain in "subject" -> this is the public/leaf certificate
$ openssl x509 -in maybe-ca.crt -noout -subject -issuer
subject=CN=ExampleCA-Intermediate, O=Example CA
issuer=CN=ExampleCA-Root
// subject carries only a CA/organization name, no site domain -> this is a CA/intermediate cert,
// it belongs in the certificate-chain slot, not the "public key" slotSe a configuração estiver correta, capture o Client Hello e compare com o que o WAF aceitará.
$ openssl s_client -connect waf-vip:443 -tls1
...
40736:error:...:tlsv1 alert protocol version:...
// the test only offered TLS1.0 -> the WAF's minimum accepted version is TLS1.1
$ openssl s_client -connect waf-vip:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
...
Cipher : ECDHE-RSA-AES128-GCM-SHA256
// re-run with the cipher list read from the real Client Hello capture to confirm
// which of the client's offered suites the WAF actually acceptsO handshake passa da etapa de versão e cifra, mas ainda falha perto da mensagem Certificate — a chave privada e a cadeia quase nunca deixam de corresponder por acidente.
$ openssl x509 -noout -modulus -in server.crt | openssl md5
(stdin)= 3f2504e04f8964ba649...
$ openssl rsa -noout -modulus -in server.key | openssl md5
(stdin)= 3f2504e04f8964ba649...
// the two hashes must match -- if they don't, this private key was not generated for this certificateDepois que as categorias acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMAO handshake falha antes de qualquer certificado ser trocado — a conexão é reiniciada no instante em que a negociação TLS começa.
CAUSAO WAF só aceita TLS 1.1 e TLS 1.2 por padrão. Um cliente — ou uma integração antiga, um scanner, uma verificação de saúde de balanceador de carga legado — que só oferece SSLv2, SSLv3 ou TLS 1.0 é rejeitado na etapa de versão do protocolo, antes mesmo de os certificados serem relevantes.
SOLUÇÃOCapture o Client Hello para confirmar a versão realmente oferecida. Se o cliente realmente não puder ser atualizado, escale para a engenharia avaliar habilitar deliberadamente uma versão de protocolo mais antiga, entendendo que isso reduz o piso de segurança para todos os outros sites que compartilham a pilha TLS terminada daquele WAF.
SINTOMAA versão TLS corresponde, mas o handshake ainda falha logo após o Client Hello.
CAUSAO cliente oferece apenas conjuntos de cifras fracos ou legados (RC4, 3DES, conjuntos sem PFS) que a política de cifras padrão do WAF rejeita. Se nenhum dos conjuntos oferecidos pelo cliente aparecer na lista aceita do WAF, não há nenhum conjunto de cifras em que os dois lados realmente possam concordar.
SOLUÇÃOLeia a lista exata de cifras a partir da captura do Client Hello, então afrouxe o conjunto de cifras aceito do WAF no console web apenas o suficiente para criar uma sobreposição — tratando isso como uma concessão deliberada e documentada contra a segurança, não como uma configuração padrão.
SINTOMAO upload do certificado «tem sucesso» no console, mas o HTTPS ainda falha, ou o navegador aponta um erro de certificado.
CAUSAUm certificado público (folha) e um certificado de CA/intermediário parecem intercambiáveis em um visualizador comum, então os dois são trocados — o slot que espera a própria chave pública do site acaba com o certificado de CA em vez disso, ou vice-versa.
SOLUÇÃOAbra o certificado e verifique o assunto: um certificado com o próprio domínio do site na linha de assunto é a chave pública/folha; um certificado com apenas um nome de CA e sem domínio do site é a CA/intermediária, e pertence ao slot da cadeia de certificados, não ao da chave pública.
SINTOMAA negociação passa da etapa de versão/cifra, às vezes até parece se estabelecer parcialmente, mas acaba falhando, ou o navegador aponta uma incompatibilidade de certificado.
CAUSAA chave privada enviada é uma sobra de uma renovação de certificado anterior, de um domínio diferente, ou de um certificado reemitido que substituiu aquele com o qual a chave foi originalmente gerada — os dois não formam mais um par de chaves válido.
SOLUÇÃOFaça o hash do módulo do certificado e do módulo da chave privada e confirme se são idênticos. Se não coincidirem, faça reemitir juntos a chave e o certificado corretos, em vez de misturar uma chave antiga com um certificado novo.
SINTOMATudo na configuração do lado do WAF parece correto, mas um site por trás de autenticação mútua/bidirecional (um Ukey ou token de hardware) ainda não funciona assim que o WAF entra no caminho.
CAUSAO WAF termina a sessão TLS do cliente e restabelece uma sessão TLS separada para o servidor — ele não repassa o certificado do cliente sem modificação. Um site que exige que o servidor verifique diretamente o próprio certificado do cliente estruturalmente não pode ser protegido por um WAF em modo de proxy reverso ou proxy transparente.
SOLUÇÃOExclua esse site específico da descriptografia/proteção HTTPS do WAF, ou reprojete a autenticação do cliente para que a verificação de autenticação mútua aconteça na frente do WAF ou de forma independente dele. Isso não é uma correção de configuração — é uma decisão de escopo a ser tomada antes da implantação, não durante uma interrupção.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Verifique o botão «Descriptografia HTTPS/SSL» na configuração do site protegido. Se estiver desligado, o WAF não está terminando o TLS para esse site, e nenhuma das verificações de protocolo, cifra ou certificado abaixo se aplica até que seja ligado.
Abra o arquivo de certificado diretamente, ou execute openssl x509 -noout -subject: um certificado cuja linha de assunto carrega o próprio domínio do site é a chave pública/folha; um certificado cuja linha de assunto carrega apenas um nome de CA ou organização, sem domínio do site, é o certificado de CA/intermediário — ele pertence ao slot da cadeia, não ao da chave pública.
Primeiro confirme que o caminho HTTP realmente não tem nenhum outro problema, depois trate isso como uma falha pura de negociação SSL/TLS. Na prática, quase sempre se reduz às mesmas quatro causas: uma versão de protocolo não suportada, um conjunto de cifras sem sobreposição, uma chave ou certificado enviado que na verdade não corresponde ao servidor, ou um cliente que exige autenticação mútua (bidirecional) por certificado que o modelo de proxy do WAF não consegue repassar.
Um certificado de chave pública e sua cadeia devem estar em PEM/Base64, delimitados por blocos -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----, com a cadeia ordenada folha-depois-intermediário. Uma chave privada deve ser igualmente um bloco PEM não criptografado (-----BEGIN PRIVATE KEY----- ou -----BEGIN RSA PRIVATE KEY-----). Um arquivo deixado em forma DER/binária, uma chave protegida por senha, ou uma cadeia na ordem errada, cada um falhará mesmo quando o certificado subjacente em si for perfeitamente válido.
Capture o tráfego separadamente nas interfaces voltadas ao cliente e ao servidor — a própria ferramenta de captura de pacotes do WAF, ou tcpdump/Wireshark em cada segmento — e leia a mensagem de alerta. Uma falha que aparece na captura voltada ao cliente mas nunca chega à voltada ao servidor é uma falha de negociação cliente-para-WAF; uma que só aparece na captura voltada ao servidor é, em vez disso, um problema de negociação WAF-para-servidor.
Esta nota é construída em torno do modelo de falhas de proteção HTTPS da série Huawei WAF5000 — configuração do site protegido, negociação SSL/TLS, cadeia de certificados — e os casos de campo por trás dela. Se o seu WAF for de outro fornecedor ou versão de firmware, os caminhos exatos do console e a política padrão de protocolo/cifra vão variar, mas a lógica de negociação subjacente — configuração, sobreposição de protocolo/cifra, correspondência de certificado/chave, exclusão de autenticação mútua — se aplica diretamente. Não cobre em profundidade HTTP/3 (QUIC), fixação de certificado, ou suporte a TLS 1.3 específico do firmware.
Diga-nos em qual categoria está falhando — descriptografia não habilitada, incompatibilidade de protocolo/cifra, ou incompatibilidade de certificado — além da captura do Client Hello, e ajudaremos você a interpretá-la.