Jump to content
TheShard

Unable to Access Certain https sites in Chrome on ESET 7

Recommended Posts

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
 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
Posted (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 by itman

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (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 by itman

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...