itman

Yes, I am "one step away" from following them.

This is the main reason why other users stopped using ESET products, and went to Kaspersky, because the ESET team doesn't understand the problem that was posing. Are they reading what you've been posting for several days?

I also know about this CRL and consider it an "anomoly" to what I have posted in regards to Eset not having issues in regards cert. chain modification issues for SSL/TLS protocol scanned web sites. That is Eset "chokes" and loads the entire Microsoft aggregate CRL into Eset Service memory on this web site.
It so happens that the old Gibson Research web site revoked cert. test uses a cert. with this CRL:

First note that this GRC revoked cert. test is quite old.
I believe the problem is that the CRL format is no longer valid; i.e. the referencing CA root cert. CRL no longer exists.
In any case, the fact this was mentioned shows you are still "totally oblivious" to what I have been posting the issue is. I see at this point, no major issues with Eset cert. revocation in regards to SSL/TLS filtered web sites. The issue is Eset is also performing cert. revocation checking on non-SSL/TLS filtered web sites and it should not be doing so.
I also see I have again wasted my time "criticizing" anything Eset does not want to acknowledge is a problem.
BTW - keep your "self-patronizing" comments to yourself.

This article by Quttera: https://blog.quttera.com/post/what-happens-ssl-certificate-trust-chain-breaks/ . Of interest is: .
First, in regards to Firefox's Authorities store, note that less than a handful of Intermediate CA certs.. exist. One of those is the DigiCert SHA2 Secure Server CA cert.. I have posted previously about. These Intermediate CA certs. in Firefox's Authorities store function as an "override" to the Intermediate cert. downloaded, if needed, by the browser from the web site server. Since browsers use the Intermediate cert. for chain validation purposes, Firefox uses the DigiCert SHA2 Secure Server CA cert. in its Authorities store and bypasses the Intermediate CA cert. download from the web site.
One possibility here is when the Win crypto API is invoked for cert. revocation status determination, it bypasses any browser modification/download  activities in regards Intermediate cert. usage and instead is using a Microsoft supplied web server Intermediate CA cert. download. This would also explain why the GoDaddy cert. example posted previously failed. In the GoDaddy case, the altered Intermediate CA cert. existed on the origin web server only; it is not present in the Firefox Authorities store.

I will also state this in regards to Eset's use of the Win crypto API.
Eset by virtue of it's SSL/TLS protocol filtering feature is responsible for cert. validation processing normally performed by the browser. Namely, certificate revocation status processing. Assumed is the Win crypto API cert. revocation processing is invoked and is one way to so. My prior testing as previously posted shows no issue in regards to SSL/TLS protocol filtered web sites:
As I see it, there is no reason Eset should be performing the above processing for non-SSL/TLS protocol filtered web sites. Is it possibly that some one at Eset got "overly creative" in invoking the Win crypto API cert. revocation processing in this regard?
-EDIT- The above does raise this question. When Eset invokes the Win crypto API cert. revocation processing is the API properly performing its cert. revocation checking?

https://www.cuisineaz.com/ - not blocked by Eset
https://actu.orpi.com/optiext/optiextension.dll?ID=5BA5zNni8NUJhDLuPut8c9%2BB57LFL2ysPCjjhh_yPcuaVCejXTFVYHgjbIiwl6t38pSzVTj8JaXAgV1XTiMQjbRiYO%2BHA - expired certificate; blocked by browser.
https://t.news.cuisineaz.com/c/?t=d119c7e-e-3z813-fmzl-c2wiaw - not blocked by Eset
https://www.societe.com/societe/i-tech-809565930.html - not blocked by Eset
https://www.radins.com/budget/faire-des-economies/magasins-destockage-economiser/18900 - not blocked by Eset

First, I posted in this thread a detailed example of certificate chain "patching" in this thread: https://forum.eset.com/topic/31282-memory-usage/?do=findComment&comment=146973 .
As far as this reference is concerned: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain
It appears that root certificates using SHA1withRSA are no longer valid for CRL purposes. You will have to ask Microsoft about this one. Again, refer to the above GoDaddy cert. chain I posted.
It would appear that CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT option would get around the current chain "patching"  issue but I have doubts. That is what happens if the cert. chain has two root certs. present which is very much the case presently?
Again, refer to the above DigiCert chain I posted. The inserted "patched" root certificate is an altered DigiCert Global Root certificate  that in reality is the existing cert. with SHA2withRSA capability that is chained to the chain terminating BaltimoreTrust root certificate. Bottom line - this altered DigiCert Global Root certificate would be the one used for CRL purposes. The problem is the Windows crypto API doesn't have an option for this.cert. chain "patching"
My conclusion is when cert. chain "patching" is evident; i.e. two root certs., Eset needs to "bow out" of CRL checking and let the browser handle it.
As far as past Eset issues when certificate chain "patching" occurred, search the forum for prior postings in regards to web site access issues when a "patched" certificate chain was in effect.
BTW - Firefox is the only browser that handles certificate chain "patching" properly in that, it actually is using an Intermediate CA cert. from its Authorities store that contains the "patched" chain.
-EDIT- The problem here is Microsoft doesn't approve of cert. chain "patching" and therefore won't support it. The CA's in turn say "up your nose with a rubber hose" to Microsoft. Their my certificates and as long as their standard's organization allow  cert. chain "patching," they are going to do it. The browser manufacturer's caught in the middle, go along with what the CA's want.

"It's time to cut to the chase" on this issue since my patience is "wearing thin."
It is fairly obvious that Eset, either directly or indirectly, is performing certificate chain validation checking as part of its background processing. It has also been doing this incorrectly for some time.
The correct way to perform cert. chain validation is when a web site is accessed the thumbprint of the terminating; i.e. top of the chain root cert. is extracted. Then an identical web site access is made via a secured server and the same process is repeated. If the two accessed thumbprints match, the chain is valid and no man-in-the-middle activity has occurred. If any other cert. chain validations are performed, it will lead to incorrect results. Why?
It is a common but infrequent practice of CA's that when there is a non-security related issue with a root certificate to "patch" the chain by having the browsers insert a new root cert. in the chain and then chain this new root cert. to the original root cert.. This will avoid having the CA issue thousands of new certificates and the costs associated with that.
From what I have observed, Eset has not been handling the cert. chain "patching" correctly for some time. So this needs to be fixed immediately, or Eset bypass cert. chain validation processing. The "mystery" at present is why Eset is now reverting to loading the entire aggregate Windows cert. revocation list into memory when this cert. patching occurs. Again, the solution is for Eset to either fix their cert. chain validation processing or bypass it entirely.

Same problem that manifests with the DigiCert Intermediate cert. issue posted previously. GoDaddy is sending an "intermediate" root CA and chaining it to the original root CA to get around the SHA1 CRL signing issue:

This also unfortunately illustrates the issue is not exclusive the DigiCert Intermediate CA cert. I highlighted.
This problem will keep reoccurring until Eset finds a way to handle this on-the-fly downloading of altered cert. chain path processing that browsers are invoking to get around the SHA1 CRT signing issue.

Here's a simpler "fix" Eset can implement.
Here's a domain, https://imgur.com/ , that Eset CRL checking goes spastic on since it is using a cert. that chains to the DigiCert Intermediate cert. noted in my above posted entry. It also happens this domain is excluded from Eset SSL/TLS protocol scanning via internal whitelist.
What happens if this domain is not excluded from Eset SSL/TLS protocol scanning? Eset does not go spastic when performing CRL validation processing and no Eset Service memory spiking occurs. Why? Because Eset has directly chained the web site cert. to its root cert. eliminating the troublesome DigiCert Intermediate CA cert.. and is using its own cert. for CRL checking.
Therefore all Eset has to do is exclude from Eset SSL/TLS protocol scanning via internal whitelisting any web site using the troublesome DigiCert Intermediate CA certs..

Here's a simpler "fix" Eset can implement.
Here's a domain, https://imgur.com/ , that Eset CRL checking goes spastic on since it is using a cert. that chains to the DigiCert Intermediate cert. noted in my above posted entry. It also happens this domain is excluded from Eset SSL/TLS protocol scanning via internal whitelist.
What happens if this domain is not excluded from Eset SSL/TLS protocol scanning? Eset does not go spastic when performing CRL validation processing and no Eset Service memory spiking occurs. Why? Because Eset has directly chained the web site cert. to its root cert. eliminating the troublesome DigiCert Intermediate CA cert.. and is using its own cert. for CRL checking.
Therefore all Eset has to do is exclude from Eset SSL/TLS protocol scanning via internal whitelisting any web site using the troublesome DigiCert Intermediate CA certs..

Since Eset appears to be clueless on how to fix "intermediate" root cert. downloading by the browser, it needs to add Intermediate cert. revocation checking bypass exclusion capability. It would first check if a web site cert. chains to an excluded Intermediate cert.. If it does, Eset would bypass any cert. revocation processing for the web site.

If this isn't possible, Eset needs to allow for disabling of its certificate revocation checking processing. Note this will have no effect on web sites that Eset performs SSL/TLS protocol scanning on since it chains the web site cert. directly to its own root cert..
Firefox is more than capable of performing this checking; more so if security.ocsp.required option is set to true. This will result in "hard failure" processing in regards to cert. revocation checking. That is if Firefox doesn't receive a revocation status response in 10 secs. from OSCP server, it assumes the cert. is revoked.

The answer to this is only if you don't have Eset installed.
First, refer to this article: https://www.bullfrag.com/chrome-cleanup-google-chromes-antivirus-will-remain-based-on-eset/ . Chrome's Cleanup utility employs the base Eset engine for malware detection purposes. In other words, it's performing the same functions as an Eset on-demand scan does; nothing more.
Additional ref.: https://www.eset.com/us/google-chrome/

IP address, 162.210.199.65, is suspicious. Two sources at VT, Comodo and Webroot, flag it as malicious. Also, another source that tracks coin mining sites flagged it.
Upon access to hxxps://162.210.199.65/, Eset immediately throws the botnet alert. As such, Eset has blacklisted the IP address.

BTW - if you haven't figured out yet what is causing Eset Service memory spiking, I will explain that.
When Eset attempts to process a certification revocation list (CRL) from a web site cert. that is using one of the two Intermediate CA certs. referenced in my prior posting, it goes "spastic" and proceeds to "brute force CRL processing recovery mode." There is a noticeable pause in web site rendering in the browser. Eset appears to thinking to itself, what do I do now? I got it! I will load the entire Microsoft provided CRL into memory that contains all revoked certs. from all issuing CA's. 
Well, I could live with that for the time being. However, the correct way to do this would be to unload this aggregate CRL from Eset Service memory when the browser was closed.
But here's the problem. Once Eset loads the aggregate CRL into Eset Service memory, it will stay there until a system restart. Most use Win 10 fast startup mode which means the aggregate CRL remains in Eset Service memory, Far worse is the Microsoft provided CRL is updated daily via Win 10 crypto processing. However from what I can tell, this update is not carried over to what currently exists in Eset Service memory.

I spent more time last weekend doing more research/testing on this issue and I know now what the problem is. It is related to a certificate chain validation issue that has surfaced multiple times in past forum issues. Eset has to date ignored the issue. So, don't expect a fix now as I see it.
Some brief diagnosis info.. I had for a while noticed that Eset memory spiking occurred on web sites using a cert. chained to this Intermediate CA cert., DigiCert SHA2 Secure Server CA. That leads to the following findings.
First, there are two intermediate certs. in Firefox's Authorities certificate store that will lead to Eset Service memory spiking if one lands on a web site whose cert. is chained to one of the following:

Review of the DigiCert SHA2 Secure Server CA chain path data shows the following:

Notice something odd about the chain path? Notice that two root CA certs. are shown.
Closer examination of chained Digicert Global Root CA cert.. shows it has characteristics different for the same cert. present in Firefox's Authorities certificate store; primarily the chained cert. supports SHA2 versus only SHA1 that is supported for the Firefox's Authorities certificate store cert..
So what the hell is going here? Well, servers can download what can best be described as a "intermediate root cert." on demand and then chain this intermediate root cert. to a new root certificate. This is done when there are problems with the original issued root CA cert.. The problem here appears to be that Microsoft no longer allows for certificate revocation lists referenced in the web site issued cert. that use SHA1; namely this:
https://en.wikipedia.org/wiki/Certificate_revocation_list
Referring back to my opening paragraph statement of "I know now what the problem is. It is related to a certificate chain validation issue that has surfaced multiple times in past forum issues," the problem is Eset "chokes" on the processing of intermediate root certs. thereby borking the entire chain validation processing.
Eset needs to fix this cert. chain processing issue ASAP!
In the interim, Eset needs to bypass any certificate revocation checking for any web site cert. that chains to the two above shown intermediate certs..
 

I did some additional research/testing.
As far as everything I have posted about Let's Encrypt recent en-mass cert. revocation being the source of Eset Service memory spiking, it is "phony baloney." In Mar., 2020, Let's Encrypt revoked over 3 million certs.. This at the time caused no issues with Eset Service memory spiking.
As far as @Marcosstatement that cert. revocation being the source of Eset Service memory spiking, I also state that is "phony baloney."
So what is the source of this Eset Service memory spiking?
I performed some certificate validation tests at this web site: https://www.ssl.com/sample-valid-revoked-and-expired-ssl-tls-certificates/ . Eset detected the two revoked certs. Eset did not detect the two expired cert. tests. However, at least Firefox detected the expired certs..
Now, back to the badssl.com cert. tests I referenced previously. Again, note that initial access to that site causes Eset Service memory to spike. Well, it so happens that the cert. for badssl.com is expired. As such, it can be inferred that all its sub domains used to test various cert. issues are using an expired cert..
The next test I performed is what happens in regards to Eset Service memory spiking if I access the badssl.com web site and perform the Dashboard tests with Eset SSL/TLS protocol scanning disabled? Guess what? No Eset Service memory spiking occurs.
The above leads to the conclusion Eset SSL/TLS protocol scanning has an issue with expired cert. detection. Eset implemented some "Band-Aid" solution which isn't working properly resulting in Eset Service memory spiking; it not being properly released; and "only God knows" what other borks may be occurring.

Also Eset IDS protection blocks port scanning by default:

This Eset service memory consumption issue will manifest on all browsers where Eset performs SSL/TLS protocol scanning.
All it takes is to land on a web site using a Let's Encrypt certificate. Eset will query via OSCP the issuing CA server. It then proceeds to download all these revoked certs. and store them in its memory.
Assumed here is previous revoked certs. were relatively an insignificant number. Therefore, any increase in Eset memory was negligible. As such, Eset memory consumption increase was not an issue.
Leave it to Let's Encrypt to "muck up the works" again.

I should also note that there are other things in Firefox that will cause Eset Service memory to spike and remain at an elevated level.
For example, the testing at badssl.com to verify that your AV's SSL/TLS protocol scanning has not borked the browser's native SSL/TLS certificate validation processing. When I performed the Dashboard test at badsll.com which performs a number of certificate validation tests, I passed all except the reversed-chain test. Of note and of interest, Firefox natively will detect this anomaly and block the connection.
After performing the Dashboard test, Eset Service memory to spiked to 200+ MB and remained at that level thereafter. This is unfortunately, current expected Eset behavior due to its loading of Win store certificate data to use for validation purposes in the test w/o Firefox expecting this to occur.

Detailed explanation as I see it.
Firefox will check daily for certificate updates. This occurs once a day when Firefox is initially opened. Firefox will then update its certificate store accordingly. Firefox also has internal settings to roll over to Windows certificate store. So this also might be a factor; especially if Firefox's Query OCSP setting is disabled or malfunctioning in some way.
In any case, Eset is monitoring this Firefox certificate update activity; hence the increased memory usage. If all goes as it should, Eset will release this increased memory usage when Firefox is closed. Firefox will not perform any additional certificate updating until the next system startup. Hence, no increased Eset memory usage on subsequent Firefox startups.

This might be the culprit.
After seeing your posting, I forced the Firefox update to ver. 97.0 within Firefox. After FF restarted, it still was using approx. 40 MB.
Shortly afterwards and with Firefox open, Eset pushed a signature update. Immediately afterwards, I checked Eset Service memory usage and it increased to approx. 220 MB.
Could the problem be an Eset signature update w/FF in use? Or more likely, any/select background process that starts up with Firefox running?
It gets better. When I closed Firefox, Eset Service memory usage dropped back to approx. 40 MB. Could this issue be now resolved? Was the problem all along FF ver. 96.0.3?

It also should be noted that WFP has been abused by ATP level based attacks:
https://www.securityweek.com/diplomatic-entities-targeted-new-moriya-windows-rootkit
As such, one should fully trust any software using WFP for network traffic monitoring activities.

Err........
If your referring to why its not listed in the top portion of the screen shot, PC Mag posts results from the last time they reviewed a listed product. Eset was reviewed a few months previous to when Kaspersky was.

Eset in its earlier versions used a mini-port network adapter driver.
It abandoned it in favor of WFP because Microsoft is constantly altering Windows network stack processing. Each of these revisions caused Eset's driver to get borked in some fashion.