ERR_ECH_FALLBACK_CERTIFICATE_INVALID with subdomain

Website, Application, Performance Security
1

What is the name of the domain?

What is the error number?

ERR_ECH_FALLBACK_CERTIFICATE_INVALID

What is the error message?

ERR_ECH_FALLBACK_CERTIFICATE_INVALID

What is the issue you’re encountering

Downloading something goes to upload DOT hiveworkshop DOT com and people get an error. I must use sub domain not-proxied for uploads to the site as they’re bigger than 100 MB.

What steps have you taken to resolve the issue?

Disabling QUIC, disabling TLS 1.3 (as suggested in other threads) but no dice. Still 24 hours later people are reporting errors when attempting to start downloads.

Was the site working with SSL prior to adding it to Cloudflare?

Yes

What is the current SSL/TLS setting?

Full

What are the steps to reproduce the issue?

Click Maps, click Download on anything, get error screen.

Screenshot of the error

image.png

2

It does not happen for everyone though. It’s 1-2 reports per day of 100s.

3

As the subdomain is not proxied and is set to “DNS only”, requests are not passing through Cloudflare so any problem is coming from your origin server.

4

Not so fast. I am getting the exact same problem as this:

Except it’s long ago and disabling TLS 1.3 did not work.

The certificate for the subdomain is not invalid, check for yourself. From what I understand, the problem stems from higher security on the root domain and then lower (still HTTPS) on the subdomain.

5

Here is someone else with this exact problem:

6

I don’t know a ton about this, but I see CF is giving my subdomain an ech thing in dig:

root@localhost:~# dig +short https upload.hiveworkshop.com
1 . alpn="h3,h2" ipv4hint=95.217.146.41 ech=AEX+DQBBggAgACBXw8l9AXjPoyTZnJZRkVPwX0X1tUfzxFsxtfs2P/iEegAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=

root@localhost:~# dig +short https www.hiveworkshop.com
1 . alpn="h3,h2" ipv4hint=104.21.24.123,172.67.218.199 ech=AEX+DQBBggAgACBXw8l9AXjPoyTZnJZRkVPwX0X1tUfzxFsxtfs2P/iEegAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3035::6815:187b,2606:4700:3037::ac43:dac7
7

I can see you have set the domain to max TLSv1.2, but www still supports TLSv1.3 so I assume you’ve set TLSv1.2 using a Page Rule or Configuration rule?

If so, can you try disabling TLSv1.3 globally on this page…
https://dash.cloudflare.com/?to=/:account/:zone/ssl-tls/edge-certificates

Otherwise it probably needs looking at by Cloudflare.

8

I have already tried disabling TLS v1.3 but the problem remained.

After looking more at the latest link from the haproxy ticket I found the following:

In my configuration I have proxy enabled for hiveworkshop.com, www.hiveworkshop.com but disabled for upload.hiveworkshop.com.

When I do dig I get this:

# dig +short https hiveworkshop.com
1 . alpn="h3,h2" ipv4hint=104.21.24.123,172.67.218.199 ech=AEX+DQBB1QAgACCCe94ieZ7pFhg+8SQKfPYVTiwfqsDTLoUpA9DxUQ+rUgAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3035::6815:187b,2606:4700:3037::ac43:dac7

# dig +short https www.hiveworkshop.com
1 . alpn="h3,h2" ipv4hint=104.21.24.123,172.67.218.199 ech=AEX+DQBBggAgACBXw8l9AXjPoyTZnJZRkVPwX0X1tUfzxFsxtfs2P/iEegAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3035::6815:187b,2606:4700:3037::ac43:dac7

# dig +short https upload.hiveworkshop.com
1 . alpn="h3,h2" ipv4hint=95.217.146.41 ech=AEX+DQBBggAgACBXw8l9AXjPoyTZnJZRkVPwX0X1tUfzxFsxtfs2P/iEegAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=

The ech=AEX... for the unproxied upload.hiveworkshop.com is wrong because it is not proxied and I don’t have ECH on my nginx server.

NOW. Someone in the ticket said:

Most likely they do it on @ if it is set to proxy mode, and then it applies to subdomains? Because on a zone of mine I do indeed not see it yet. Tho rte.ie might be on a non-free CF plan and they’re delaying the rollout for those. idk.

So I disabled proxy on hiveworkshop.com but kept it on for www.hiveworkshop.com.

Now the ech= disappeared from upload.hiveworkshop.com.

I think this is what I want. But I also think it might be a mistake on CF’s part to enable ech= on subdomains that are not proxied.

I will run with this for a while to see if that solves the issues I am having.

9

Thanks @user3138 - We are going to rollback ECH. I think you have identified a corner case.

The HTTPS record SHOULD NOT be returned for the upload domain.

I assume you are gray clouding upload. to an Orange Clouded root domain hiveworkshop . com My quick hunch is CNAME flattening is causing this issue. We will investigate with the DNS team to fix. The ECH record should only be returned for proxied records.

The TLS 1.3 disable button would fix this as well, but we will investigate the root cause so will back this out.

Thanks for reporting and apologies.

Matt

4 Likes
10

Wow thank you for the response!

11

No problem at all and apologies again.

Matt

12

That’s exactly it.

Thank you.

13

Adding to this in case anyone else is having this problem.

I was having the exact same symptoms (requests randomly failing, although most would work) and I found that disabling TLS 1.3 worked for me.

My web app sends API calls to a subdomain that is not proxied via Cloudflare, although the DNS is hosted on Cloudflare.

The specific troubleshooting steps I took were:

  1. Chrome developer tools showed error: ERR_QUIC_PROTOCOL_ERROR.QUIC_NETWORK_IDLE_TIMEOUT
  2. Disabled Experimental QUIC protocol via chrome://flags/#enable-quic
  3. Re-tried request, which showed error: ERR_ECH_FALLBACK_CERTIFICATE_INVALID
  4. Disabled TLS 1.3 via Cloudflare SSL/TLS settings
  5. Tried again around 12 hours later.

I don’t seem to be getting any further errors, but I will update this post if I do.

14

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