SSL for SaaS with cloudfront fails SSL handshake

SSL for SaaS - custom domain fails SSL handshake with AWS CloudFront origin server

Hello,

We’re implementing vanity domains with SSL provisioning for our customers and have chosen SSL for SaaS. We’re using an AWS S3 bucket setup for static hosting and exposing it via cloudfront distribution. We can reach our application through the domains we configured on cloudflare without problem. However, when creating a custom hostname we end up with error 525 SSL handshake failed error page. (domain & certificate validation have been completed, CNAME in customer dns is created).

We’ve followed the steps in https://developers.cloudflare.com/ssl/ssl-for-saas

  1. We have added a flattened CNAME that points to our cloudfront distribution, it is a proxied record
  2. We have added a proxied CNAME pointing to the flattened one
  3. We have enabled custom hostnames
  4. We set the fallback origin to the flattened CNAME
  5. We created a custom hostname
  6. We completed domain & certificate verification with TXT records
  7. The customer added a CNAME of the custom domain to proxied CNAME we had setup

Some settings which may be relevant for this We are currently set to full SSL mode. Otherwise our normal CNAME configured domains will error out because of too many redirects.

We do not know how to proceed from this, have we overlooked a setting? Is it impossible to use flattened CNAMEs for this?

We found a similar problem to our own here: SSL for SaaS, but it was never resolved.

Any help or insight is very much appreciated.

1 Like

Did you also add the new domain as an “Alternate Domain Name (CNAME)” in your CloudFront distribution settings?

We only added the CNAME domains we configured in cloudflare to our alternate domains in cloudfront. Is it required to also add every new custom domain from the SSL for SaaS module as alternate domain as well?

Not tested, but I’m thinking that CloudFront is seeing the new custom domain in the HTTP Host header and can’t map that to any distribution.

That is what I’m afraid the issue is. In our own testing we temporarily set the SSL mode to flexible and we are able to reach our cloudfront distribution (returns a 403 since it doesn’t recognize the host domain, but it’s reachable).

I would have hoped we had missed some setting or something else, because this issue could become a blocker for us. If this is the case is there any way of doing something with that host header or something else on the cloudflare side? I don’t think AWS is very lenient with these things.

Enterprise plan only and not sure how it works with the SaaS product but:
https://support.cloudflare.com/hc/en-us/articles/206652947-Using-Page-Rules-to-Re-Write-Host-Headers

Alright, I’ll have to look this over with everyone as enterprise is a pretty far leap for us on a first time implementation with the service. We’ll also look into AWS as well for a possible solution.

Thanks for the quick responses and helping us reach a consensus on the problem! I’ll update this thread should we find relevant information in the next few days, after which I will close it by marking the host-rewrite as solution. Judging by the description it fits the exact use case.

Small update on our findings, enterprise is a no-go, we can’t justify the cost for this feature alone. Manipulating this header is also a no-go on the AWS side due to restrictions on edge functions. It appears that using a cloudflare worker as our origin which fetches the cloudfront content could work.

The worker subdomain is perfectly capable of reaching the content of the cloudfront distribution despite not being configured as alternate domain. The problem is, it is currently impossible to setup workers for a wildcard trigger (*/*) due to a confirmed bug, see posts How to properly set up a custom hostname with a worker? - #6 by domjh, SSL for Sass using Worker - #2 by user3988 and SSL for Sass using Worker - #4 by user3988

This wildcard issue also affects page rules it seems, meaning that even with host header rewriting on enterprise, we wouldn’t be able to create a trigger for it to activate on custom domains…

So for now we’ll have to make things work by setting up individual cloudfront distributions on the AWS side and possibly switch over once the worker issue is resolved.

3 Likes