SSL Handshake issues with fetch

I have an issue that started yesterday, I’m now unable to connect to a specific end-point from within workers when doing a fetch request, but it works in dev and in the quick-edit.

The SSL handshake fails, but why would it only fail in the worker? My code is un-changed, the target hasn’t changed anything either. Is there a problem with handling SSL handshakes?

Any other @MVP that’s got any advice?

1 Like

Is the endpoint coincidentally hosted on Vercel? Believe they still reject a couple Cloudflare requests, which would result in a SSL handshake error

1 Like

No clue, it’s been running fine for about a year with no issues like this.

I even isolated the fetch request to it’s own worker and the problem persists.

So this is the new “Cloud wars” then, just rejecting requests from competitors?

The problem end-point is using Amazon AWS and their routing service, but we’re fetching from AWS all the time without 525 issues so why this one?

Anyone know what settings on AWS can cause 525 in this case?

The SSL certificate of the origin we fetch from has a perfect A+ on SSL Labs test, so that’s not it.

similar Fetch from AWS API Gateway fails from worker with Error 525 revealing the origin URL in error page ?

I’m aware, however, it is and has always been set to full, I tried strict too but no difference.

The issue is that the end-point switched to Cloudflare for their main domain, which caused routing issues for the sub-domains (which don’t use Cloudflare). But they’re still denying there’s an issue and don’t want to contact Cloudflare to fix it.

Edit: They are finally admitting the issue and fixing it… :slight_smile:


Glad to hear you found the issue!

Thanks for helping as always :wink:

Now I’ll always know how to check for this issue too.

1 Like

They are unable to fix it, their main domain isn’t assigned to Cloudflare, it’s assigned to AWS DNS.

Yet this still happens, what to do in cases like these @harris ?

If this is going to happen every time someone uses Cloudflare, then what’s the point of building using workers? It’s just going to fail and no one is going to fix it :smiley:

I’m very close to just moving to the new Deno Cloud (CF Worker alternative), where this isn’t an issue.

1 Like

Could it be that due to their SSL certificate being * and not is making fetch check the certificate towards instead of which fails, due to being on the Cloudflare CDN, thus making fail too?

I managed to re-produce the issue in my own account, setting a Custom Hostname “Cloudflare SSL for SaaS” or CNAME for the root domain will cause all workers to fail towards ALL sub-domains, either with time-outs or with SSL Handshake issues (Works locally and in Quick Edit but not when deployed).

Since CNAME is such a common feature, Workers would be useless, we can’t contact every supplier and tell them not to CNAME their website if the sub-supplier uses Cloudflare CDN because our Workers won’t work. That’s preposterous … (The solution suggested by Cloudflare in tickets)

Update: Cloudflare has filed it an internal (not confirmed) bug.

1 Like

Cheers thanks for the update!

So the issue is with Cloudflae CNAME flattening (flatten at root only or flatten all CNAMEs?) feature where the apex and subdomain are not both with Cloudflare DNS ?


Update: Cloudflare says it’s due to the “Wildcard” setting on the CNAME domain, this makes it so that none of the sub-domains can be routed to. The supplier “Kinsta” in this case, did that for all domains and you could not do it for a specific sub-domain (catch-all).

This on Enterprise plan ? I thought subdomain wildcard DNS was Enterprise only?

They have it as a metered service now, still in private beta though.

1 Like

I see so charge per DNS query?

Per custom domain. Say you have a customer that’s on Godaddy and you offer a service that they want on their domain. You tell them to create a new DNS post for that points to CNAME also called vanity domains. I tested it with workers too and works very well :slight_smile:

Oh is this part of CF’s SAAS offering ?

Yes! Custom domains pointing at 3rd party domain servers.

1 Like