Getting ECH fallback certificate error

I have a server on AWS EC2 with AWS issued SSL Certificate and using Cloudflare proxy with SSL set to Full Strict.

AWS Certificate is set on the load balancer and it is valid.

Some of our users report getting randomly ERR_ECH_FALLBACK_CERTIFICATE_INVALID whether it is in incognito mode or not. We are not able to reproduce it on our machines.

Is there a way to disable ECH on Cloudflare to rule this out?


Having the same problem with one of our sites using Full SSL (not strict). From my testing, it shows up in Chrome mobile on an android phone, but not on my desktop Chrome, guessing it’s due to version changes and how they’re handling ECH differently.

Temporarily pausing cloudflare on this site (bypassing and using the original server IP address) seems to resolve the issue as a workaround, but is obviously not a permanent fix.

I see that ECH just started getting rolled out by Cloudflare over the last week, so I would also like an option to disable and opt-in later once the bugs have been worked out with Chrome’s handling of ECH or whatever is going on.

1 Like

I have the same problem using Chrome on my Android tablet accessing my own website today. Cleared cache and browsing data but no change.Works ok with the same Chrome version on my mobile and also on the windows pc.Tried Cloudflare in development mode and made no difference.
Would be good to be able to switch ECH off until this is fixed.

1 Like

For folks having issues, if you enable ECH in chrome://flags search for ECH or hello. Does that help?

1 Like

We are running into a similar issue.

We run Cloudflare DNS and proxy most of our production traffic and all development traffic is DNS-only. All traffic goes to our local instances of HAProxy which to my knowledge doesn’t have ECH support yet, but I don’t think this matters from what others have mentioned (reference:

On proxied subdomains we are having no issue it seems and we run in FULL SSL mode meaning both our client connection is HTTPS and the Cloudflare Proxy uses HTTPS to our server (HAProxy).

On DNS-only subdomains we are getting the “ERR_ECH_FALLBACK_CERTIFICATE_INVALID” error in updated Chrome browsers. I have verified our letsencrypt certs are all valid and web browsers that do not yet support ECH work without issue. In our discussion on that github HAProxy issue others suggested this might be an issue with Cloudflare’s ECH implementation.

That indeed solves the problem for affected websites. Disabling ECH in the CF dashboard also fixes the problem.

1 Like

Can I ask whether you have created these subdomains explicitly or by creating a Wildcard record?
I’ve noticed that as soon as the apex domain is proxied, Cloudflare publishes HTTPS records (which contain the ECH information) for my wildcard DNS-only records, but not for explicitly created DNS-only records.

Edit: Ignore this. The target of my wildcard CNAME was the apex domain, so this is wrong. I should just go to bed after midnight :wink:


In one instance we CNAME the DNS-only subdomain to the parent domain which is proxied, effectively this just works as if we did an A record directly to our IP on DNS only. This was affected, until we tested disabling ECH at the website level in Cloudflare after purchasing a plan on that website. - proxied and working ECH - DNS only as WSS break sometimes when proxied by Cloudflare and giving us the aforementioned error

In another instance, we do have mostly wildcards for our development environment which is a subdomain of our company site… - proxied and working with ECH - DNS only as the CF cert cannot protect this nested subdomain and giving us the aforementioned error - also a CNAME to which effectively just creates a record to our development node is affected in DNS only mode

1 Like

I don’t see that option in the dashboard.

It’s not available in the Free Plan. To be able to disable ECH you need a paid plan.

Hi, In the free version, the option is activated by default and it’s impossible to change that… It’s scandalous to force a beta!
If you still want to work around this problem, you can disable TLS 1.3 while CF fixes this problem.


It looks like when the zone apex is CF proxied, all labels within that zone are erroneously ECH enabled, even if they are DNS-only.

If on the other hand the zone apex is DNS-only (or not existing at all), then the problem does not arise (even on free plans).

Great, this will buy people some time without paying.


Same issue here but Proxy it’s not enabled in my CF DNS entry.

SOLUTION: the DNS entry was a CNAME (without Proxy), pointing to a A entry (with Proxy enabled). Removing the Proxy in the A registry solved the issue.


Yeap that did it.

1 Like

How long does it take for the change to be effective? I disabled TLS 1.3 30 minutes ago (and purged the cache) but I still get the same error.

I believe there is a cache on the web browser that causes some headaches here, clearing browser cache/cookies may help via the chrome settings. Verifying via incognito should also show the current state regardless of cache causing issues on your regular browser windows.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.