SSL Protocol Filtering and HTTPS Website Failures

[dbergst 1]

I have been following the procedures in the article posted at https://support.eset.com/kb3126/ and am still running into difficulty with certain web site certificates.  What happens is the real certificate is being replaced by an invalid expired certificate from a different website.   If protocol filtering is disabled, this does not occur, and the correct site certificate is used.

In case anyone wants to try the site in question, it is https://community.kde.org

Below is a copy of the error message I have been seeing:

community.kde.org uses an invalid security certificate. The certificate is only valid for search.dnsadvantage.com. The certificate expired on Monday, September 18, 2017, 12:03:45 AM. The current time is August 3, 2018, 11:24 PM. Error code: SSL_ERROR_BAD_CERT_DOMAIN

Edited August 4, 2018 by dbergst
Added detailed error message

[Marcos 5,446]

It appears they have already fixed the cert. issue. An SSL check didn't report any issues and ESET is scanning the website alright too:

[dbergst 1]

12 hours ago, Marcos said:

It appears they have already fixed the cert. issue. An SSL check didn't report any issues and ESET is scanning the website alright too:

I checked and at first the issue appeared resolved; then, when going to a subsite in the community.kde.org domain the cert. issue returned, even when going back to the root of the domain.

 

[itman 1,800]

1 hour ago, dbergst said:

I checked and at first the issue appeared resolved; then, when going to a subsite in the community.kde.org domain the cert. issue returned, even when going back to the root of the domain.

I can reach that domain in IE11 w/o any certificate errors. Might be a FireFox problem since they use their own certificates.

Note this web site only uses TLS 1.2 with no downgrade capability.

[dbergst 1]

1 minute ago, itman said:

I can reach that domain in IE11 w/o any certificate errors. Might be a FireFox problem since they use their own certificates.

Note this web site only uses TLS 1.2 with no downgrade capability.

Thanks, itman.  I noticed the problem seemed to be resolved after retrying the site and subdomain.  Just to be sure I cleared out my browser cache in case the wrong certificate was still there.

[dbergst 1]

Well it appears I spoke too soon.  The invalid certificate is showing up again.

[itman 1,800]

Below is the https://community.kde.org/ site's certificate as shown in IE11.

Firefox might be objecting to all those "aliases" specified by DNS names beginning with "*."

Don't believe the problem here is Eset. All Eset is doing is responding to what the browser is telling it in regards to certificate validity.

Edited August 4, 2018 by itman

[itman 1,800]

58 minutes ago, dbergst said:

Just to be sure I cleared out my browser cache in case the wrong certificate was still there.

Don't know how Firefox clears its certificate cache. However in IE11, clearing the browser cache won't clear the browser's certificate cache. There is a special tabbed option in IE11 settings to clear the browser's certificate cache.

[dbergst 1]

Something still seems to be amiss with SSL protocol filtering, at least with my installation of EIS 11.2.49.0.  For now I have this setting turned off and the certificate issues are gone.

[itman 1,800]

Appears the web site is bogus.

How I determined this is I went to the GRC web site that will fingerprint the web site through independent server lookup: https://www.grc.com/fingerprints.htm . Here is the thumbprint for the web site that GRC found:

Quote

community.kde.org incapsula.com — 0A:92:05:48:62:31:73:D9:9C:7A:D7:DC:C6:43:B5:B9:6B:26:8C:E8

For the following comparison ignore the above colon symbols in comparing the following thumbprint in the certificate shown for the https://community.kde.org/ website:

The thumbprints don't match obviously. This indicates that the web site displayed in the browser is not the actual one associated with the certificate issued to it.

Also I assume that FireFox is actually performing a web site certificate pinning validation whereas IE11 does not. Additionally, Eset does not perform certificate pinning validation. So the certificate discrepancy is indeed originating from Firefox.

@Marcos, I couldn't think of a better example of why Eset's SSL protocol scanning should be performing certificate pinning validation. At least, provide a user option to add a thumbprint for their Banking & Payment protected web sites and validate to that.

-EDIT- It gets better. I just went to https://community.kde.org/ again and the certificate had a different thumbprint!

Edited August 4, 2018 by itman

[dbergst 1]

What get's interesting also is the fact that a bogus certificate for search.dnsadvantage.com was showing up at my end.   I traced this issue to the DNS settings on my router which were customized recently.  When I went back to the standard DNS servers my ISP (Verizon) uses, the certificate injections stopped and the web pages loaded normally.

In regard to the site certificate for community.kde.org, that is a separate matter that should be addressed by the site owner.

[itman 1,800]

As further proof the certificate being used by kde.org and all those other DNS name sites referenced in its certificate is bogus, go to the https://incapsula.com web site. Observed is that site is using an EV certificate issued by GeoTrust.

Also @Marcos, someone needs to check out Eset's certificate chain validation processing. In IE11, Eset failed to alert about the missing root CA certificate for https://community.kde.org/ as shown below:

Edited August 5, 2018 by itman