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.
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.
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: https://github.com/haproxy/haproxy/issues/1924).
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.
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
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. sonorancad.com - proxied and working ECH ws.sonorancad.com - 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… sonoransoftware.com - proxied and working with ECH cms.dev.sonoransoftware.com - DNS only as the CF cert cannot protect this nested subdomain and giving us the aforementioned error git.sonoran.software - also a CNAME to git.dev.sonoransoftware.com which effectively just creates a record to our development node is affected in DNS only mode
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.
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.