An HTTPS-protected site that won't load through the WAF, or that works fine over HTTP but breaks the moment TLS is turned on, almost always fails somewhere inside the SSL/TLS handshake. This is the check order that finds which side of the handshake is actually failing — protocol version, cipher suite, certificate chain, or client authentication — and the field cases behind each one.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
HTTPS site faults on a WAF look mysterious until you notice they only ever come from three places.
A protected site that's unreachable over HTTPS splits into three categories almost every time: a configuration problem (decryption isn't even turned on, or the wrong certificate file went into the wrong slot), an SSL protocol/algorithm problem (the client and the WAF can't agree on a protocol version or cipher suite), or a certificate problem (the uploaded public key, private key or chain doesn't actually match what the server presents). Sorting the symptom into one of these three buckets first saves most of the back-and-forth.
What follows is the check order for each bucket, the packet-capture and OpenSSL commands that show you exactly where in the handshake it's failing, the gotchas that account for most of these tickets, and 5 FAQ answers pulled from real deployments.
The WAF sits in the middle of two independent TLS negotiations — client-to-WAF and WAF-to-server — and the fault almost never lives in both at once.
Placing the failure on this map first tells you whether to keep reading configuration, or move straight to a packet capture.
Diagram labels are kept in English for engineering clarity.
Once you know the site is failing during SSL negotiation rather than after it, the boxes on the left — decryption not configured, protocol version, cipher suite, certificate/key mismatch — cover almost everything that's actually wrong. The two on the right are what a negotiation-level fault looks like from the outside, or a structural limitation rather than a misconfiguration at all.
Configuration, protocol negotiation, and certificates each leave a different signature — here's where to look for each one, and the exact commands.
Before anything else, confirm the protected site is actually set up to terminate TLS at all.
$ 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" slotIf configuration is fine, capture the Client Hello and compare it against what the WAF will accept.
$ 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 acceptsThe handshake gets past the version and cipher stage but still fails around the Certificate message — the private key and chain almost never fail to match by accident.
$ 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 certificateOnce the buckets above have told you where the problem sits, these five account for most of what's actually wrong.
SYMPTOMThe handshake fails before any certificate is exchanged — the connection resets the instant TLS negotiation starts.
CAUSEThe WAF only accepts TLS 1.1 and TLS 1.2 by default. A client — or an old integration, scanner, or legacy load-balancer health check — that only offers SSLv2, SSLv3 or TLS 1.0 is rejected at the protocol-version step, before certificates are even relevant.
FIXCapture the Client Hello to confirm the version actually offered. If the client genuinely can't be upgraded, escalate to engineering to evaluate enabling an older protocol version deliberately, understanding that doing so lowers the security floor for every other site sharing that WAF's terminated TLS stack.
SYMPTOMThe TLS version matches, but the handshake still fails right after the Client Hello.
CAUSEThe client offers only weak or legacy cipher suites (RC4, 3DES, non-PFS suites) that the WAF's default cipher policy rejects. If none of the client's offered suites appear in the WAF's accepted list, there's no cipher suite both sides can actually agree on.
FIXRead the exact cipher list from the Client Hello capture, then loosen the WAF's accepted cipher suite in its web console just enough to create an overlap — treating this as a deliberate, documented trade-off against security, not a default setting.
SYMPTOMCertificate upload "succeeds" in the console, but HTTPS still fails, or the browser flags a certificate error.
CAUSEA public (leaf) certificate and a CA/intermediate certificate look interchangeable in a plain viewer, so the two get swapped — the slot that expects the site's own public key ends up holding the CA certificate instead, or vice versa.
FIXOpen the certificate and check its subject: a certificate with the site's own domain name in the subject line is the public/leaf key; a certificate with only a CA name and no site domain is the CA/intermediate, and belongs in the certificate-chain slot, not the public-key slot.
SYMPTOMNegotiation gets past the version/cipher stage, sometimes even appears to half-establish, but ultimately fails, or the browser flags a certificate mismatch.
CAUSEThe private key uploaded is left over from an earlier certificate renewal, a different domain, or a re-issued certificate that replaced the one the key was originally generated with — the two no longer form a valid key pair.
FIXHash the certificate's modulus and the private key's modulus and confirm they're identical. If they don't match, get the correct key and certificate re-issued together, rather than mixing an old key with a new certificate.
SYMPTOMEverything about the WAF-side configuration looks correct, yet a site behind mutual/two-way authentication (a Ukey or hardware token) still won't work once the WAF is in the path.
CAUSEThe WAF terminates the client's TLS session and re-establishes a separate TLS session to the server — it doesn't pass a client certificate through unmodified. A site that requires the server to directly verify the client's own certificate structurally can't be protected by a WAF in reverse-proxy or transparent-proxy mode.
FIXExclude that specific site from WAF HTTPS decryption/protection, or re-architect client authentication so mutual-auth verification happens in front of or independently from the WAF. This isn't a configuration fix — it's a scoping decision to make before deployment, not during an outage.
Pulled straight from the field — the ones worth having an answer ready for.
Check the "HTTPS/SSL Decryption" toggle in the protected site's configuration. If it's off, the WAF isn't terminating TLS for that site at all, and none of the protocol, cipher or certificate checks below apply until it is turned on.
Open the certificate file directly, or run openssl x509 -noout -subject: a certificate whose subject line carries the site's own domain name is the public/leaf key; a certificate whose subject line carries only a CA or organization name, with no site domain, is the CA/intermediate certificate — it belongs in the chain slot, not the public-key slot.
First confirm the HTTP path really has no other problem, then treat this as a pure SSL/TLS negotiation failure. In practice it narrows to the same four causes every time: an unsupported protocol version, a cipher suite with no overlap, an uploaded key or certificate that doesn't actually match the server, or a client that requires mutual (two-way) certificate authentication that the WAF's proxy model can't pass through.
A public-key certificate and its chain should be PEM/Base64, delimited by -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- blocks, with the chain ordered leaf-then-intermediate. A private key should similarly be an unencrypted PEM block (-----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----). A file left in DER/binary form, a passphrase-protected key, or a chain in the wrong order will each fail even when the underlying certificate itself is perfectly valid.
Capture traffic on the client-facing and server-facing interfaces separately — the WAF's own packet-capture tool, or tcpdump/Wireshark on each segment — and read the alert message. A failure that shows up on the client-facing capture but never reaches the server-facing one is a client-to-WAF negotiation failure; one that only shows up on the server-facing capture is a WAF-to-server negotiation problem instead.
This note is built around the Huawei WAF5000-series HTTPS protection fault model — protected-site configuration, SSL/TLS negotiation, certificate chain — and the field cases behind it. If your WAF is a different vendor or firmware version, the exact console paths and default protocol/cipher policy will vary, but the underlying negotiation logic — configuration, protocol/cipher overlap, certificate/key match, mutual-auth exclusion — carries over directly. It doesn't cover HTTP/3 (QUIC), certificate pinning, or firmware-specific TLS 1.3 support in depth.
Tell us which bucket it's failing in — decryption not enabled, protocol/cipher mismatch, or certificate mismatch — plus the Client Hello capture, and we'll help you read it.