The request was aborted: Could not create SSL/TLS secure channel.

Update:

Even if I disable SSL TLS inspection, it did not work, as it was my first thought!

I found out this so far, and now it work.

I can enable SSL/TLS inspection, and create this rule:

This makes it work, EVEN after restart.

So the on off switch of SSL/TLS, does not always seem to anable and disable, as it's supposed to do.

Update:

Even if I disable SSL TLS inspection, it did not work, as it was my first thought!

I found out this so far, and now it work.

I can enable SSL/TLS inspection, and create this rule:

This makes it work, EVEN after restart.

So the on off switch of SSL/TLS, does not always seem to anable and disable, as it's supposed to do.

Proxy (the HTTPS decryption in Firewall policy) enable the "V17.5 Proxy" and you will bypass the TLS encryption for HTTPs, because the Proxy will accept those packets. 

For more information, read: https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/recommended-reads/115976/xstream---the-new-dpi-engine-for-web-proxy-explained

LuCar Toni said:

Proxy (the HTTPS decryption in Firewall policy) enable the "V17.5 Proxy" and you will bypass the TLS encryption for HTTPs, because the Proxy will accept those packets.

Thanks for the reply LuCar Toni I have not seen this post before :-)

But, my issue was this:

- Have SSL inspection disabled

- have Web proxy (17.5) disable and None in Web policy

- have Firewall rule that allows ANY service to WAN.

TLS/SSL was broken for LAN, no matter if I enable or disable SSL inspection, only when I made the exception, things started to roll perfectly :-)

Should this not work, with exception, if SSL inspect is disabled, and all proxy features are disabled?

I guess this is a bug and someone should investigate. If any service and not web filtering  is applied, neither the proxy mode 17.5 or tls/ssl inspection should intrude.

If this is not the case, how can we prevent that proxy or dpi engine intrude?

Sounds odd to me, did not see this before.

I would say, maybe there was another policy, picking up this traffic?

Because if you create a Web proxy exception, it will be used for ether DPI Engine or Web Proxy (old). 

So most likely, any rule picked up this traffic and the exception solved this or there was another rule involved. 

Can you actually reproduce this issue right now?