ERR_SSL_PROTOCOL_ERROR on Google Chrome

[sforbus]

We are having a bizarre problem since updating to 6.2.1 (we updated due to a memory leak issue in 6.2.0).

Certain sites are giving us a ERR_SSL_PROTOCOL_ERROR only in Google Chrome. I have tried all the usual troubleshooting for this error, but the only thing that fixes it is restarting the fortigate. Two sites (facebook.com and login.renweb.com) both use TLS 1.3, but we can get to facebook without a problem and we cannot get to the other site. After rebooting the device, it works for several days and then starts behaving poorly again.

Other browsers work fine, including Internet Explorer, Edge (not Chromium based) and Firefox.

I have attempted to disable SSL certificate inspection, but that does not seem to affect the problem one way or another. I also tried putting the fortigate back on its factory certificate.

My next step will be to revert to 6.0 branch, where I did not experience this issue, but I figured I would post first to see if anyone had similar experiences.

[emnoc · Accepted solution]

Have anybody used curl against theses sites? Inspect the certificate and if you see any stale cert clear them. You can also test in a incognito window and see if the problem exists.

It sounds  like a browser issues. FWIW. I check all of those sites from  fortios v6.2.3 and see no issues using chrome on windows { Version 78.0.3904.87 (Official Build) (64-bit) }

Ken Felix

[dxnet]

Firmware 6.2.1 I have similar error, cant open https://www.whatsapp.com/ in Google Chrome, in IE works.

I add exempt for ssl inspection (wildcard *.whatsapp.com), but it doesn't work. whatsapp in chrome works only ssl deep inspection is disabled

[sforbus]

I have solved the problem by downgrading back to 6.0.5, I believe. It has been a couple of days and this problem has not resurfaced. I will see if it happens again.

[bbilut]

Have you tried disabling QUIC protocol in Chrome?

[dxnet]

I tried to disable QUIC, but it doesn't resolve problem also doesn't work https://serverfault.com/ and I add exempt for ssl inspection *.serverfault.com too And I noticed that I can't open this sites in Mozilla too. Works only in ie, edge

[dxnet]

So, I've solved the problem by downgrrading back to 6.2.0 (build 0866), ssl in Chrome works on all sites, where I had problem. (whatsapp.com, https://serverfault.com)

[kingD]

I configured an url filtering that works only with IE. Chroom lets all the https traffic pass

[marcrp]

We are experiencing the same issue too since upgrading to 6.2.1.

Although for us it seems to be only affecting IE11 and we randomly get the error "Can’t connect securely to this page" "Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to"

The only work around is to create a rule with no AV inspection and put the site we are having issues with as the destination and it seems to work. 

I think I will be reverting to 6.2.0 as I have so many random sites that aren't working for us.

[seadave]

TLS 1.3 is a different beast.  Can't tell from the bottom of this page if MiTM TLS 1.3 is only supported in Flow Based inspection or also in Proxy mode (which most people use).  You may need to change from proxy to flow.

https://docs.fortinet.com/document/fortigate/6.2.0/new-features/35927/tls-1-3-support

One other issue we ran into when doing major version upgrades is to ensure your CA cert used for MiTM is not using a weak signing algorithm such as SHA1.  Make sure you generate a self signed one that is at least 2048bits using SHA256 if RSA and 384bits if using ECDHE.

We have found some domains that use HSTS (cert pining), those will not accept a connection that is broken by a proxy.  We had to create a rule to exempt such domains from filtering if they were legitimate for business.

Finally, I wouldn't be using 6.2.X in production yet and I'd only use it on devices bigger than E series with a model number greater than 100.  Other models are prone to fault due to minimal RAM and CPU resources.  6.2 is still very new.  We are running 6.0.5 in production and it has proven to be very stable on 501Es

[GregAndo]

Things were going okay, but now we are beginning to see this too after having run for a few days.  I am not sure how far reaching it is, but, ironically, it is affecting my ability to log into the FortiGate web interfaces of my fleet, which are a mix of 6.0 and 6.2.1

Has anyone been able to isolate the cause?  What about a temporary resolution that doesn't require a reboot?