Un sitio protegido por HTTPS que no carga a través del WAF, o que funciona bien por HTTP pero falla en cuanto se activa TLS, casi siempre falla en algún punto dentro del handshake SSL/TLS. Este es el orden de comprobación que encuentra en qué lado del handshake está fallando realmente — versión de protocolo, conjunto de cifrado, cadena de certificados o autenticación del cliente — y los casos de campo detrás de cada uno.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Las fallas de sitios HTTPS en un WAF parecen misteriosas hasta que se nota que solo provienen de tres lugares.
Un sitio protegido inalcanzable por HTTPS casi siempre se divide en tres categorías: un problema de configuración (el descifrado ni siquiera está activado, o el archivo de certificado equivocado se cargó en la ranura equivocada), un problema de protocolo/algoritmo SSL (el cliente y el WAF no logran acordar una versión de protocolo o un conjunto de cifrado), o un problema de certificado (la clave pública, la clave privada o la cadena cargada en realidad no coincide con lo que presenta el servidor). Clasificar primero el síntoma en una de estas tres categorías ahorra la mayor parte del ir y venir.
A continuación, el orden de comprobación para cada categoría, los comandos de captura de paquetes y OpenSSL que muestran exactamente dónde falla la negociación, los errores comunes que explican la mayoría de estos casos, y 5 respuestas de preguntas frecuentes extraídas de implementaciones reales.
El WAF se encuentra en medio de dos negociaciones TLS independientes — cliente-a-WAF y WAF-a-servidor — y la falla casi nunca está en ambas a la vez.
Ubicar primero la falla en este mapa indica si conviene seguir revisando la configuración o pasar directamente a una captura de paquetes.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Una vez que se sabe que el sitio falla durante la negociación SSL y no después, los recuadros de la izquierda — descifrado no configurado, versión de protocolo, conjunto de cifrado, incompatibilidad de certificado/clave — cubren casi todo lo que realmente está mal. Los dos de la derecha muestran cómo se ve una falla a nivel de negociación desde fuera, o una limitación estructural en lugar de un error de configuración.
La configuración, la negociación de protocolo y los certificados dejan cada uno una firma distinta — aquí está dónde buscar en cada caso, y los comandos exactos.
Antes que nada, confirme que el sitio protegido realmente esté configurado para terminar 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" slotSi la configuración está bien, capture el Client Hello y compárelo con lo que el WAF aceptará.
$ 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 acceptsEl handshake supera la etapa de versión y cifrado pero aún falla alrededor del mensaje Certificate — la clave privada y la cadena casi nunca dejan de coincidir por accidente.
$ 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 certificateUna vez que las categorías anteriores le han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla.
SÍNTOMAEl handshake falla antes de que se intercambie cualquier certificado — la conexión se reinicia en el instante en que comienza la negociación TLS.
CAUSAEl WAF solo acepta TLS 1.1 y TLS 1.2 de forma predeterminada. Un cliente — o una integración antigua, un escáner, una verificación de estado de balanceador de carga heredada — que solo ofrece SSLv2, SSLv3 o TLS 1.0 es rechazado en el paso de versión de protocolo, antes de que los certificados sean siquiera relevantes.
SOLUCIÓNCapture el Client Hello para confirmar la versión realmente ofrecida. Si el cliente realmente no se puede actualizar, escale a ingeniería para evaluar habilitar deliberadamente una versión de protocolo más antigua, entendiendo que hacerlo baja el piso de seguridad para todos los demás sitios que comparten la pila TLS terminada de ese WAF.
SÍNTOMALa versión TLS coincide, pero el handshake sigue fallando justo después del Client Hello.
CAUSAEl cliente solo ofrece conjuntos de cifrado débiles u obsoletos (RC4, 3DES, conjuntos sin PFS) que la política de cifrado predeterminada del WAF rechaza. Si ninguno de los conjuntos ofrecidos por el cliente aparece en la lista aceptada del WAF, no hay ningún conjunto de cifrado en el que ambas partes puedan realmente coincidir.
SOLUCIÓNLea la lista exacta de conjuntos desde la captura del Client Hello, luego relaje el conjunto de cifrado aceptado del WAF en su consola web justo lo suficiente para crear una superposición — tratando esto como una concesión deliberada y documentada contra la seguridad, no como una configuración predeterminada.
SÍNTOMALa carga del certificado «tiene éxito» en la consola, pero HTTPS sigue fallando, o el navegador marca un error de certificado.
CAUSAUn certificado público (de hoja) y un certificado de CA/intermedio parecen intercambiables en un visor común, por lo que se intercambian — la ranura que espera la propia clave pública del sitio termina con el certificado de CA en su lugar, o viceversa.
SOLUCIÓNAbra el certificado y revise su asunto: un certificado con el propio dominio del sitio en la línea de asunto es la clave pública/de hoja; un certificado con solo un nombre de CA y sin dominio del sitio es la CA/intermedio, y pertenece a la ranura de la cadena de certificados, no a la de la clave pública.
SÍNTOMALa negociación pasa la etapa de versión/cifrado, a veces incluso parece establecerse a medias, pero finalmente falla, o el navegador marca una discrepancia de certificado.
CAUSALa clave privada cargada es un resto de una renovación de certificado anterior, de un dominio diferente, o de un certificado reemitido que reemplazó a aquel con el que la clave se generó originalmente — los dos ya no forman un par de claves válido.
SOLUCIÓNCalcule el hash del módulo del certificado y del módulo de la clave privada y confirme que sean idénticos. Si no coinciden, haga reemitir juntos la clave y el certificado correctos, en lugar de mezclar una clave antigua con un certificado nuevo.
SÍNTOMATodo en la configuración del lado del WAF parece correcto, pero un sitio detrás de autenticación mutua/bidireccional (un Ukey o token de hardware) sigue sin funcionar una vez que el WAF está en la ruta.
CAUSAEl WAF termina la sesión TLS del cliente y restablece una sesión TLS separada hacia el servidor — no transmite el certificado del cliente sin modificar. Un sitio que requiere que el servidor verifique directamente el propio certificado del cliente estructuralmente no puede ser protegido por un WAF en modo de proxy inverso o proxy transparente.
SOLUCIÓNExcluya ese sitio específico del descifrado/protección HTTPS del WAF, o rediseñe la autenticación del cliente para que la verificación de autenticación mutua ocurra delante del WAF o de forma independiente de él. Esto no es una corrección de configuración — es una decisión de alcance que hay que tomar antes del despliegue, no durante una interrupción.
Extraídas directamente del campo — las que vale la pena tener una respuesta lista.
Verifique el interruptor «Descifrado HTTPS/SSL» en la configuración del sitio protegido. Si está desactivado, el WAF no está terminando TLS para ese sitio en absoluto, y ninguna de las comprobaciones de protocolo, cifrado o certificado siguientes aplica hasta que se active.
Abra el archivo de certificado directamente, o ejecute openssl x509 -noout -subject: un certificado cuya línea de asunto lleva el propio dominio del sitio es la clave pública/de hoja; un certificado cuya línea de asunto lleva solo un nombre de CA u organización, sin dominio del sitio, es el certificado de CA/intermedio — pertenece a la ranura de la cadena, no a la de la clave pública.
Primero confirme que la ruta HTTP realmente no tiene ningún otro problema, luego trate esto como una falla pura de negociación SSL/TLS. En la práctica, casi siempre se reduce a las mismas cuatro causas: una versión de protocolo no compatible, un conjunto de cifrado sin superposición, una clave o certificado cargado que en realidad no coincide con el servidor, o un cliente que requiere autenticación mutua (bidireccional) por certificado que el modelo de proxy del WAF no puede transmitir.
Un certificado de clave pública y su cadena deben estar en PEM/Base64, delimitados por bloques -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----, con la cadena ordenada de hoja a intermedio. Una clave privada debe ser igualmente un bloque PEM sin cifrar (-----BEGIN PRIVATE KEY----- o -----BEGIN RSA PRIVATE KEY-----). Un archivo dejado en forma DER/binaria, una clave protegida con frase de contraseña, o una cadena en el orden incorrecto fallarán cada uno incluso cuando el certificado subyacente en sí sea perfectamente válido.
Capture el tráfico por separado en las interfaces orientadas al cliente y al servidor — la propia herramienta de captura de paquetes del WAF, o tcpdump/Wireshark en cada segmento — y lea el mensaje de alerta. Una falla que aparece en la captura orientada al cliente pero nunca llega a la orientada al servidor es una falla de negociación cliente-a-WAF; una que solo aparece en la captura orientada al servidor es en cambio un problema de negociación WAF-a-servidor.
Esta nota se construye en torno al modelo de fallas de protección HTTPS de la serie Huawei WAF5000 — configuración del sitio protegido, negociación SSL/TLS, cadena de certificados — y los casos de campo detrás de ella. Si su WAF es de otro proveedor o versión de firmware, las rutas exactas de la consola y la política de protocolo/cifrado predeterminada variarán, pero la lógica de negociación subyacente — configuración, superposición de protocolo/cifrado, coincidencia de certificado/clave, exclusión de autenticación mutua — se traslada directamente. No cubre en profundidad HTTP/3 (QUIC), el anclaje de certificados, ni el soporte de TLS 1.3 específico del firmware.
Dígannos en qué categoría está fallando — descifrado no habilitado, incompatibilidad de protocolo/cifrado, o incompatibilidad de certificado — además de la captura del Client Hello, y le ayudaremos a interpretarla.