How ignore 'cert issues' in Workers subrequests?

We have a public service, CDN Finder, that enables you to quickly see which CDN a site is using.
CDN Finder runs entirely in Workers.

We’re seeing 526 and 525 responses for subrequests, for URLs that load fine in the browser.
Example:
https://community.windows.com

The first thing CDN Finder does is fetch the URL and that subrequest fetch gets a 526 error.
Example CDN Finder result (JSON):
https://api.cdnplanet.com/tools/results?source=website&service=cdnfinder&id=1390136929795_894b5b9b0868a1376356

The SSL Checker on SSL Shopper shows no intermediate cert is present.
https://www.sslshopper.com/ssl-checker.html#hostname=community.windows.com

Our SSL/TLS encryption mode is Full.

The SSL/TLS tab in the dashboard states for the Full mode:

Full SSL: Your origin supports HTTPS, but the certificate installed does not match your domain or is self-signed. Cloudflare will connect to your origin over HTTPS, but will not validate the certificate.

From what we observe in our Worker for CDN Finder, Cloudflare does validate the origin cert.

Is there a way to have the Worker not validate the cert for subrequests?
Ideally, this is a Fetch request property.

Did you figure out the answer to this?

No I did not :frowning_face:

I get these 525 responses periodically as well. Would love to know how to relax the ssl checking for outgoing fetch calls within workers to other hosts on the internet that may never change their settings.

There are two ways with node fetch that you can disable SSL verification. It’s not recommended though

The first is creating your own agent:

const fetch = require('node-fetch');
const https = require('https');

const httpsAgent = new https.Agent({
      rejectUnauthorized: false,
    });

const response = await fetch(url, {
      method: 'POST',
      headers: headers,
      body: body,
      agent: httpsAgent,
    });

You can also set an environment variable NODE_TLS_REJECT_UNAUTHORIZED = "0"

1 Like

Sorry, this has nothing to do with node, which Cloudflare does not use on its workers platform.

This is specifically about the fetch implementation on workers

Just wanted to say it in case some weren’t aware yet, but error 525 is pretty much a catch-all error for all kinds of possible issues that prevent making a successful SSL connection between Cloudflare and your origin server.
You can for example also get the error if your origin does not (temporarily) accept any SSL connections or block them (this is something you might have noticed if you’re making use of Vercel as hosting provider).
525 does not necessarily mean a certificate issue.

That’s precisely it. A 525 is not a certificate issue.

Also, all that talk about disabling the verification is rather concerning, because the verification is there for a reason and disabling it essentially undoes SSL altogether.

Yes, the particular use case mentioned by @aaronpeters.nl might be an exception, but in general people appear to be way too comfortable breaking encryption. It’s not like we don’t already have enough broken security because of Cloudflare.

So, unless one has such a specific use case one really better fixes their setups instead of relaxing SSL verification.

3 Likes

So it sounds like 525 is more transitory then? Would you think it’s typically something that could be retried inline as part of the same worker request?

I’ll put a simple retry fallback for these and see if that helps, but it would be nice to know if it’s something we can minimize in general.