TLS 1.3 Only Site Unable to be Proxied by CF?

I have a site setup with LetsEncrypt certs and all subdomains validate in FireFox (latest) when browsing to the page. However, if I try to proxy via CF to one of the subdomains I get an error between CF and the origin server.

Are there limitations on what the origin server can connect to? This is an NGINX server running TLS 1.3 only.


No, because I don’t want that. My question was around any limitations that with which the origin server can connect. Is CF not able to communicate over TLS 1.3 to the origin server?

I’m not concerned about clients that can’t connect to TLS 1.3. In this case TLS 1.3 only is a requirement. So my question still stands: are there limitations with CF proxying to the origin server if it is TLS 1.3 only?

Actually you haven’t. I’m asking what the CF proxy supports. I haven’t found a list of what versions and cipher suites are supported. Given CF’s very public push of supporting TLS 1.3 it seems very odd that this doesn’t work.

While I appreciate your response - it’s not a definitive answer. If you don’t have a definitive answer there’s no need for you to continue to respond.

So, you don’t know if TLS 1.3 is supported by the CF proxy? Because, that is my question. Again, I appreciate your original response, but it’s not the answer I’m looking for.

From the documentation, TLS 1.3 is supported to the origin using the standard TLS 1.3 ciphers.

Is this a production origin, or are you able to temporarily :grey: the entry, and use a tool like to test that your server looks OK. Or you could use a compatible version (i.e 1.1.1 or higher) of openssl to to do a test like:

echo | openssl s_client -connect your-origin-ip-address:443 -servername -tls1_3

Thank you for providing the link. It looks like it should be supported, but clearly there’s something else wrong. I still get an 525 error for SSL connection.

When I run the subdomain against SSL Labs test I get an A+ back (I’ve enabled TLS 1.2 temporarily and still get the same thing). I was getting an A back prior to enabling TLS 1.2 - but that’s because it was strictly set to TLS 1.3.

When running the openssl client command I get back a positive as well:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Regardless, very odd. I guess I’ll have to open a ticket.

I figured it out. It was the curve. CloudFlare doesn’t list the ECDH curves that are supported, apparently secp521r isn’t. I changed it to secp384r1 and the origin starts working. Would be nice if they listed that under the link provided above. I changed the site back to TLS 1.3 and it continues to work in this configuration.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.