Jump to content


Most Valued Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by itman

  1. https://d4stiny.github.io/Several-Critical-Vulnerabilities-on-most-HP-machines-running-Windows/ I personally would opt for the uninstall option.
  2. You should be able to uninstall the version of Smart Security on the laptop via the way you uninstall any other app. Namely, open Control Panel -> Programs -> Uninstall a program. Reboot after the uninstall is completed. Then download the current version of Smart Security as done previously and install it on the laptop.
  3. Assuming you're using Win 10, refer to this article: https://support.microsoft.com/en-us/help/4028379/windows-10-how-to-use-remote-desktop . This also only applies to client to client PC connections. To utilize full RDP connectivity in a client to server scenario, you need to have Win 10 Professional or above installed. The Win 10 Home version does not support full RDP connectivity. An alternative here is to determine if your workplace allows remote connection via a VPN connection.
  4. I really don't don't know what you are referring to here. Windows Defender Controlled Folders option only applies if Windows Defender is the active real-time protection solution. If you have Eset installed, it is the active real-time solution and should be reflected as such in Windows Security Center. Activating the Windows Defender Periodic scanning option does not enable the Controlled Folders feature. In regards to this: I have never seen like setting. I do suspect however it might be indicative of both Eset and Windows Defender real-time scanning being enabled which should not happen if Eset was properly installed.
  5. Sadly, this issue isn't restricted to fake certs.. Legit certs. have been stolen. The attackers then proceed to sign their malware code with them. In a couple recent incidents, stolen/misappropriated driver certs. were used. Now you can't get better than that. Win 8.1/10 Secure boot will protect you here but you need to have the hardware to support it. Bottom line - anyone in "the security know" will flat out state the whole certificate concept is completely broken. But that's a topic for wilderssecurity.com or malwaretips.com posting and discussion.
  6. The above malware reference also brings up the issue if this move by FireFox/Eset to defer to the Win root CA store is the most secure thing to do?
  7. @Marcos , is Eset Online Scanner Quarantine file retained after it's associated directory is removed? If so, Eset Online Scanner Quarantine could be reinstalled. Then the previous Quarantined item restored. Reboot and see if that resolves the slow startup issue.
  8. It really appears everything is OK with Windows Security Center and Eset's registration of itself within. I would think that this flickering you are observing is more related to an issue with your graphics card/chip. Or possibly an issue with the driver/s it is using.
  9. Interesting. Appears the Eset cert. in the Win root CA store got corrupted somehow. Never seen that one before. However, there are malware that have been known to deploy certmgr.msc; e.g. https://thehackernews.com/2018/07/cryptocurrency-mining-ransomware.html . Maybe something escaped your VM with all the malware testing you do?😬
  10. This is the standard display from Firefox when a third part root certificate is being used. It has always been displayed as such. You probably just never checked the HTTPS certificate status previously. -EDIT- The message display is slightly different now that FireFox is now deferring to the Win root CA store; i.e. security.enterprise_roots.enabled.
  11. That's strange. Really don't know why a License key would be required for an uninstall. Here's a link on how to both use and download the Eset uninstaller tool for whatever Win version you have installed: https://support.eset.com/en/kb2289-uninstall-eset-manually-using-the-eset-uninstaller-tool . Note this must be run in Win Safe mode. Note: If this is a Win XP device, the OS needs to be upgraded to use any current Eset product. Once that hopefully successfully completes, boot back into normal Win startup mode. Download the current version of Smart Security Premium from here: https://www.eset.com/int/home/smart-security/download/ and install it. Then use the upgraded License key you purchased to activate it.
  12. Based on the screenshot you posted here: https://forum.eset.com/topic/23125-certificate-issues-for-firefox-740-64bit/?do=findComment&comment=111963 and per @SeriousHoax previous reply to you, Eset's cert. is being used by FireFox w/o issue. So I really don't know what leads you to believe it is not.
  13. I have a theory of what is going one here. It manifests when multiple Eset root CA certificates exist in the Windows root CA certificate store. Eset's root CA certificate is signed with a private key. That key is stored somewhere in the directories Eset creates at installation time. Whatever Eset certificate FireFox is extracting from the multiple ones stored in the Windows root CA certificate store has a private key that does not match the one currently stored in the applicable Eset directory. Hence use of the certificate extracted is rejected by FireFox. I would assume that the latest dated Eset root certificate in the Windows root CA certificate store is the one being used by the current Eset installation but there is no guarantee that is the case. Refer to the below screen shot: 1. Open Eset GUI and navigate to Web and Email settings. 2. Open SSL/TLS settings. 3. Under Root Certificate section, mouse click on "View certificate." 4. Mouse click on the Details tab. 5. Scroll down to a line named Thumbprint. Mouse click on it which will duplicate the value to the box below it. Copy that thumbprint value and save it somewhere. 6. Exit the Eset GUI. 7. Enter certmgr.msc in Win 10 desktop Search bar. 8. Open certmgr. Then open Trusted Root Certification Authorities -> Certificates. 9. Now compare the prior saved Eset cert. thumbprint to the thumbprint of all Eset certificates shown. 10. When a match on thumbprint is found, keep that certificate and delete all the other Eset certificates present. 11. Exit certmgr. At this point, FireFox should only access the remaining Eset root certificate in the Win root CA store and there should be no longer any private key issues with FireFox's use of that certificate.
  14. "To add more confusion to the mix," my FireFox updated to ver. 74.0.1.
  15. I also just noticed that you are attempted to upgrade Eset Smart Security 9. That product is no longer supported: https://support.eset.com/en/kb3678-is-my-eset-product-supported-eset-end-of-life-policy-home-products . This could be the issue. I suspect that what you purchased perhaps is a two seat license for Internet Security? I know Eset Smart Security 9 is the last version supported on Win XP. But again, it shows end-of-life as of 12/2019. As such, I don't see how you could have purchased an upgraded license for it.
  16. https://support.eset.com/en/kb7297-resolve-act-or-ecp-errors-during-activation-home-users Did you purchase your upgraded license from an authorized Eset source in the U.S.? Such sources would be the Eset U.S. web site, an authorized Eset reseller in the U.S., etc.. Also make sure that U.S. is selected as the country during installation. This should have been done automatically since the first three characters of the license key indicate country; e.g. USAX- .........
  17. If "worse comes to worst," you can always switch to pre-release updates. Ver. 13.1.24 should then be available for update. Appears ver. 13.1.24 contains Internet protection module 1395.
  18. Check the Eset cert. in Firefox and verify its OK. Then mouse click on Edit Trust tab and verify that its set to identify web sites.
  19. One thing that needs noting as far as Internet protection module 1395. It has a date of 3/31/2020 associated with it. So unless you have this module in your Eset installation, Eset's root CA certificate still needs to be installed in FireFox's Authorities certificate store.
  20. I can't connect to this domain in FireFox:
  21. At this point, it makes no difference since you have added Eset's root CA certificate to FireFox's Authorities store. Note that by default, FireFox will search there for a certificate. If not found, it then will search in the Windows root CA certificate store. Just realize that it appears Eset is now no longer updating FireFox's Authorities store at installation time. Or for that matter, after Eset installation via prior stated update methods. Appears your issue was related to this:
  22. That could be the issue since I don't know what Eset certificate Firefox would use when multiple ones exist now that it is deferring to the Windows root CA certificate store. When Eset is installed, it adds its certificate included within the installer to the Windows root CA certificate store. Likewise when Eset is uninstalled, it is supposed to delete its certificate from the Windows root CA certificate store. Note that an Eset in-product upgrade does not replace the original Eset Windows root CA certificate. However, I believe an off-line download and install on top of existing Eset installation will install a new Eset certificate. This is how most likely you ended up with multiple Eset certificates in the Windows root CA certificate store.
  23. Based on your screen shot, you don't need to add Eset's root CA certificate to FireFox's Authorities certificate because by default, FireFox will look for it in the Windows root CA certificate store. Therefore, the next thing is to verify that Eset's certificate exists there and is a valid certificate. Do the following: 1. Enter certmgr.msc in the your desktop search window. 2. Open certmgr. 3. Verify that the Eset certificate exists in Windows Trusted Root Certification Authority per the below screen shot:
  24. Since I have this module, I did the following: 1. Deleted Eset's root CA store certificate from Firefox's Authorities certificate store. 2. Shutdown FireFox. Restarted FireFox. Zip issues on any HTTPS web site where Eset's root CA store certificate is being used. Next via about:config, checked the status of security.enterprise_roots.enabled. Note that I had not previously entered this value manually. See the below screen shot: Note the lock symbol? Appears this is something FireFox creates internally to prevent modification of that setting? Finally, note the two highlighted security.disable settings. I believe the highlighting indicates a change from default fault which I assume is "true." Again, this is something FireFox did internally; or perhaps by my manually accessing those via Firefox security options; or Eset did prior to module 1395? What I am speculating is that perhaps user manual entry of security.enterprise_roots.enabled is what is the OP's problem? That perhaps it is interfering/overriding Firefox's like created setting?
  • Create New...