Peter Randziak

Hello Jim, good, thank you for the confirmation. may I ask if you tried also upgrades from the previous version(s) or clean installations only? Regards, P.R.

Hello Epunkt, I can see that you use x64 version of FreeBSD 11, which is not supported by the currently released ESET Gateway Security for Linux/FreeBSD. Planned next major version should bring support for the x64 FreeBSD OS. Regards, P.R.

Hello M4v3r1ck, thank you for letting us know, I have forwarded it to a macOS support specialist to check. Regards, P.R.

Hello m4v3r1ck, great, thank you for such positive feedback, much appreciated. Will forward to the Devs to make theirs Friday even better :-) Regards, P.R.

Hello Itman, thank you for sharing it. Chrome https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html Firefox https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/ It seems all the major browsers are keeping SHA1 support due to the enterprise customers. Regards, P.R.

Hello DinGo, the fix mentioned should be available quite soon so we expect the release for automatic updates in about 2 weeks from now. Regards, P.R.

Hello Itman, the currently released SSL scanner (part of Internet protection module) does not ask / block by default secured sites with SHA1 certificates. Not sure what is the ratio behind it, but I assume that there are still many sites with such certs, which would lead to bad user experience as they would be asked for / blocked. Regards, P.R.

Hello Itman, I checked it with the dev responsible and it is intentionally that way. Common name can only be checked with regard to the server the client is connecting to. Because of that Windows would display the certificate as valid even if it's used for a wrong server. Because of that we let the browsers handle the situation. Regards, P.R.

Hello Itman, O.K. now it makes more sense to me, thank you for the clarification. I will check it with devs. Regards, P.R.

Hello Jim, our QA guys tried to reproduce the issue, you mentioned but without success :-( the EP 6.5 survived the upgrade from 1607 to 1703. Are you able to reproduce the issue? Regards, P.R.

Hello Itman, as far as I know we do not use a designated ESET servers to perform the certificate validation. On top of that you may have your own trusted certificate authorities imported so it won't work. So it currently seems that no certificates are validated by ESET for sites visited by IE11 in private mode, right? Regards, P.R.

Hello M4v3r1ck, from my past experience no response means everything is O.K. :-). If I remember correctly all major reported issues should be fixed (the dev team put really a huge effort to this release) Regards, P.R.

Hello Itman, it seems that tv.eurosport.com si not available via IPv6 at all :-( "nslookup tv.eurosport.com Non-authoritative answer: Name: a1846.w3.akamai.net Addresses: 23.67.56.65 23.67.56.17 Aliases: tv.eurosport.com static.eurosport.edgesuite.net" Sadly do not know such site and I do not have IPv.6 so I can't test it myself. You stated, that you think in IE11 private mode the certificate validation is not performed for sites served via IPv.6, right? Are the sites with not valid certificate blocked / validated on: IE11 standard mode? IE11 private mode for sites served via IPv.4 Thank you, P.R.

Hello itman, I tried to visit a secured site with untrusted certificate via IE 11 from both normal and private mode and I got a prompt from ESSP if I would like to proceed so the certificate got validated by us. Can you maybe try to perform the same test? Regards, P.R.

Hello Avielc, it should be ecmd /setfeature webaccess enable see http://support.eset.com/kb6382/?locale=en_US&viewlocale=en_US for more commands. Regards, P.R.

Hello itman, not sure, but I assume that the connections are just open, not active anymore. Regards, P.R.

Hello Itman, that is strange. The ESET Security Forum is hosted in a cloud indeed. Is the situation the same with a different browser(s)? I tried it myself on IE 11 and it loaded almost instantly. What exact Windows and ESET version do you have? Regards, P.R.

Good, thank you. In case they are without the "Update engine advanced logging" enabled, I'm afraid that the guys won't be able to determine the root cause exactly. :-( P.R.

Hello Jim, both the update files and the modules are digitally signed so in case the file is corrupted you can see such message. I'm glad that it got resolved by the next update attempt (so it would probably resolve itself by next scheduled update as well.) btw. in the diagnostics there is a new option log log the update process as well so in case you (or anyone else) encounter issue with an update this is a very easy way to collect required logs for ESET support. Regards, P.R.

Hello Peter, yes sure, I will send you a private message in few moments. Regards, P.R.

Hello guys, Rein is right about the Device control module. When it comes to the Script scanner module displaying in ESET Endpoint Security 6.6, it will be fixed in next Antivirus and antispyware scanner module (1516+), thank you for pointing on this. Regards, P.R.

Hello, the automatic updates were not enabled yet, as I was informed there is an issue that has to be fixed, before we start the automatic upgrade distribution. Regards, P.R.

Hello Hungtt, user is probably logged in as an user from that domain, that is why it works. Try to access the shared local folder as a local (not domain) user or even better as local system. Regards, P.R.

Hello Jim, as far as I know even the 6.5 shouldn't be removed upon upgrade. Do you have DeviceGuard feature enabled on that system? Regards, P.R.

Hello Rein, not all modules are being displayed, but not sure why here is such discrepancy. Have you installed both products on the same version of Windows? Regards, P.R.