Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
sforbus
New Contributor

ERR_SSL_PROTOCOL_ERROR on Google Chrome

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.

 

2 Solutions
emnoc
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
Cibura
New Contributor III

Quick update, I believe we solved the problem, or at least my problem. I haven't fulled vetted this out yet, but so far, so good.

 

All of my static URL Web Filters end with:

* wildcard block

 

I changed it to:

[^.] regex block

 

and now everything works as it should. Wanted to get this out these asap in case it helps anyone.

View solution in original post

37 REPLIES 37
dxnet
New Contributor

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
New Contributor

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
New Contributor III

Have you tried disabling QUIC protocol in Chrome?

dxnet
New Contributor

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
New Contributor

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.comhttps://serverfault.com)

kingD
New Contributor

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

marcrp
New Contributor

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
Contributor III

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
New Contributor

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?

Labels
Top Kudoed Authors