Full SSL rejects self-signed certificate on non-CF origin

SSL/TLS encryption mode is set to “Full” (not “Full (strict)”), but it appears to be handled as “Full (strict)” for non-CF origins.

https://selfsigned.istkaputt.de/ gets met an SSL 526 error. It’s a very simple worker fetching https://self-signed.badssl.com.

addEventListener('fetch', event => {

It works fine if I set SSL to Flexible on istkaputt.de, but I don’t think I should need to disable SSL on my origins to be able to fetch from a non-cloudflare-origin that uses a self-signed certificated in workers.

I understand invalid certificates would be a different beast (e.g. telling fetch to ignore the expiration date), but this one isn’t invalid, it’s just not trusted.

Well, a self-signed certificate is just as invalid as an expired one. If you cannot establish a proper level of trust it is invalid per se. Actually, an expired certificate is more trustworthy than a self-signed one.

I understand your issue, but I really believe the proper way would be to contact the owners of the site you are connecting to and get them to fix their site.

And Full is actualy not a secure mode either, you should really switch that to Strict.

1 Like

I get that, though I disagree about not-trusted being just as invalid.

However: Full specifically says “Encrypts end-to-end, using a self signed certificate on the server”, but then does require them for worker fetch.
At the same time, fetch isn’t completely ignoring the zone’s SSL setting.
If I set it to Flexible, it works as if it was set to Full: connect to the origin with SSL, but allows self-signed certificates.
If I set it to off, fetch actually changes the URL in the worker to http://self-signed.badssl.com/ (which I find debatable, but that’s not important).

The current behavior is inconsistent – Full is its own setting with regards to origins in the same zone, but becomes Full (strict) when it comes to non-CF origins (if I understand correctly, it would respect another zone’s setting if I were to fetch a URL from that zone which makes it more confusing).
This is either a bug, or it deserves to be documented.

What was not clear about my earlier explanation?

In order for a certificate to be valid, it needs to be trusted and fulfil all the criteria of such a certificate, specifically being part of a trusted chain, being issued for the hostname in question, and having a validity period which matches the current date.

A self-signed certificate already does not fulfil the first criteria and hence cannot be considered valid.

Point taken, that is an inconsistency.

Still, I’d argue the underlying issue is that you are trying to connect to a server with broken security and that rarely is a good idea. Hence why I mentioned the proper way would be to contact those site owners so that they can fix their site.

Also, one shouldn’t be on Full in the first place, so you’d run into the certificate validation issue anyhow.