Untrusted Certificate Warning on (mostly likely) Safe Sites

[howardagoldberg 14]

... and yet another issue:

 

This afternoon, seemingly out of nowhere, certain websites while using Chrome are creating a barrage of "Encrypted Network Traffic: Untrusted Certificate" warnings (see attached screenshot).

 

So, far this is effecting Amazon.com and Companionlink.com.

 

There was no issue yesterday. I can reproduce on other computers using Chrome. Using Firefox does not trigger the warning.

 

But Amazon on Chrome is now unusable because the warning pops up with every link on the site, regardless of whether I am logged in to Amazon or not.

 

Thoughts?

[Marcos 5,070]

As for the geo-um.btrill.com domain, it seems to be malware-related according to the information I've found. The other website utilize a valid certificate. If you are getting a warning about an untrusted certificate when opening amazon.com or another 100% legit website, make sure that you have your system date set correctly. If that doesn't help, provide us with instructions how to reproduce that.

[MarkT 0]

@ howardagoldberg

 

I had a similar untrusted connection issue yesterday after uninstalling and reinstalling NOD32 because of it not being recognised by Windows as an antivirus program.

 

This worked for me:

 

hxxp://support.eset.com/kb3126/

 

[howardagoldberg 14]

As for the geo-um.btrill.com domain, it seems to be malware-related according to the information I've found. The other website utilize a valid certificate. If you are getting a warning about an untrusted certificate when opening amazon.com or another 100% legit website, make sure that you have your system date set correctly. If that doesn't help, provide us with instructions how to reproduce that.

 

Here are instructions to reproduce:

 

1) Open Chrome or Internet Explorer

2) Go to amazon.com (this is the site with the geo-um.btrill.com domain - obviously, Amazon is legit)

3) Wait for the warning dialogue above to appear

4) Click block every time you click a link on the page

 

I have reproduced this on two other computers while using Chrome (latest version) and Internet Explorer. This warning does *not* pop up while using Firefox.

 

Rinse and repeat for Companionlink.com, but the certificate issuer is different.

 

Just to reiterate ... I have tested this on two Win7x64 systems running 64-bit Chrome and IE, and a brand new Win10 Pro x64 system that is updated with the "anniversary update" with 64-bit Chrome. Edge is also affected. Only Firefox seems to be immune.

 

This is most certainly an another ESET issue. That's three in two weeks.

 

This error appeared after uninstalling and reinstalling NOD32 9.0.386 after the update to build 396 caused an error which did not allow Windows to recognize ESET being installed (see my post on this in the forum).

 

My date and time are accurate on all systems. And so far, these are the only two websites that seem to be affected.

 

 

 

@ howardagoldberg

 

I had a similar untrusted connection issue yesterday after uninstalling and reinstalling NOD32 because of it not being recognised by Windows as an antivirus program.

 

This worked for me:

 

hxxp://support.eset.com/kb3126/

 

 

 

Thank you for the suggestion. I tried it, but unfortunately, did not resolve the issue.

Edited August 5, 2016 by howardagoldberg

[howardagoldberg 14]

When I click on the "untrusted certificate" hyperlink when going to Amazon.com:

 

 

 

When I click on the "unstrusted certificate" hyperlink when going to Companionlink.com

 

 

 

Note that both are issued by "Cisco Umbrella Secondary SubCA nyc-SG" with a Valid from date of 8/2 and Valid to date of 8/7.

 

I am getting on to Facebook, Twitter, GoogleApps, this forum and all manner of other secure sites without issue.

[howardagoldberg 14]

An update ... although not a solution:

 

1) I employ OpenDNS (pro/paid version) at the network (router) level, and on a whim, reviewed domains that have been blocked by OpenDNS on my network over the past two months. Both of the domains being flagged in the above certificates showed up in the OpenDNS log. What was particularly interesting, is that both were very far down on the last of "number of requests made" going back to early July, but really ramped up in late July through this past week (when ESET started throwing up warnings for Amazon and CompanionLink).

 

By late July, both were in the number 1 and 2 spots for blocked requests being made. Given the relatively low frequency that I go to Amazon or CompanionLink (maybe once a day compared to dozens of times a day to other secure websites), I have to assume that it is not only Amazon and CompanionLink that are generating these requests.

 

Note: Both these domains are being blocked by OpenDNS due to my catagory settings, in this case, they are being blocked as "Adware." They are not flagged by OpenDNS as botnets, malware, phishing, fraud, etc. Also note, that even though ESET did throw up warnings for me this morning about these certificates, OpenDNS did NOT block these domains this morning, which makes me think there is not a direct connection between the OpenDNS blocking and ESET's warnings.

 

 

2) This morning, I choose - on the two Win7 systems thus far - to "always block" the certificates above when I generated the ESET warning by going to Amazon and CompanionLink. The warnings have since been banished as far as I can tell, and the websites in question seem to be behaving normally (no decreased functionality thus far).

 

The above being said:

 

1) The domains in question were being blocked by OpenDNS en-masse before the certificate warnings popped up on my system this past week. Those warnings only began to display after I had to uninstall version 9.0.396 and clean install 9.0.386 (due to the communication error between ESET and Windows detailed in other forum posts both here and on the ESS forum). So, there could have been something legitimate going on to prompt the warnings, but it is hard to believe that that the reinstall/downgrade to 9.0.386 and the above warnings are a coincidence. And again, why only on these two, clearly legitimate, sites?

 

UPDATE: To test further, I went to several computers that have not been turned on since the end of June (the computers belong to my children who are at overnight camp). Both these systems were running NOD32 9.0.381 (one Windows 8.1 machines, one Win10 machine w/o anniversary update installed). Clicking "check for updates" in the update tab indicated that not even 386 was available, and that 381 (and on yet another system, 375) were up to date! For some unknown reason to me, one of the computers had SSL/TSL scanning off. I can't imagine why ... but it was. In any case, these computers exhibited the same behavior (once SSL/TSL scanning was turned on, of course). So, we can rule out it being related to the install/uninstall process. Also one of the computers had AdBlock Plus installed. On that system, only the CompanionLink site prompted a warning, AdBlock did something with Amazon that must have prevented that certificate from getting through in the first place.

 

2) Since all three browsers that I use on my system are on the list of SSL/TLS filtered applications (IE, Chrome, and Firefox -- all latest versions, all 64-bit versions), why did the warnings above *only* get generated when using Chrome or IE. As stated in my earlier posts, using Firefox did not trigger the warnings. (For the record, I use Chrome and FF every day on all systems -- I only discovered that IE was affected when I started testing the behavior on all of my systems and wanted to see if there were browser-to-browser differences).

 

So, the questions remain:

 

a) Why did these warnings only show up when going to Amazon and CompanionLink? (Signed in or not signed in)

b) Why did these warnings *not* show up when using Firefox? If the warnings were legitimate, the fact that I was not warned when using Firefox would be a huge security issue!

c) Why did these warnings only being to appear after the uninstall/reinsall procedure (again on three computers, 2 using Win7 and 1 using Win10), when OpenDNS was clearly blocking these domains in a significant way well-prior to the ESET warnings? See the UPDATE note above.

 

As another point of interest, this morning when I generated the warnings, the "Reputation" on the warning stated ... green check mark, Discovered 3 days ago. When the warnings were displayed on Friday (two days ago), the reputation line also stated that it was "discovered 3 days ago." How is that possible? Today (Sunday), it should have read "discovered 5 days ago," right?

 

One way or another, there is an issue here with ESET that needs to be addressed, and the response I get on this forum will determine whether or not I feel I can continue to trust ESET to protect the six computers, two phones, and four tablets on my network that currently employ ESET as the primary security solution.

 

I have been using ESET for over ten years, and generally have been a raving fan -- but the events of the last 2-3 weeks (this, the build 396 issue, and the "last update" display issue), have brought into question what is happening on the testing/QA side. Please reassure me ... and let me know what is going on here with this particular non-cosmetic issue.

 

Thank you.

Edited August 7, 2016 by howardagoldberg

[howardagoldberg 14]

UPDATE: So, the certificate - even after "blocking always," still is popping up on occasion with the aforementioned sites. Clicking "block always" again temporarily solves the problem, but it is hard for me to believe that the issue is with Amazon.

 

I am still waiting for some kind of guidance on how to proceed.

 

I have run full-scans of my system using ESET, Windows Defender (Win7), TDSS Killer, and the MS Security Scanner application. All is clean, and in addition, I have OpenDNS running on the router level.

 

The lack of response over the past five days is very concerning.

[howardagoldberg 14]

Issue still persists in 9.0.402 ... any news on what the remedy is?

[Marcos 5,070]

I'm unable to reproduce it. Have you tried contacting your local customer care? I'd also suggest switching to pre-release updates in case the issue was related to the system Schannel.dll which is responsible for establishing an SSL connection.

 

This forum is visited by experienced users and moderated by ESET's staff and is not meant to substitute customer care. If anybody of us is able to help and share our knowledge, we will be happy to do so.

[howardagoldberg 14]

I am able to reproduce this on six computers ... all now running 9.0.402, on Win 7, 8.1, and 10 in both 32-bit and 64-bit variants. Even selecting "block always" only temporarily solves the problem.

 

This is an ESET issue, especially given how specific the issue is: a small selection of websites, and not affecting Firefox at all.

 

Since all the certificates in question are being issued by "Cisco Umbrella Secondary SubCA nyc-SG," I suspect that ESET does not have this issuer in their list of trusted certificate issuers. So, that is really the first question: is this certificate issuer trustworthy? If yes, then ESET needs to add this issuer to the list of trusted certificate providers.

 

​With that said, what are the possible issues if I change the setting of "If the certificate cannot be verified using the TRCA certificate store" from "ask about ..." to "block?" I have not tested this possible resolution, but curious if there would be any ill effects in doing so. I have a suspicion that would solve the problem for me.

[Paul_045 0]

Howard....  I'm NO guru by any means - but I was having the same problem - different server but same problems.

 

I went back and forth with tech a little - but one key thing he said that eased my mind a little to go ahead and try this...

 

in previous version the programmers left the scan of the the SSL turned off, but with Ver 9 they chose to default to "on" and this has created problems - I have been an ESET customer for MANY years and have had Nod32 save my butt on a few occasions and trust them to care for us customers - he suggested turning it off for a few days or updates and then try turning it back on again as the programmers are working on this and other problems all the time, as it will be fixed soon.

 

basically bring your NOD screen up and hit F5 to go the Advanced setup screen and click on the SSL/TLS section and disable your protocol filtering.  That stopped the repetition of the nag screen for me.    He did mention that sometimes to just turn it off, then close out and a few minutes later open it up and turn it back on - This has worked on a few systems.

 

Myself... I'll just give it till tomorow and see if it works.  But I can use my computer now without the nag screen.

Hope this helps

Paul

 

There are posts that go into greater detail about this on this on this board

[Marcos 5,070]

Since all the certificates in question are being issued by "Cisco Umbrella Secondary SubCA nyc-SG," I suspect that ESET does not have this issuer in their list of trusted certificate issuers. So, that is really the first question: is this certificate issuer trustworthy? If yes, then ESET needs to add this issuer to the list of trusted certificate providers.

 

We don't use any own list of CA certificates. If the OS trusts a certificate, then we trust it too.

[howardagoldberg 14]

 

Since all the certificates in question are being issued by "Cisco Umbrella Secondary SubCA nyc-SG," I suspect that ESET does not have this issuer in their list of trusted certificate issuers. So, that is really the first question: is this certificate issuer trustworthy? If yes, then ESET needs to add this issuer to the list of trusted certificate providers.

 

We don't use any own list of CA certificates. If the OS trusts a certificate, then we trust it too.

 

 

Marcos, this honestly does not make sense. I am not getting any warnings from Windows or the browsers in question, only from ESET. And as stated several times previously, the warnings pop up when hitting less than a handful of specific, known, trusted sites (like Amazon.com) when using Chrome, IE, or Edge. The warnings do not pop up when using Firefox, hinting that ESET is either not properly monitoring Firefox, or is "over-reacting" to all the other browsers. Either way, something is amiss.

 

Once again, I can reproduce this behavior on six systems running 9.0.402, with Win 7x64, Win 8.1 x32, Win 8.1 x64, and Win 10 x64.

 

What's more -- to repeat myself again, telling ESET to "always block" the offending certificate has no long-term effect. Once I shut down the computer, the issue presents upon a fresh boot.

 

I have tried turning SSL scanning on and off, and that does not resolve the issue.

 

I have done fresh installs of ESET. Issue remains.

 

OpenDNS is protecting all of these systems at the router level, and I have run scans with ESET, Windows Defender (Win7), and the MS Security Scanning tool -- all systems clean. Also, no other errant behavior is being exhibited by any of these systems, and the websites in question run fine after the warning pops up and I choose the "always block" option.

 

I don't know what the issue is, but I know it is an ESET issue.

 

A note regarding Paul_045's comment: Yes, turning off SSL does "resolve" the issue. What is interesting is that on the Win 8.1 systems, SSL scanning *was* turned off by default! When I first tested for this issue on those systems a few weeks back, the issue did not present initially, which I found interesting. Checking for what was different ... SSL scanning was not enabled during the initial install of ESET on those systems. Turning on SSL scanning resulted in the Win 8.1 systems behaving in the same way as the Win 7 and Win 10 systems.

[chris78 0]

I have a similar problem with Firefox Portable 48 (from PortableApps.com).

I'm currently running Nod32 9.0.386.0 on Windows 7 SP1 64-bit, Home Premium edition.

 

When I visit Amazon sites, the images and css don't load, making the sites unusable. (Today, it even started happening on yahoo.com as well)

 

When I open the browser console, I see the following errors:
 

images-na.ssl-images-amazon.com:443 uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.

Error code: <a id="errorCode" title="SEC_ERROR_UNKNOWN_ISSUER">SEC_ERROR_UNKNOWN_ISSUER</a>

 

 

s1.yimg.com:443 uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.

Error code: <a id="errorCode" title="SEC_ERROR_UNKNOWN_ISSUER">SEC_ERROR_UNKNOWN_ISSUER</a>

 

I can't update my addons in Portable Firefox (whether manually or automatically):

 

 

addons.cdn.mozilla.net:443 uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.

Error code: <a id="errorCode" title="SEC_ERROR_UNKNOWN_ISSUER">SEC_ERROR_UNKNOWN_ISSUER</a>

 

The yahoo/amazon problems don't occur with Google Chrome Portable or with non portable Firefox 48. Non portable Firefox can also update its addons without error.

 

My SSL/TLS settings are the default ones. In the list of SSL/TLS filtered applications, Firefox Portable, Chrome Portable & non portable Firefox are set to "Auto".

When I set Portable Firefox to Ignore in the list of SSL/TLS filtered applications, all aforementioned problems disappear.

 

On another computer (Windows 7 SP1 64-bit, Home Premium edition) running Nod32 7.0.325.1, Firefox Portable doesn't have any problem.

[Marcos 5,070]

I have a similar problem with Firefox Portable 48 (from PortableApps.com).

I'm currently running Nod32 9.0.386.0 on Windows 7 SP1 64-bit, Home Premium edition.

 

This is normal and expected. The ESET Root certificate is not imported into portable Firefox automatically so you can either export it and import it manually or disable SSL/TLS filtering (not recommended). Unlike v9, older versions had SSL/TLS filtering disabled by default which is why it works without issues with older versions.

[chris78 0]

 

I have a similar problem with Firefox Portable 48 (from PortableApps.com).

I'm currently running Nod32 9.0.386.0 on Windows 7 SP1 64-bit, Home Premium edition.

 

This is normal and expected. The ESET Root certificate is not imported into portable Firefox automatically so you can either export it and import it manually or disable SSL/TLS filtering (not recommended). Unlike v9, older versions had SSL/TLS filtering disabled by default which is why it works without issues with older versions.

 

 

Thank you very much for your help. I exported the root certificate then imported it into Firefox Portable: it fixed my problems.

Is this a 1-time thing or will I need to repeat it with every Nod32 minor/major update?

Edited August 25, 2016 by chris78