offbyone

Yes, version 9.0.12013.0 was the last affected. Newer versions were not.

To put it right, I meant a newer CE module than 2099.x. ie. version 210x.

If I remember correctly, SS filtering used to be disabled by default in older versions of Windows server products. Therefore you must enable SSL filtering via a policy:

Note that SSL/TLS filtering may cause issues with some SSL/TLS enabled server applications so it's possible that you will have to exclude them.

I will also add that people "better get cracking" on applying these KB updates. Based on this recent posting: https://forum.eset.com/topic/38212-install-failing-on-2008r2-servers-with-acs-support/ , updating is far from smooth.

It is actually Microsoft that sunset support for cross-signed root certificates: https://knowledge.digicert.com/alerts/Kernel-Mode.html.

Obviously, you will be able to apply the applicable KB for the referenced OS version.
The problem is there is no reference to Win 10 1903 in https://support.microsoft.com/en-au/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 . As such, it can be assumed it can't be updated via KB method.

Enabling ERRM increases attack surface, especially when work mode is set to "all operations" as opposed to "safe operations only".  An attacker could theoretically detect the application that has RMM access allowed and inject itself into it. On the other hand, we are not aware of such misuse of ERMM to date.

As I understand ESET Bridge is only useful if you have a homogeneous environment with Endpoint Security 10+, is that correct?
So if I have some Endpoints with version 9, I cannot use Bridge?
 

Yes, you are correct the Bridge is compatible with Endpoint later than version 10. For more you can find in our documentation in case of any further questions https://help.eset.com/ebe/1/en-US/ .

Hello @thae,
some features, like the "HTTPS traffic caching for ESET security products" are supported on the listed products / versions only, but the ESET Bridge can be used as a proxy 1. to cache the standard http traffic and 2. to be used as gateway in a network without direct internet access...
Peter

Just verified.
The warnings are still visible in the console but disappeared at the client side.

From what I understood the alert was removed from the client side, but not from the management console, which makes sense IMHO.

Here the alerts have gone.
Seems that ESET fixed the issue "online" without the need to deploy anything. We use on prem management.

Please kindly do not deactivate the notifications or you won't probably reactivate them later and missing some important notifications in the future may lead to issues if our message cannot be delivered. We are working on a solution when managed Endpoint won't display the notification in gui. It may take a couple of days and we expect it to be released next week.

For those of you affected by this problem I have found that you need to programmatically disable the "Get notifications from these senders" by editing the wpndatabase.db on everyone's computer. Here is a basic PowerShell snippet of how I accomplished this:
$connString = ("Data Source='" + "$env:LOCALAPPDATA\Microsoft\Windows\Notifications\wpndatabase.db'") $con = New-Object -TypeName System.Data.SQLite.SQLiteConnection $con.ConnectionString = $connString $con.Open() $cmd = $con.CreateCommand() $cmd.CommandTimeout = 10 $cmd.CommandText = "UPDATE [HandlerSettings] SET [Value] = 0 WHERE [HandlerSettings].[SettingKey] LIKE 's:toast' AND [HandlerSettings].[HandlerId] IN ( SELECT HS.[HandlerId] FROM [HandlerSettings] AS HS INNER JOIN [NotificationHandler] AS NH ON NH.[RecordId] = HS.[HandlerId] WHERE HS.[SettingKey] LIKE 's:toast' AND NH.[PrimaryId] LIKE 'Microsoft.Explorer.Notification%' )" [void]$cmd.ExecuteNonQuery() $con.Close() This is probably bad code but I am a systems administrator not a programmer. Systems administrators are responsible for their infrastructure and we do not need to be dictated by people complaining about a yellow popup describing something that will happen over a year from now. Every environment is different and it's a shame ESET doesn't realize this.

This is OK as a personal preference.
But keep in mind that there are other companies which have different demands. On large Enterprises with lots of clients and mission critical systems, rolling out new versions take much of human resources and time.
So if you have a very stable and reliable software running, and 7.3.2055 is as such, it can be good advice to run that version until EoL and use the free human IT resources to push other IT projects where situation is different.
At the end it is good advice to let the customers decide and not force them to cut off a software version 13 month before EoL.

At Wyatt's suggestion, I have posted a feature request in this thread: 
 
It's not showing there yet due to content moderation policies, but should show up soon. on page 4.

In a managed environment, like we're using with ESET Protect, we absolutely need the ability to suppress end of life warnings. It makes no sense to warn users that their fully functional client will have a problem 12 months from now.  They can't do anything about it other than worry and clog our helpdesk support.

Give the IT administrators better insights into upcoming end-of-life dates right in the web console rather than making us proactively track down a website within your support pages.    I'm in the console on a daily basis and there'd be plenty of opportunity to warn me that 9.0.2046.0 needs to be updated before November 30, 2022.

I've manually renewed the Let's Encrypt certificates in question now and the optional expired path in the chain has now gone.  This should resolve the client issue with ESET for us although I do question if it should have been necessary as the certificates were still valid.  Anyway, I hope this helps.

Hi.
One of our customers is getting a lot of "Certificate Revoked" errors from ESET Antivirus since 1.10.2021. Accessing these sites not via ESET does not show any problem. What seems to be common to all these sites is that they are using Let's Encrypt and OCSP Stapling.
Here is one example: https://app.softgarden.io
Any ideas how to track down the problem.
THX a lot.

This will be due to the Let's Encrypt "DST Root CA X3 DST" certificate authority expiring on the 30th September.  We have the same issue with 1 of our customers who use ESET Endpoint Security.  None of our other customers have issues.  Even though our certificate is valid ESET gives the same error and prevents access because one of the 2 paths has now expired.  Seems to be that ESET doesn't check the new/current cert authority "ISRG Root X1" for the multi-path Let's Encrypt certs, or something like that.

I am going to renew our certificates early to remove reference to the old cert authority to see if that fixes the issue.

Support case created.

We have successfully implemented haproxy in front of ESMC in a test environment.
Our first attempt to run in http mode failed, as we found that ESMC agent does not seem to send back valid HTTP responses which comply to http standards.
But we further found that this is not a problem with what we want to achieve (checking validity of the client cert on the reverse proxy side), as TLS bridging with haproxy also works in TCP mode.
Following is the relevant part of the haproxy config:
frontend esmcAgentFE mode tcp option tcplog bind *:2222 ssl crt /etc/haproxy/ssl/crt/esmcServer.pem verify required ca-file /etc/haproxy/ssl/ca/esmcCA.pem default_backend esmcAgentBE backend esmcAgentBE mode tcp default-server ssl default-server ca-file /etc/haproxy/ssl/ca/esmcCA.pem default-server crt /etc/haproxy/ssl/crt/esmcAgent.pem server default esmc.mydomain.com:2222 Cheers

Yes, it is conflicting:
https://support.mozilla.org/en-US/kb/how-disable-enterprise-roots-preference
Because prior to ver. 68, Enterprise Roots preference by default was not to refer to it.

Does this file exist? "C:\Program Files\Mozilla Firefox\defaults\pref\eset_security_config_overlay.js"