TheShard 0 Posted July 12, 2019 Share Posted July 12, 2019 We are having an issue with HTTPS filtering where we are unable to access certain websites (mostly for appliances, load balancers, etc. that have a self-signed signature) even after adding an exclusion for the website in Chrome or any browser that uses the Chrome rendering engine (Opera, for example). One such example prompts us upon going to the site, we hit to allow the exclusion always and other browsers work but Chrome is giving the below message. It works in Chrome if ESET 7 is not installed. Even disabling ESET does not allow it to work, the product has to be completely removed! Has anyone else encountered this? Below is the message we get. This site can’t provide a secure connection 10.10.1.69 doesn't adhere to security standards. ERR_SSL_SERVER_CERT_BAD_FORMAT Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 12, 2019 Share Posted July 12, 2019 Check out this Eset knowledge-base article as a possible solution: http://support.eset.com/kb7241/ Link to comment Share on other sites More sharing options...
Administrators Marcos 5,074 Posted July 12, 2019 Administrators Share Posted July 12, 2019 Try enabling pre-release updates in the advanced update setup. With newer modules the decision in case of self-signed certificates is left to the browser. Link to comment Share on other sites More sharing options...
TheShard 0 Posted July 17, 2019 Author Share Posted July 17, 2019 Thank you both for the reply. I've tried the steps in KB7241 with no luck. I've also tried setting my profile to pre-release updates with no change. Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 17, 2019 Share Posted July 17, 2019 (edited) To begin with the certificate Chrome is objecting to is associated with a private IP address: Quote Private IP Addresses Most organisations have far more computers than available IP addresses. Using private IP addresses helps to tackle this issue by allowing companies to have a single Internet gateway with a public IP address. All of the other nodes have private IP addresses. The gateway uses a Network Address Translation (NAT) server to translate the private IP addresses to an address that can be routed across the Internet. ICANN has reserved sets of IP numbers for private use on the three classes of address. Notice how the recommendation includes non-standard subnet masks for class B and class C private IP ranges. Private Address Ranges for class A, B and C networks Class Private IP Address Range Subnet Mask A 10.0.0.0 to 10.255.255.255 255.0.0.0 B 172.16.0.0 to 172.31.255.255 255.240.0.0 C 192.168.0.0 to 192.168.255.255 255.255.0.0 https://www.sqa.org.uk/e-learning/WebTech01CD/page_12.htm So unless IP address, 10.10.1.69, is associated with some internal network web site/device address, you shouldn't be connecting to it in the first place. I believe in the U.S., some cable providers use the 10.xxx.xxx.xxx range for their internal network address assignments versus the 192.168.xxx.xxx range. One possibility here is the cable router, gateway device, etc. uses some type of admin utility that requires a root certificate to be installed? These type of "utility" certificates have been abused in past; e.g. Lenovo "Superfish" incident. If this is an internal network entity, this article describes how to add the self-signed certificate used by the entity to Chrome's root CA certificate store: https://www.corvil.com/kb/how-do-you-get-chrome-to-accept-a-self-signed-certificate Bottom line - this has nothing to do with Eset's SSL/TLS protocol scanning. Edited July 17, 2019 by itman Link to comment Share on other sites More sharing options...
Administrators Marcos 5,074 Posted July 18, 2019 Administrators Share Posted July 18, 2019 Quote Even disabling ESET does not allow it to work, the product has to be completely removed! This cannot be true because when SSL filtering or the whole protocol filtering is disabled, the SSL (https) communication bypasses ESET completely so there's no chance we would intervene in it in any way. You can test the behavior when a self-signed untrusted certificate is used here:https://self-signed.badssl.com/ You should be asked by the browser if you want to continue to the website. Link to comment Share on other sites More sharing options...
TheShard 0 Posted July 24, 2019 Author Share Posted July 24, 2019 Yes, it's a private IP address. It's for a security appliance. That was eluded to in the initial post when I mentioned that it was for a load balancer. And yes Marcos, I thought that too except it is the case. Since it seems like this isn't a known issue, I'll go ahead and open a support case. I'll report back here with the results. Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 24, 2019 Share Posted July 24, 2019 (edited) I reviewed your original posting. It appears your issue has nothing to do with Eset. To get Chrome to trust a self-signed certificate, it must be: 1. Installed properly into Chrome. Details on how to do that are here: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/ . 2. The self-signed certificate must be properly formatted. Based on the Chrome message you showed in the original posting, it appears your self-signed certificate is not properly formatted: ERR_SSL_SERVER_CERT_BAD_FORMAT Additionally, it may be necessary to exclude your self-signed certificates from Eset's SSL/TLS protocol scanning. Edited July 24, 2019 by itman Link to comment Share on other sites More sharing options...
Recommended Posts