cmit

@itman this is not the 100% answer you have been looking for because it is only the popup notification disabled but the Firefox itself the first time did show the yellow untrusted alert that shows the option to accept and continue for users' Firefox but not all. thanks but the people from ESET still do not have any answer to my original question (my first two posts) why we had to delete the ESET certificate from Firefox's Certificate Manager -> restart computer for every user of the same computer in order to have an option to "accept and continue" or be able to just able to view websites right away? This is getting more confusing is the issue from ESET, from Firefox, or from both, or simply our own ESET policy setting? From other threads other people have posted on ESET Forum, i don't think we are the only ESET customer having this inconvenient issue.

@Marcos may i please also have other comments from people from ESET. It's not fair just @itman looking into this helping a lot.

Screenshot below my setting should answer your question. Our "Display alerts" and "Display notifications on desktop" is set to disabled. Is this the reason we didn't get that red and yellow alert? Some of our computer's Firefox do display the yellow untrusted alert within the browser (not the ESET popup) though. Some of our staff freak out when seeing popup from antivirus program.

how is your IE11 verification procedure on ESET SSL certificate related to the issues I have been talking about since all ESET certificates are valid (not expired)?

this is the opposite from what you mentioned before:

@itman Could you give example of the man-in-the-middle activity on our Internet connections? Do you mean could be related to our ESMC setup, our domain controller policies, or from possible external threat activities? I am still waiting for @Marcos or someone else from ESET to explain why you and I both have the badssl.com result (ESET non-alert status) instead of ESET's alert.

Both the ESET forum and the badssl.com/dashboard websites state ESET SSL Filter CA on all three tested computers but two of three tested computers' IE's ESET SSL Filter CA's thumbprint do not match the ESET SSL Filter CA in the certmgr.msc's Windows Trusted Root Certification Authorities folder. What does this mean? How is this related to the issues we are having? All certificates are valid (not expired). Every time there's newer version of ESET EndPoint AntiVirus released, we trigger update from ESMC. Would this be the cause of some thumbprint not matched? I need at least two people from ESET to comment on the issues I'm having. @Marcos @MichalJ

for three testing computers. Don't know why the date valid from date of today. Did not reinstall ESET.

Screenshots below what from three test computers I tested: I have no idea. Maybe (don't quite remember) I have deleted the ESET certificate authority from Firefox -> reboot computer. ------------------------------------------------------------------------------------ @itman sry don't quite understand what you mean"If the Eset root CA certificate exists and in a valid status and/or does not exist ". My ESET root CA certificates do exist and are in a valid status but what does then "and/or does not exist" mean? ------------------------------------------------------------------------------------ Now testing on a 4th computer. When using Firefox to connect to my test router, Firefox shows this But when using IE11, the test router's login page (in https) shows up fine. The certmgr.msc does show valid ESET certificate on this 4th computer as well. This 4th test computer also does not show ESET alert on Firefox and IE when going to badssl.com/dashboard (shows the red sha1-intermediate and dh1024 connected).

Yes about 2 months ago but got to nowhere. Created another ticket today. Will probably get another reply with general questions from Tier 1 ESET Support after 2+ days (1 day if lucky, usually the ESET Standard Business email support's reply is slow in my experiences so far).

The server that has our ESET Security Management Center running also has ESET File Security running.

My main domain controller server has ESET File Security running. Could this be a suspected issue?

Thank you @itman @Marcos ESET guru guys please fix ESET about this certificate nightmare. Thanks.

@itman "Browser alerts" from ESET when the badssl.com test was running? No. This is why I asked Are all the badssl.com's "Not Secure" result supposed to be all green (cannot connect) since you said I "passed all the tests; i.e. "cannot connect." "

Are you talking about alerts from ESET or from this baddssl.com website? No alerts from ESET. But has a few red connected results on Firefox and Chrome. Are all the badssl.com's "Not Secure" result supposed to be all green (cannot connect)?

No, no ESET warning at all on three computers tested (Firefox and Chrome) when going to https://badssl.com/dashboard/ Yes on all Chrome and Firefox that has ESET certificate installed. This method did not work on that 1 of 3 test computers' Firefox newly installed. But this computer's Chrome already has ESET certificate and did detect both the eicar_com.zip files.

What do you mean getting rid of Comodo code signing cert? If you remove it from your browser, doesn't that put your web browser at risk of your antivirus not protecting the browser? (same purpose of enabling ESET SSL/TLS protocol filtering)

No. But I noticed one of the computers that just had a fresh latest Firefox installed does not have ESET certificate exist when I went to this Firefox's Certificate Manager (still no ESET certificate in this Firefox after computer restart). Basically, as long as the ESET certificate is not within the web browser, all these issues go away, but loses the meaning and purpose of the "https everywhere".

Tested on three computers, these is what I saw on Firefox, Chrome, Edge, IE.

Same issues still happening often on multiple domain users (some from same computers but logged in with different Windows accounts). The suggested solutions in this link (https://support.eset.com/kb5833/?locale=en_US&viewlocale=en_US) also wastes time for system administrators. These two additional options ("SSL/TLS protocol filtering mode" and "List of SSL/TLS filtered applications") are just temporarily workarounds and not really working in all four scan actions (auto, scan, ignore, ask) we tested. Putting Internet Explorer, Firefox, Chrome into the excluded application from SSL/TLS scanning contradicts with what's mentioned about the "risk of disabling SSL/TLS protocol filtering". If nobody from ESET can confirm if this is Firefox's issue (or Chrome or IE) or ESET's or our own issue, then two "ultimate" solutions can think of: 1. set an ESET policy to just disable SSL/TLS protocol filtering for all domain computers. 2. totally uninstall ESET and look for other antivirus alternatives. This is probably the moment somebody from ESET gonna ask for log collectors again on our computers (mostly at different location) and still might not have a conclusion. I have enabled the full diagnostics on a test computer but only can see the SysInspector. Log Collectors and Diagnostic logs are empty even after requested and turned ON. (Talked to two people from ESET Business Support chat but in my option they lack experiences about this part and just sent a few ESET Online Help links for customers to read without a full solution/explanation about these issues.) What's the purpose of using ESMC to check domain computers convenient if there's file size limit for log collector? (https://help.eset.com/esmc_admin/70/en-US/client_tasks_diagnostics.html)

Is this Firefox's issue or ESET's or both? (or our own issue?) I believe my case is not related to this anymore (https://www.ghacks.net/2019/02/01/mozilla-halts-firefox-65-distribution-on-windows/) because the error message no longer says SEC_ERROR_UNKNOWN_ISSUER after Mozilla released fixed update. Cannot say if this is affecting all our domain users but most of our users still having the "SSL_ERROR_BAD_CERT_ALERT" without any options to select. The ONLY proper solution is to delete the ESET certificate authority from Firefox -> restart the computer (not log off) -> then will be able to access websites right away. If not right away, at least Firefox would shows "Warning: Potential Security Risk Ahead" to allow user to have the "Accept the Risk and Continue" button to click. We had to repeat this "solution" on every domain user of the same computer. (i.e. if there are 5 different Windows user accounts use the same computer, had to restart this same computer 5 times. Waste of time.) This issue also happening on brand new computer with fresh latest Firefox installed. ESET tech support had suggested as follows: - temporarily disable the policy - on a client disable SSL/TLS filtering and make sure the error doesn't occur - reboot the machine - without launching any applications, re-enable SSL/TLS filtering - wait ~2-3 seconds, then launch a browser and open an https website But this solution did not work. I even clean-uninstalled and re-installed my ESET EndPoint AntiVirus. Any ultimate proper suggestion/solutions? I have already collected and submitted the ESET logs (collector) but nobody from ESET has detailed explanation but simply suggested a work around. At least we need to know is this ESET's or Mozilla's issues or both or is this something else just never ends?

my concern and question is is this Mozilla's issue or ESET's issue? Even thought ESET "fixed it" (not sure if temporarily) by updating the detection engine but WHY did the ESET treat this .xml file as a trojan? Could any experts from ESET please explain in details? If this is the "big problems" of the firefox world, need to let Mozilla know.

So this is ESET's fault? What's the root cause of this FP? What's the updated detection engine version #? What is this VisualElementsManifest.xml for? I see Chrome and Windows tile also has this .xml file. What should be done with those already "affected" computers? restore from quarantine? so this "cleaned by deleting" really means "moved" to quarantine?

Is this Mozilla, Microsoft, or ESET's issue? Just happened today multiple (number still increasing) of our domain computers' ESET Endoint AntiVirus caught this "firefox.VisualElementsManifest.xml" as "a variant of Generik.HBKPFTF trojan". This event also happened on a new firefox.exe just downloaded from the official Firefox.com website for installation onto a new computer.

Does the Scan function (In-Depth) scan more areas when EDTD is enabled vs no EDTD? I have also noticed that after the EDTD is enabled for our workstations, it takes 1.5 or double of time to complete the scheduled periodic in-depth scan. i.e. - usually takes 4-4.5 hrs without EDTD - with EDTD enabled, takes at least 6 hrs (or even 9 hrs) to complete the scan. This is another question related to the justification of if the EDTD really necessary (more $$$ times # of computers) or are those computers without EDTD (only EndPoint AntiVirus or EndPoint Security or File Security) basically have much higher chances of getting hit by threats? i.e. For the EDTD licenses cost, we would have to buy the bucket of 250 licenses even though we only around 190 devices needed. No option to allow customers to manually choose exactly how many licenses only required to purchase.