How to Fix ERR_SSL_ECH_FAILED (Encrypted Client Hello) in Google Chrome and Cloudflare

With the global rollout of IETF RFC 9460 and RFC 9619, web browsers (Google Chrome, Chromium, and Mozilla Firefox) enabled Encrypted Client Hello (ECH) by default. Historically, even during an encrypted TLS 1.3 session, the initial ClientHello packet transmitted the Server Name Indication (SNI) in cleartext, enabling middleboxes, firewalls, and internet service providers across Pakistan (such as PTCL, Nayatel, and StormFiber) to monitor, log, and filter user web visits.

ECH solves this privacy gap by encrypting the inner SNI inside an outer dummy handshake using a public key retrieved from the domain’s DNS HTTPS Resource Record (Type 65).

However, when CDN edge networks (such as Cloudflare, Fastly, or custom edge proxies) rotate their ECH cryptographic keys while recursive DNS resolvers cache stale HTTPS records, or when middleboxes tamper with DNS-over-HTTPS (DoH) traffic, browsers abruptly terminate the connection with the critical error ERR_SSL_ECH_FAILED or SSL_ERROR_ENCRYPTED_CLIENT_HELLO_FAILED.

Hosting mission-critical web applications on high-performance Dedicated Servers in Pakistan and Dedicated Servers with synchronized DNS zone records eliminates cryptographic desynchronization and ensures seamless client connections.

---

How Encrypted Client Hello (ECH) Operates

To understand why ERR_SSL_ECH_FAILED occurs, trace the two-tier handshake architecture:

1. DNS HTTPS RR Lookup: Before sending a single packet to the web server, Chrome queries the authoritative nameservers for the domain’s Type 65 (HTTPS) record.
2. ECH Parameter Extraction: The DNS response returns an ech= parameter containing the CDN/server’s public key configuration and supported cipher suites (ECHConfigList).
3. Inner and Outer ClientHello: The browser generates two handshakes:
   • Outer ClientHello: Unencrypted, contains a harmless front-facing outer SNI (e.g., cloudflare-ech.com).
   • Inner ClientHello: Encrypted with the server’s public key, containing the real sensitive destination domain (yourdomain.com.pk).
4. Server Decryption: The edge server uses its private key to decrypt the Inner ClientHello and terminates the TLS session.

+---------------------------------------------------------------+
|               Google Chrome / Mozilla Firefox                 |
+-------------------------------+-------------------------------+
                                |
               1. DNS Query (HTTPS Record Type 65)
                                v
+---------------------------------------------------------------+
|                  Recursive DNS Resolver / DoH                 |
|             Returns cached ECHConfig: Key ID 0x4A             |
+-------------------------------+-------------------------------+
                                |
      2. Browser encrypts Inner ClientHello using Key 0x4A
                                |
                                v
+---------------------------------------------------------------+
|              Edge Server (Cloudflare / Web Server)            |
|              Active Key rotated to 0x4B!                      |
|                                                               |
|   Cannot decrypt ClientHello using stale Key 0x4A!            |
|   Server returns: ECH Retry Request or Drops Socket           |
+-------------------------------+-------------------------------+
                                |
                                v
+---------------------------------------------------------------+
|               ERROR: ERR_SSL_ECH_FAILED                       |
|          Secure handshake cannot be completed                 |
+---------------------------------------------------------------+

For webmasters troubleshooting related browser security exceptions, explore our diagnostic guides on How to Fix SEC_ERROR_CERT_ALTNAME_INVALID in Mozilla Firefox, How to Fix SEC_ERROR_UNTRUSTED_CERT in Mozilla Firefox, and How to Fix SSL_ERROR_BAD_CERT_DOMAIN in Mozilla Firefox.

---

Step 1: Diagnosing DNS HTTPS (Type 65) Records via dig

Query the authoritative nameservers for your domain using dig to inspect the published ECH parameters:

# Query HTTPS Resource Record (Type 65)
dig yourdomain.pk HTTPS +short

Sample output from an active ECH-enabled zone:

1 . alpn="h3,h2" ipv4hint=104.21.42.12 ipv6hint=2606:4700:3037::ac43:8212 ech=AEX+DQA6...

Inspect the ech= base64 payload:

• If ech= is present in DNS, but your web server or origin SSL certificate does not support ECH decryption, clients connecting with ECH will crash with ERR_SSL_ECH_FAILED.
• If the DNS TTL is set to 86400 (24 hours) while Cloudflare rotates keys every 4 hours, recursive resolvers across Pakistani ISPs (PTCL, Nayatel) will serve expired keys, breaking connections until caches expire.

---

Step 2: Server-Side Resolution in Cloudflare and CDN Dashboards

If your website is proxied through Cloudflare and users report ERR_SSL_ECH_FAILED:

1. Toggle ECH in Cloudflare Dashboard:

   • Log in to your Cloudflare dashboard.
   • Navigate to SSL/TLS >> Edge Certificates.
   • Scroll to Encrypted Client Hello (ECH).
   • If experiencing key rollover mismatches, toggle ECH Off, wait 5 minutes for Cloudflare’s edge nameservers to withdraw the ech= parameter from Type 65 records, and toggle it back On to publish fresh keys.

2. Reduce DNS TTL on HTTPS Records: Ensure DNS records for the root domain and www alias use Auto or a maximum TTL of 300 seconds so that any upstream key rotation propagates to ISP resolvers in under 5 minutes.

---

Step 3: Origin Server Configuration (Apache & Nginx Direct Hosting)

If you are hosting directly on an un-proxied dedicated server or VPS without Cloudflare, ensure your DNS zone does NOT publish an orphan HTTPS record.

If you previously used Cloudflare and switched your nameservers back to a cPanel/WHM host or BIND server:

# Search zone file for lingering HTTPS records
grep -i "HTTPS" /var/named/yourdomain.pk.db

If an obsolete record like:

yourdomain.pk.  300  IN  HTTPS  1 . alpn="h2" ech="AEX..."

persists in your local zone, delete the record immediately:

# Remove HTTPS record in cPanel Zone Editor or via CLI
whmapi1 dumpzone domain=yourdomain.pk
whmapi1 resetzone domain=yourdomain.pk

Reload BIND nameserver:

rndc reload yourdomain.pk

---

Step 4: Client-Side Workaround for Local Testing in Chrome & Firefox

For developers in Pakistan testing staging environments behind firewalls:

In Google Chrome:

1. Open Chrome and navigate to chrome://flags/#encrypted-client-hello.
2. Set Encrypted Client Hello to Disabled.
3. Relaunch Chrome.
4. Additionally, open chrome://net-internals/#dns and click Clear host cache.

In Mozilla Firefox:

1. Navigate to about:config.
2. Search for network.dns.echconfig.enabled and toggle to false.
3. Search for network.dns.use_https_rr_as_alpn and toggle to false.
4. Relaunch Firefox.

---

Step 5: Validating End-to-End Handshake with OpenSSL 3.2+

Verify that your website executes clean TLS handshakes using modern OpenSSL:

# Query TLS 1.3 handshake with SNI
openssl s_client -connect yourdomain.pk:443 -servername yourdomain.pk -tls1_3

Confirm that the output terminates cleanly with:

SSL handshake has read 3450 bytes and written 380 bytes
Verification: OK

Google Chrome and Mozilla Firefox will now load the website seamlessly with full cryptographic encryption and zero ECH protocol errors.

---