Worker works on workers.dev domain but not on own subdomain

Ah! Never mind, wrong link!

@mwerner You are getting a HTTP error 500 on http://rsp.obsessiveanalytics.com/* and 525 SSL handshake failed on https://rsp.obsessiveanalytics.com/sourceConfig

To fix Error 500
Provide details to your hosting provider to assist troubleshooting the issue.
To fix 525: SSL handshake failed
Contact your hosting provider to exclude the following common causes at your origin web server:

  • No valid SSL certificate installed
  • Port 443 (or other custom secure port) is not open
  • No SNI support
  • The cipher suites accepted by Cloudflare does not match the cipher suites supported by the origin web server

If 525 errors occur intermittently, review the origin web server error logs to determine the cause. Configure Apache to log mod_ssl errors. Also, nginx includes SSL errors in its standard error log, but may possibly require an increased log level.

Also, this is at the top

@AppleSlayer

The worker works perfectly fine, just not via the own subdomain, all requests against the .workers.dev domain works, the JS in the worker simply performs a fetch and returns the response:

switch(pathname){
    case '/sourceConfig':
      return fetch('https://api.rudderlabs.com/sourceConfig', {headers: request.headers})
      break;
    case '/dataPlane':
      const init = {
        headers: {
          'Content-Type': 'application/javascript'
        }
      };
      const response = await fetch('https://cdn.rudderlabs.com/v1/rudder-analytics.min.js');
      const responseText = await response.text();
      return new Response(responseText, init);
      break;
//...
}

The fact that the exact same code works on the workers.dev subdomain but not on the own subdomain would tell me that it’s an issue with the cloudflare routing/proxying, not the worker code itself, no?

Got some logging and the empty response is because apparently JS returns an empty response when you call .responseText() on a fetch. The status of the fetch is 525 SSL handshake failed. Again this works on the workers subdomain but not on my own.

I’m not the only one it seems that has issues fetching in workers and getting 525 errors, so far I have found no solutions in those posts though. One said to change the SSL mode (which is currently set to flexible on the site settings) to full or full (strict) via a page rule.

I did that:


But still get the 525 error.

Found the solution. Apparently CloudFlare workers bypass page rules so the approach above I had was fine just had to be done in reverse.

I set the overall SSL settings to “full” and then made a page rule for my website to make it go down to “flexible”. Now it works as intended on my own subdomain. @AppleSlayer thanks for the help it was much appreciated.

In both cases you have a security issue.

That’s all fine and good @sandro but going strict/full strict was simply not an option for the origin server that is hosting the website/webapp at my main domain. At least right now it isn’t. And I’m not handling any PII data or user information so having the CloudFlare <> my origin server connection secured is not paramount - right now.

Using full (strict or not) overall and flexible for my app/site is functional. My site isn’t down and the proxy setup is working too.

Also I just switched the overall settings to Full Strict and it’s working for the proxy so yay, I just haven’t gotten around to setting up the origin certificate SSL stuff on my website.

Then you have an issue with the server and should fix that first. Right now you not only have an insecure site you also deceive your visitors.

I’m sorry to disagree. There’s a reason your post is a post here and not an official CloudFlare documentation.

Firstly about the “insecure site” argument:
There is nothing wrong with using flexible. SSL termination is extremely common. Take a look at any AWS load balancer for instance. They handle the SSL termination and the traffic between the load balancer to the origin server(s) is over HTTP. This is not insecure. Unless your sever is compromised, no one is “able to intercept, record, and manipulate these connections without you, Cloudflare, or your visitors having the slightest idea” as you put it.

About the “deceiving your visitors argument”:
Please do tell me how I am deceiving anyone here? A visitor is getting an encrypted connection to cloudflare and for anything that is cacheable they are guaranteed to get CloudFlare’s cache of the requested resource. As for the things I proxy through the workers, that is what they are there for; to handle these kinds of requests that need extra processing, authentication, that you don’t want or need to expose on the front-end.

Yes, locally, not across public networks aka the Internet.

As for your deception, how else would you call it if someone pretends to have a secure site when in fact everything goes in an unencrypted fashion over the wire? You are sugarcoating your insecure setup.

Well tell me how someone would (without having a shell on my origin server) be able to intercept CloudFlare’s proxy request and I’ll believe you that it is “insecure”.

If you answer the question how someone can intercept any request, you’ll also have the answer to your question. Are you saying HTTPS is overrated?

Of course it isn’t but I’m saying that because the connection between cloudflare and my origin server, and the various protections it has, is over HTTP, calling the entire site “deceptive” and “insecure” is wrong.

I am afraid it is insecure for that very reason.

I am really not sure why we even need to discuss this in 2021. A certificate these days is a matter of seconds and if you really cared about security you’d have installed this in the meantime instead of discussing why HTTP is insecure.

CloudFlare’s reverse proxy is plenty secure for the site that you didn’t take the time to even look at. It’s a blog and has a contact form that is handled in JS so it doesn’t even submit to the “insecure” origin server. That is why I haven’t bothered putting the origin certificate there (yet) and why that site is secure.

If you do not have an origin server the encryption mode won’t matter at all and you can set it to Full Strict anyhow. Why did you downgrade in the first place then?

OK last reply here because it isn’t productive. This post is about an issue with cloudflare workers and 525 erorrs when using your own domain. Knowing that in order for that to work SSL needs to be “full” (strict or not) is the end of that.

And you didn’t read my post. The contact form doesn’t submit to the origin server. The blog/blog content comes from an origin server. It effectively serves only static content and receives no input/user data. That origin server does not have the origin certificate setup (yet) since I’m currently rebuilding it so it’s a waste of time to add SSL functionality to it right now.

Congratulations, you have an insecure site.

1 Like

One more time, because it has been almost an hour and in that time you can properly secure an entire array of servers.

You’re welcome!