Cloudflare SSL proxy CNAME SNI issue

I am trying to setup a proxy to take advantage of the bandwidth alliance between Cloudflare and Oracle for their Object storage service. However, every time I try to access the service I get either “Resource not found” or a 526 error.

If I create a oraclestorage record in my DNS with a CNAME of objectstorage.us-ashburn-1.oraclecloud.com and then enable the SSL proxy, I get a 526 error with Full (Strict) on or “Resource not found” when using Full. If I disable the cloudflare proxy I get the SSL cert for a different oracle domain, specifically “swiftobjectstorage.us-ashburn-1.oraclecloud.com”. If I create an additional record in DNS to have a CNAME of “swiftobjectstorage.us-ashburn-1.oraclecloud.com” the 526 error goes away, likely because that is the default certificate returned by Oracle matches this hostname but none of the requests to that API return anything other than “Resource not found”. My guess is the SNI hostname is missing so it is not routed to the correct services internally on the Oracle side.

I ran dig for both domains and both appear to resolve to the same set of IPs, so it appears they are using SNI to differentiate which service is being accessed. I also used openssl s_client directly connect to one of those IP’s and I was returned the cert for “swiftobjectstorage.us-ashburn-1.oraclecloud.com” when I did not include the “-servername” flag for “objectstorage.us-ashburn-1.oraclecloud.com” and I was returned the correct cert when I did.

Does Cloudflare the SSL proxy not pass the CNAME being proxied as the servername for SNI to the origin server? My only other guess is since “objectstorage.us-ashburn-1.oraclecloud.com” is a CNAME pointing to “objectstorage.us-ashburn-1.oci.oraclecloud.com” that somehow the CNAME resolution breaks SNI? Is this just not a supported access pattern or is my configuration somehow wrong?

Absolutely correct. A CNAME is the only exception where the server’s certificate does not need to match the original hostname.

And yes, Cloudflare will not rewrite the request to change the hostname. The request will still contain the original hostname, but that’s not any different from any regular CNAME record. Just because you have a CNAME record does not mean the request will change. The rule of thumb is, if your site loads fine when unproxied, it will do so too when you proxy it. The same goes the other way round, if you have issues loading the site directly, the proxy will have issues as well.

To fix your particular use case I’d first pause Cloudflare (Overview screen, bottom right) and make sure Oracle is properly configured for your domain, along with a proper certificate for your domain name or - at least - serves the your domain’s content content on either of the two oraclecloud.com hostnames. Once that works, you should also be able to unpause Cloudflare, as requests should always validate, because of the valid certificate, either for your own domain or for the hostname configured for the CNAME record.

Couple things, first being this is the Oracle API domains so I have zero control over the configuration or how they respond. Second, the SSL validation from the Cloudflare side is really the last of my problems, I can lower to full from full (strict) and past that. The real problem is it appears that the reverse proxy on Oracle’s API side uses SNI to differentiate between what API domain you are calling since multiple seem to use the same IPs, and without that it is unable to route you to the correct API and thus the “Resource not found” response. I assumed that when proxing that Cloudflare would be including the SNI hostname of the proxied domain from the CNAME record in their requests to it. If someone knows for sure this is not the case or can point me to some documentation around this that would be helpful. I have been unable to find a definitive answer in my searching but maybe I’ve just been searching the wrong terms.

As for if I unproxy, I still have the same problem since the SNI hostname will be for my domain and not the CNAME hostname it points to. I just tested this to be sure and got the same “Resource not Found” error. This gives me more confidence that this is the true root of the issue when the Cloudflare proxy is active.

Then you need to clarify this with Oracle, they need to properly respond first for your site. And yes, SSL validation should be of your concern, otherwise your site will still be insecure.

As I already wrote, the proper approach to fix your issue is following these suggestions.

The SSL validation is also tied to the SNI issue. If I create a CNAME for the Oracle API domain name associated with the default SSL cert returned if no SNI provided when connecting to that IP(or for a hostname not recognized), I do not get SSL validation errors from Cloudflare. If I connect to the service directly with a SNI hostname I do get the correct certificate returned for the hostname in SNI.

I think there is some confusion here, these are the Oracle ObjectStorage API hostnames, not domains for services or sites I host or are hosted for me by Oracle. What I am trying to do is very similar to the technique used to get Backblaze B2 storage to be zero rated under the bandwidth alliance which supposedly is supported by Oracle for Object Storage as well.

If the answer is the CloudFlare SSL proxy only uses the SNI hostname from the incoming request or doesn’t include it at all on requests to the proxied origin server, I guess I’m stuck and I’ll have to look for other solutions.

$ dig @1.1.1.1 objectstorage.us-ashburn-1.oraclecloud.com
...
;; QUESTION SECTION:
;objectstorage.us-ashburn-1.oraclecloud.com. IN A

;; ANSWER SECTION:
objectstorage.us-ashburn-1.oraclecloud.com. 60 IN CNAME	objectstorage.us-ashburn-1.oci.oraclecloud.com.
objectstorage.us-ashburn-1.oci.oraclecloud.com.	60 IN A	134.70.32.1
objectstorage.us-ashburn-1.oci.oraclecloud.com.	60 IN A	134.70.24.1
objectstorage.us-ashburn-1.oci.oraclecloud.com.	60 IN A	134.70.28.1

Without SNI, direct SSL connection to Oracle IP. Note the domain in the CN, this is the default cert I referenced above.

$ openssl s_client -connect 134.70.32.1:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = Redwood City, O = Oracle Corporation, CN = swiftobjectstorage.us-ashburn-1.oraclecloud.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=swiftobjectstorage.us-ashburn-1.oraclecloud.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2

WIth SNI, direct SSL connection to Oracle IP. Note that on this request the CN of the cert matches the SNI hostname. This is the connection I assumed the CloudFlare proxy would be making when proxying a CNAME record. This assumption might be wrong. If it only includes the original domain name from the request without rewriting thats understandable, I just didn’t see that in documentation anywhere and wouldn’t have expected that from a reverse proxy.

$ openssl s_client -connect 134.70.32.1:443 -servername objectstorage.us-ashburn-1.oraclecloud.com
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = Redwood City, O = Oracle Corporation, CN = objectstorage.us-ashburn-1.oraclecloud.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=objectstorage.us-ashburn-1.oraclecloud.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2

Yes, that’s exactly what I addressed in my first response.

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