[Attempt to add root cert. Failed]

I have temporarily disabled the option in NOD32 to add the cert into known browsers so as to curtail the pages of these errors in the log files. I totally agree Eset should generate less of a generic error message so that the end user can determine exactly which browser is causing the issue. 

I have no idea what "browser" here is causing the issue since Firefox is not installed and as far as I can determine Chrome which is currently my default browser has the cert installed.

[Attempt to add root cert. Failed]

I am about to give up on Eset.  Since using the normal uninstall of firefox beta and nightly rebooting and installing NOD32 proved to not solve the problem I reinstalled FF beta and then used Revo Uninstaller Pro to delete all traces of firefox from registry and Win10. I ensured that TLS was disabled. Rebooted started up procmon and sure enough, as soon as I re-enabled TLS the error occurred at 10:12 PM.  

I currently do not have the strength nor desire to install Firefox Nightly reinstall uninstall and test today so I am attaching the Procmon and ESET log gather files

NOD32CertError.zip eav_logs.zip

[Attempt to add root cert. Failed]

4 minutes ago, justme12 said:

Zip the Procman files and they will be small enough to attach if you want to send to ESET tech.

I had the same results as you yesterday when I removed FFox.  HOWEVER: today I downloaded Revo uninstaller Pro and removed way more FF reg values than the normal uninstall of FF accomplishes.  THAT seems to have done the trick. I have no more events.

Though I don't see why one has to go through this whole process.  ESET should install regardless and if there is an issue give notice. Must say, I have lost considerable confidence in the software as from a TLS issue that may have left one vulnerable and never knowing unless looking at the logs and then google researching what they mean. 

Oh ok thanks for that tidbit. Will indeed try the Revo Uninstaller Pro use with Firefox still uninstalled and sigh again redo the log collection yet again if the issue still occurs after the cleaning with Revo.

 

[Attempt to add root cert. Failed]

 

 

 

2

19 hours ago, Marcos said:

In order to investigate the issue, please provide:

- Logs collected with ESET Log Collector when the error occurs
- A Procmon log from time when you disable and re-enable SSL filtering after a reboot. Stop logging when an error importing the root certificate pops up.

NOD32 was still uninstalled.

I uninstalled Firefox Nightly and Firefox Beta via WIndows 10 Remove Apps option in Control center. I then rebooted

I then installed Eset 12.1.34 and rebooted. Right off the bat the error regarding cert error showed up in the log files even before I was able to disable TLS.

I disabled TLS rebooted. I started Procmon up and captured the events and then enabled TLS and like clockwork, the log showed the same CERT error. This all happened without any Firefox browser installed in WIndows10.

I can not attach the logfiles here due to the size of the Procmon files. I have uploaded them elsewhere and can provide a link.

[Attempt to add root cert. Failed]

23 minutes ago, itman said:

BTW - which Eset Event Log was full of these entries; no one ever mentioned that? Also a posting of the actual event log entries would have been helpful.

I had 2 months of log entries which repeatedly showed the same error message along with the updates to virus definitions but that was it in the logs. I had no clue to notification whatsoever that this issue even existed.

I just stumbled across the issue because I went to the Eset logs looking for information to rely to someone about a Pup alert for a website. Only then did I discover approximately 1700 entries a vast majority of them being these alerts about Attempt to add root cert. Failing. Only other entries in the log was the regular definition updates.

[Attempt to add root cert. Failed]

12 minutes ago, justme12 said:

*** Now what concerns me. Is there a simple way notifying of the event?  How often do people view their logs if they view at all. 

Exactly why I am wondering how many other Eset users logs are full of this error and they have no clue that this is happening. 

it is too bad that Eset is also generating such a generic error message without identifying the browser it is having an issue with. It would help reduce the countless hours of hunting blindly. It is not uncommon these days with Windows 10 to have multiple browsers installed.

Why did you resort to uninstalling  Firefox using a Pro version of Revo. Have you attempted to uninstall Firefox using the normal means in Windows10 via the control panel? What version of Firefox did you have installed by the way?

[Attempt to add root cert. Failed]

1 hour ago, itman said:

To begin with, I have never had FireFox installed on any Win 10 build on my PC. It currently has x(64) 1809 installed. As such, I have no old and possibly borked Firefox files and registry entries from prior versions of it, etc..

To get to the bottom of this current FireFox baloney in regards to EIS 12.1.34, I went to the Firefox web site and downloaded and installed it. I believe the current ver. is 66. I then opened FireFox and checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was not there as expected.

I then rebooted the PC to try to simulate the behavior posted in this thread; namely if  "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED"  alert/log entry would manifest. It did not.

I then again checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was there as expected: 

 

All this leads me to believe that whatever is causing this behavior on user's PC's has nothing directly to do with the Eset installation but rather, some misconfiguration issued with their current Firefox installation.

I would advise uninstalling Firefox, clearing out all past remnants of it on your OS installation, and rebooting. Then install the current version of Firefox from the Mozilla web site and repeating the installation steps I posted above. As far as running development or beta versions of Firefox concurrently with Eset, you do so at your own peril; just like if you were running a pre-release ver. of Win 10. 

First this installation of Windows 10 and in turn all of the applications in my case is less than 5 months old. 

Second how was it determined that in fact this is due to Firefox browser and not another browser. As I mentioned elsewhere in this thread every browser I could check (except for MS Edge) appears to have the appropriate cert installed in the browser's Authorities certificate store. In the case of Firefox I even resorted to importing the cert with no effect on the error.

As I write this I have not yet decided what my next step is regarding Eset as it is still uninstalled. If I uninstall Firefox beta and uninstall Firefox nightly, install Eset antivirus are you saying that this error is no longer going to occur?

[Attempt to add root cert. Failed]

As I said in a prior post I wonder how many other systems that logs are being filled with these types of errors and the computer owners have no idea that its occurring? I just happen to stumble across it yesterday. I had been using Windows 10 without Eset on multiple systems with Windows10 and I am now wondering if the reason why its been happening for 2 months here which was the only one with Eset was because that was when Eset was installed in Windows10.

I have been using Eset for years and had recommended it to clients and friends in the past. Going to have to touch base with some users to see if in fact this is a wide spread issue.

[Attempt to add root cert. Failed]

2 hours ago, justme12 said:

As requested:  Also removed and reinstalled ESET - no change.  2 events occurred at 11:46:24

procmon.zipUnavailable eis_logs.zipUnavailable

OK thanks for that info. Was debating on whether to retry the reinstall to see if it fixes the issue but it apparently does not. Are you using any additional security software like Malwarebytes Pro like I am on Windows10 Pro?

[Attempt to add root cert. Failed]

49 minutes ago, itman said:

It appears to me this "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" message is being generated when Eset can't access Chrome's or FireFox's certificate store to verify that the Eset certificate is installed. As has been noted, the Eset certificate actually exists in these browsers and yet the Eset log event keeps recurring. This activity would be indicative of some type of permissions issue in regards to Eset accessing either Chrome or FireFox internally. Is Chrome's or FireFox's sandbox feature enabled by anyone having this issue?

When Eset was installed here on Windows 10 Chrome was the release version with a standard installation. Firefox was the beta version as well as a nightly release both with the standard installation. I do not remember enabling any sandbox option in either browser. Both browsers are of course still installed here but Eset remains uninstalled for now. Is there no way of Eset indicating which browser it has cert installation issues with?

With me I am always testing/trying new browsers and currently have 3 versions of Edge (Win10 native plus 2 Chromium pre releases) along with Chrome, Brave beta  and Firefox plus Windows10 IE.

[Attempt to add root cert. Failed]

Well for me I also noticed that Eseential PIM Pro 8.5 which is an app that I use to keep contact information and appoints etc on Windows 10 would no longer sync up to my Google account. It was throwing a HTTPS denied error. Since I needed the sync to work between my iOS devices I uninstalled NOD32 12.1.34? via Windows10 App center. The Essential PIM issue was fixed.

Right now I am using Malwarebytes Pro along with Windows10 Windows Defender. When I get some time I will try reinstalling NOD32. The only reason why I noticed this error is that I went looking for other information regarding a block that ESET did on a site because it deemed it was  source of Pup.  Only then did I see over 1200 entries of this error over the last 2 months.

I just wonder how many other people are having this issue without knowing its happening

 

[Attempt to add root cert. Failed]

1 minute ago, stackz said:

If you have a master password set for firefox logins and passwords, then this is what worked for me.
Disable SSL scanning in Eset, then temporarily disable the master password in firefox. Enable SSL scanning and check whether you still get the error notification. Hopefully it is now fixed. Finally, set your firefox master password.

No Master Firefox password since I am using Lastpass for password storage. Even switch Chrome to the default browser did not help. Does Eset use the Windows10 app list for the known browser to import the cert into?

 

[Attempt to add root cert. Failed]

Yes it probably does but ever browser I have installed has this cert installed. I could not find any way of checking the original MS Edge browser certs I rarely use the original MS Edge as a browser. Firefox and Chrome with MS Edge Chromium on occasion. All of which have the Eset cert installed. I do use Thunderbird email client but that appears to have the Eset cert that expires on May 5, 2029 w a SHA Fingerprint of F1:31:6C:34:83:3A:B7:1F:58:8F:A6:93:35:2C:F5:8F:39:EF:ED:F0 installed.

 

As soon as enable the TLS option or the option to Add Root cert blam I get the errors in ESET log. I wished the heck the log file would indicate what particular app/browser its supposedly having issues with!

[Attempt to add root cert. Failed]

I disabled the option in ESet to Add Root Certificate to Know browsers.

[Attempt to add root cert. Failed]

Firefox both of them have the cert already installed as well as Brave Beta. Just wished the heck the log file in NOD32 would indicate what web browser its complaining about. Perhaps its a red herring since I checked Firefox, Brave and even Edge Chromium and  IE  all have the cert installed. With me if I disable the TLS option and delete the events showing the error for May in the log file as soon as I re-enable the option with no browsers open it shows the error in the Logfile

[Attempt to add root cert. Failed]

I also have the same problem and disabling TLS rebooting and before running any application in WIndows10 x64 I re-enable TLS and as soon as I do I get the error. I have Firefox beta and nightly both x64 installed along with CHrome, Brave Beta and MS Edge Chromium Dev and Canary. This has been going on for about 2 months well before I installed MS Edge Chromium.

[Eset blocks IP but Virustotal does not]

I have ESET NOD32 Antivirus 11.2.63.0 installed on Win7 x64 here and using Symenu app to download updates to a series of utilities I use. When it goes out to get two errors when it attempts to connect to a particular domain:

"My Antivirus is blocking SyMenu from downloading Adaware and several other utils because the Polish site that is using to serve up these files is on a blacklist of malware sites. Is there no way of changing the download source for utils in the SyMenu app?

Time;URL;Status;Application;User;IP address;SHA1
10/3/2018 1:30:40 PM;hxxp://dpcdn-s13x.pl/narzedzia/GPU-Z.2.11.0.exe;Blocked by internal IP blacklist;

AdwCleaner 7.2.3.0 The remote server returned an error: (403) Forbidden.Please retry
GPU-Z 2.11.0 The remote server returned an error: (403) Forbidden.Please retry
HWiNFO 5.88 The remote server returned an error: (530) Not logged in.The remote server returned an error: (530) Not logged in.Please retry
Mozilla Firefox Portable 62.0 The remote server returned an error: (404) Not Found.Please retry"

Yet when I do a scan on that domain using Virustotal it shows no issue with Eset https://www.virustotal.com/#/url/a7b9d6fe19affd1ddf45f2f8ceb3590181fe5d7d6741aa7eec1cf13dbcff27ff/detection is this blacklisting on the domain on my computer warranted?

 

[Free FileSysnc false positives]

I tried downloading Free FileSync syncing app from https://www.freefilesync.org/ and got the following warning

E:\Downloads\FreeFileSync_9.0_Windows_Setup.exe » INNO - a variant of Win32/FusionCore.I potentially unwanted application

 

Yet when I scanned it via VirusTotal.com it showed no issues at all.

 

[Posssible false positive]

I was wondering if someone could check into a possible false positive I got for a Win32/Olmarik.TDL4.Trojan after I downloaded and installed hxxp://www.surfright.nl/en/kickstartto a USB flash drive. I booted the flash drive, which was recently long formatted under Win7 shut the machine down and booted normally. WIthin several minutes Eset 7.0.317.4 alerted me that Win32/Olmarkig.TDL4.Trojan was on this computer. The Eset removal tool hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3339 did not find anything neither did a bunch of other utils including TDSSKiller.

 

I am wondering whether the above util is actually installing a rootkit or whether this is a false positive by Eset NOD32.

 

To fix the problem I booted with a Windows7 install disk and did a bootsec install followed by a fixmbr. Subsequent scans by NOD32 show no infection.

[NOD32 7.0.32 prevents access to web interface of Gateway]

Yup that is what it was. I added the single IP to the excluded list and now am able to access the web interface.

[NOD32 7.0.32 prevents access to web interface of Gateway]

I have a Win7 x64 w NOD32 ver 7.0.302 Pace 5168N-010 Internet Gateway box supplied by my ISP. It has a web interface accessible via 192.168.100.254. The other day I tried accessing the interface from Windows 7 x64 via the LAN here through IE 10, Chrome  31.0.1650.34 beta-m, Opera 17.0.1241.45 via hxxp://192.168.100.254 and was told that the page could not be displayed. For some reason Firefox 25 has no such problem.  A Windows 8.1 box with NOD32 Ver 7.0.302 and IE 11 and Chrome has the same problem. An XP computer with NOD32 version 6 has no problem with IE 10 or Chrome.

 

 

On the Win7 x64 box I tried using https rather than http. I ignored the security cert warning and was able to access the box's web interface! problem using hxxp://192.168.100.254.

 

On my Win7 x64 box I disabled NOD32 and had no problems with IE, Chrome nor Opera. Same thing with the Win 8.1 box. Why is NOD32 7.0.302 blocking access to this address?