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

[abhiapsunde]

I have a worker that get its data from a AWS API Gateway endpoint.

While this works fine in the online Worker Editor , when it deployed and worker endpoint is invoked from outside world it fails with following error :

Error 525 Ray ID: 48c3984a64e49668 • 2018-12-20 16:48:09 UTC

SSL handshake failed

AWS endpoint is in following format XXXXX.execute-api.us-east-1.amazonaws.com

I have verified from browser by hitting the origin directly that the certificate is at-least valid for Chrome browser (The cert itself appear to be a wildcard one , one served for all *.execute-api.us-east-1.amazonaws.com endpoints). As per the help page for 525 , there will be other issues like cipher suite used by AWS may not be supported by CF , that is something I need some help from CF to check.

Second problem is , the error page shown to end customers is revealing the origin in error page. I’m hoping to use CF rate limiting to protect the endpoint and don’t want anyone else to know the real URL. So I would like to know how I can stop CF from doing this.

Any help / pointers on this are highly appreciated.

[abhiapsunde]

Assuming there is something wrong with wildcard cert AWS presents , I created a custom domain and applied a custom certificate to it. Started using that endpoint in the worker, again works all fine from the Editor but in real world fails with following -

TypeError: Too many redirects.; urlList = ORIGIN_URL ,…ORIGIN_URL … 21 times

cf-ray:48cac851aa9a2a7f-SEA

Little more about the custom domains , its a subdomain in my site (copy-paste.net ) created as CNAME to the AWS cloudfront subdomain they generated for me and installed custom certificate on.
I can access that url directly from browser and curl and dont see any redirections there.

UPDATE
for the SSL handshake error I believe there is something messed up with AWS Virginia data center endpoint for my service , I also have this service in other data centers and the worker fetch works fine with that URL.

UPDATE
As of today , none of the URL ( I have the service in around 10 AWS regions ) work. I really don’t know what is with the AWS URL that CF doesn’t like !

Final Update
Silly me, my understanding of SSL options (OFF, Flexible, Strict, Full) in CF dashboard was all messed up , thing which I should have read first. On setting it to Full I’m able to fetch from AWS API gateway from my worker.

[travis7]

@abhiapsunde thank you so much! Setting my SSL mode to Full solved this issue for me as well.

Instead of connecting to an AWS API Gateway, I was connecting to an external Heroku instance.

I’d love for someone from Cloudflare to explain what’s going on here, as this was really, really difficult to track down. All of these requests work as expected locally and from other servers, just not when run from within my Cloudflare workers…

[nicolas]

Same here. Spent a long time figuring it.
But that “fix” doesn’t work for me, I need the “flexible” setting for an other use case

[matteo]

You can configure SSL TLS settings per path using Page Rules, my recommendation would be to have it to highest possible setting (ideally Full (Strict)) and the lower it for the specific paths or subdomains if there is no other way to add a certificate at the origin.

Most often, if the origin supports HTTPS and correctly redirects to it, the redirect loop is caused by the fact that Cloudflare asks the origin for the content via HTTP, it gets a redirect to the HTTPS page, which is the same the user is already on, causing a redirect to itself, forever.

[captainben]

Check your settings for authenticated pulls, I’m seeing toggling that can have an effect on the workers…even though it shouldn’t because with my understanding authenticated pulls is only used in conjunction with a server and workers/routes are supposed to be above a server and not touching the server.

[lovasoa]

Hello !
I am having the same issue. Did someone from clouflare have a look into it ? I don’t see any reason why a worker should not be able not fetch an HTTPS url, whatever the SSL mode is for the website…

[sebastienlorber]

Has anyone found a solution? @lovasoa ?

This drives me mad for a few hours. Tried all the global/page SSL settings combinations possible (off, flexible, full, strict), no change.

CloudFlare workers fetch HTTPS works on workers.dev subdomain but not on own subdomain getting 525 error

Kenton Varda: (Note: The “SSL Handshake fail” error itself is actually a known bug in Workers, that happens when you try to talk to a host outside your zone using HTTPS but you have “flexbile” SSL set. We do not use flexible SSL when talking to domains other than your own, but there’s a bug that causes the request to fail instead of just using full SSL as it should.)

Can we get a public status on such a bug? Is it reasonable to expect it to be fixed now?

My domains:
https://cf.thisweekinreact.com/
https://this-week-in-react.pages.dev/

Code: https://github.com/slorber/this-week-in-react/blob/main/app/routes/index.tsx#L54

I just send a request to some https API:

async function subscribeToRevue({
  email,
  revueSecretKey,
}: {
  email: string;
  revueSecretKey: string;
}) {
  const REVUE_SUBSCRIBE_API = "https://www.getrevue.co/api/v2/subscribers";

  const revueFormData = new FormData();
  revueFormData.append("email", email);
  revueFormData.append("double_opt_in", "true");

  const result = await fetch(REVUE_SUBSCRIBE_API, {
    method: "POST",
    headers: {
      Authorization: `Token ${revueSecretKey}`,
    },
    body: revueFormData,
  });

  return result;
}

There’s nothing fancy being done, and it’s quite similar to your Egghead + Unsplash tutorial here: Expert led courses for front-end web developers. | egghead.io

This works fine in Wranger/dev. I also got this working on Vercel in 3 minutes, while I’m struggling for hours to make it work on CF. I really wanted to give a try CF workers but this is a pain atm and I think I’m just going to move back to Vercel

Looks related to:
https://tipsfordev.com/cloudflare-workers-fetch-https-works-on-workers-dev-subdomain-but-not-on-own-subdomain-getting-525-error

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?

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

I have a worker that does 3 things, all of which are proxies: Accessing /dataPlane will simply execute a fetch against a different URL (an analytics JS SDK) Acessing /sourceConfig requires an auth header to proxy some stuff POSTing to /v1/page or /v1/track , and a few others, passes on the posted body to the destiantion and returning that origin’s response I deployed it to the workers subdomain and as you can see here: https://rsp-production.financialflo.workers.dev/dataPlane it shows the JS …

Requests to Lets Encrypt ACME server failed with 525 Origin SSL Handshake Error

Hi. I am writing a Worker script that automates the process of ordering new certificates from Lets Encrypt via its ACME API and completing the DNS challenges. At first, the script requests https://acme-staging-v02.api.letsencrypt.org/directory to get a list of sub-service endpoints. The code can be simplified as: addEventListener('fetch', event => { event.respondWith(handleRequest(event.request)) }) /** * Respond to the request * @param {Request} request */ async function handleRequest(…

Error: Origin SSL Handshake Error (525)

Hello, I am encountering a strange error on my Worker, where I am consistently receiving a 525 error when fetching an external website: addEventListener('fetch', event => event.respondWith(fetch('https://deepl.com'))); Some notes: I have tried this on a fresh worker script without any routes associated with the script This happens both using wrangler dev and in production I have tried to disable caching with the cf object properties related to caching I have Full (Strict) SSL enabled on the…

Also can forward the log that API call returns:

# Error 525

Ray ID: 6d9eb373ca1b40b1 • 2022-02-07 18:32:27 UTC

## SSL handshake failed

You

### Browser

Working

Paris

### Cloudflare

Working

cf.thisweekinreact.com

### Host

Error

## What happened?

Cloudflare is unable to establish an SSL connection to the origin server.

## What can I do?

### If you're a visitor of this website:

Please try again in a few minutes.

### If you're the owner of this website:

It appears that the SSL configuration used is not compatible with Cloudflare. This could happen for a several reasons, including no shared cipher suites. [Additional troubleshooting information here.](https://support.cloudflare.com/hc/en-us/articles/200278659)

Cloudflare Ray ID: **6d9eb373ca1b40b1** • Your IP: 2a01:cb00:ca6:de00:59c3:19b8:ed3:9294 • Performance & security by [Cloudflare](https://www.cloudflare.com/5xx-error-landing)

[thomas4]

Can you check that your hosting provider isn’t a Cloudflare reseller?

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).

Just a couple of weeks ago, this issue popped up again and the provider I had issues with just moved to another hosting because Kinsta refused to accept there was any issues.