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 zone, and have tried the other options as well to no avail.
  • I can successfully get a response from every other website I’ve tried over SSL.
  • I can successfully curl the above domain
  • The host has SNI enabled, and cipher suites Cloudflare supports (according to SSL Labs)
  • For some reason, in the worker playground, it will successfully fetch this domain if I use the HTTP simulator (see screenshot). This apparently proxies worker requests through the https://dash.cloudflare.com/api/v4/accounts/.../workers/scripts/white-bread-97d2 endpoint…

If any other information is needed, I can provide it.


1 Like

Domain?

Sorry it’s in the code snippet, https://deepl.com

Loads for me, how did you get the error?

It only happens from my worker script, the fetch fails with HTTP 525 on that URL and all URLs on that domain.

So what’s the worker script link?

Same for me… Don’t know why.

From the above screenshot, it seems that error is comming from Cloudflare.

Is the external Website working over HTTPS? - seems it’s working and it’s also on Cloudflare too.

Seems like you are missing a part of a code in your snippet.

Works for me, here:

My below code working from this source:

addEventListener('fetch', function(event) {
  event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
  // Only GET requests work with this proxy.
  if (request.method !== 'GET') return MethodNotAllowed(request)
  return fetch(`https://deepl.com`)
}
function MethodNotAllowed(request) {
  return new Response(`Method ${request.method} not allowed.`, {
    status: 405,
    headers: {
      'Allow': 'GET'
    }
  })
}

To use it on your domain, you might need to have DNS records pointed (for example A www and A yourdomain.com to 192.0.2.1 and added the active Worker (in production) under the zone to the route like yourdomain.com/*) and setup a Page Rule for the SSL (Full maybe?).

Otherwise it’s the cause as stated from below cite:

UPDATE:
Okay, neither with Fetch HTML - https://developers.cloudflare.com/workers/examples/fetch-html does’t work and I have tried all 3 SSL settings, none.

I tested some other Website over HTTPS, it’s working.
Even some of mine’s on Cloudflare, working fine.

Except, those who have Firewall Rules and some other security settings, but I accordingly get 1020 Access Denide or some other know error so far.

I have exactly the same problem! I’m using the deepL API(https://api-free.deepl.com/v2/), and it works in the simulator, but not when deployed.

I contacted DeepL support, and they told me to:

Please ensure the following domain pattern isn’t blocked by a firewall, VPN, SSL-Check or proxy server: *.deepl.com.

Which I can’t do here, right?

@taylor.john.clifton - did you figure it out in the end?

I’m having the exact same issue when connecting to the Movie DB API (API Docs).

I get a 525 response when running via wrangler dev and when deployed, however it will work fine on the “Quick edit” screen within my dashboard.

The worst part is this is when deployed to the workers.dev domain, so I have no control over any SSL settings:
https://project.username.workers.dev

Has anyone had any luck with this? It seems to be at cloudflares end, but there seems to be nothing that I have control over to fix.

I am also having this issue as well with a different endpoint/domain altogether, using the default worker.dev address. It works fine in development/quick edit/preview, but not in production. I get the status 525 returned. Is this a bug with Cloudflare workers?

UPDATE: The endpoint I’m attempting to make secure (HTTPS) fetches to is hosted by AWS

UPDATE 2: I was able to resolve this by setting up a route to the worker using my domain, and ensuring that the SSL settings for my domain on Cloudflare was set to “Full” - For whatever reason, this seems to be an issue when using the default workers.dev route/address and attempting to fetch from AWS and other sources. Just create a route with a subdomain of a domain you can set to “Full” SSL. Otherwise, I’d suggest buying a new domain to use specifically for this purpose. (Did you know Cloudflare offers registrar services, and recently started supporting domain purchases?)

Just so that you know, this will keep your entire site insecure. If you have to pick this insecure mode, it is better to do it via a page rule for that specific path.

Although, I am surprised that would fix it, as a 525 indicates a general SSL issue, which you should also experience on that insecure encryption mode.

I believe you’re mistaken. Setting SSL to “Full” requires a secure connection from the origin/web server to Cloudflare and offers a secure connection (proxy) to visitors connecting to the site. It is “Off” and “Flexible” that are insecure. The only difference between “Full” and “Full (strict)” is that “strict” requires the SSL certificate used for encryption to be issued/signed/cross-signed by a Cloudflare-trusted certificate authority or Cloudflare origin certificate.

In the case of using a domain route for the worker, Cloudflare essentially intercepts the request to your origin and instead directs it to access your worker, but only for the configured routes of that domain.

I can’t say why the workers.dev domain has this issue though, and of course we don’t have access to its SSL settings.

I am not and I am not going to address this yet again. Please use the search.

As long as you are on Full you have an insecure site. I understand in this context it might be tricky, hence the suggestion to only implement it via a page rule.

Plus, it’s not clear why Full should work for aforementioned reason.

1 Like