dbergst

Time;URL;Status;Application;User;IP address;SHA1 12/11/2019 12:47:29 AM;hxxp://www.systemrequirementslab.com/services/systeminfo/28CA06ED-AC00-7A31-F22A-63396FD2A4F3/1232 Is this a legitimate site and if not why is AMD trying to access it?

Yes, rebooting helped here. So I take it this is an intermittent issue?

I'm seeing this issue but only after canceling a prompt from firefox to close out the old process.

This worked for me.

As it turns out, I discovered that when the IMAPS Scanner was enabled, ESET was blocking all connections over port 993. After running a repair on the ESET software installation, the port is no longer blocked and my Thunderbird 60 client works as expected.

Thanks, guys. Per Marco's response I have opened a case with ESET to help resolve this issue.

I'm not sure what is different about my setup here; IMAP is connecting over the default port (993), and the ESET software version in 11.2.49.

Thank you Marcos, the IMAP server is Google (imap.googlemail.com).

I just started running Thunderbird version 60 and ran into problems with sending and receiving emails. Initially I reported these issues with the Thunderbird team but it was soon discovered that the problem might be antivirus or firewall related. Sure enough, I tried disabling the IMAPS Scanner Setup in EIS and the email client started behaving correctly. Any thoughts on what I can do to re-enable the IMAPS scanner?

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.

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.

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

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.

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