bbahes

If it's in USER cert store then my guess is that you or process can update it without any prompt. I will check this. ESET did do something with their certificates last week....

I think they did change something about their certificates...they won't say. I had problems with accessing their forum last week but nobody confirmed any problem or change: https://forum.eset.com/topic/4776-forumesetcom-this-page-cannot-be-displayed-ie11/ As for your screenshot you should have looked details about when it was created and who is creator/owner of the file...

I have tried that too, but didn't look at tcpdump output. RD Sensor still didn't work. I have feeling it has something to do with supported OS version, as you can see on attached image.

Try investigate system processes with Sysinternals Procexp. If you don't Know how then ask someone to do it for you. Else if this is not option I would suggest to clean your hard drive and do new installation.

Not that it's important now, but if SSL handshake fails, how is it "site outage issue" ? I'm asking purely because I was in doubt that my IE configuration, or SSL registry settings got corrupt. My guess was that it was CRL issue not certificate itself and that IE was behaving correctly, whereas Chrome did not, so we could access https forum site via Chrome. "Of the major browsers, only Internet Explorer and Opera behave correctly in a wide variety of revocation scenarios, including where end-entity and intermediate certificates had been revoked only via a CRL or only via OCSP. The remaining browsers — Google Chrome, Safari, and Firefox — all have less consistent behaviour when checking the revocation status of SSL certificates." - hxxp://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.HTML

Working today ok in IE. Must have been something with server certificate CRL...

It must be IE related. I will check and report back result.

Hi! I am unable to access https://forum.eset.comfrom IE11 but I'm able to access it from Chrome. In IE I get error message : "Turn on TLS 1.0, TLS 1.1 and TLS 1.2 in Advanced settings and try connecting to https://forum.eset.comagain. If this error persists, contact your site administrator." In Wireshark I get this: TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Doing check on site cert: certutil -verify -urlfetch forum.eset.com.cer Issuer: CN=thawte SHA256 SSL CA O=thawte, Inc. C=US Name Hash(sha1): 55b8cc328599c11969052a591ea0d7bdcdd95b4b Name Hash(md5): eaef5fa6aa2ec8c3f762b5fbbb58c15d Subject: CN=forum.eset.com OU=IT Support O=ESET, spol. s r.o. L=Bratislava S=Slovakia C=SK Name Hash(sha1): 682342ed3fb6ec4ac575ba03de5f56def265a6a4 Name Hash(md5): 5a9d80fdcd58c1859fe774f9b9dc80c0 Cert Serial Number: 4e5bee8faf9b1b2e951586ea0a95b845 dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ChainContext.dwRevocationFreshnessTime: 6 Days, 9 Hours, 59 Minutes, 21 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwRevocationFreshnessTime: 6 Days, 9 Hours, 59 Minutes, 21 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=thawte SHA256 SSL CA, O="thawte, Inc.", C=US NotBefore: 1.4.2015. 2:00 NotAfter: 10.4.2017. 1:59 Subject: CN=forum.eset.com, OU=IT Support, O="ESET, spol. s r.o.", L=Bratislava, S=Slovakia, C=SK Serial: 4e5bee8faf9b1b2e951586ea0a95b845 SubjectAltName: DNS Name=forum.eset.com 7a761f99d810d208cfb6a9c7a85afd8d63d8ac48 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 [0.0] hxxp://tg.symcb.com/tg.crt ---------------- Certificate CDP ---------------- Verified "Base CRL (0589)" Time: 0 [0.0] hxxp://tg.symcb.com/tg.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 0 [0.0] hxxp://tg.symcd.com -------------------------------- CRL (null): Issuer: CN=thawte SHA256 SSL OCSP Responder, O="thawte, Inc.", C=US ThisUpdate: 21.4.2015. 20:50 NextUpdate: 28.4.2015. 20:50 a95c6b2af9773fd0fa6454317b8538c78e2b096d Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=thawte Primary Root CA - G3, OU="© 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 23.5.2013. 2:00 NotAfter: 23.5.2023. 1:59 Subject: CN=thawte SHA256 SSL CA, O="thawte, Inc.", C=US Serial: 36349e18c99c2669b6562e6ce5ad7132 SubjectAltName: Directory Address:CN=VeriSignMPKI-2-415 f7b92774088f56a9b7a53c668df2b7dad547d167 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- Verified "Base CRL (13)" Time: 0 [0.0] hxxp://crl.thawte.com/ThawtePCA-G3.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 0 [0.0] hxxp://ocsp.thawte.com -------------------------------- CRL (null): Issuer: CN=thawte Primary Root CA - G3 OCSP Responder, OU=Certification Services Division, O="thawte, Inc.", C=US ThisUpdate: 16.4.2015. 21:14 NextUpdate: 23.4.2015. 21:14 c09a7b699b9476bfebf95883ea9fc51117bdcd4d Issuance[0] = 2.16.840.1.113733.1.7.54 Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing Application[4] = 1.3.6.1.5.5.7.3.8 Time Stamping CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=thawte Primary Root CA - G3, OU="© 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 2.4.2008. 2:00 NotAfter: 2.12.2037. 1:59 Subject: CN=thawte Primary Root CA - G3, OU="© 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Serial: 600197b746a7eab4b49ad64b2ff790fb f26bf3ca8915175b4356f0a6b603e91b8d538bf1 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 -------------------------------- Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing Application[4] = 1.3.6.1.5.5.7.3.8 Time Stamping Exclude leaf cert: b1ca9eb1f926d7a7ff789f711324523806c177ae Full chain: 6b9e537b8a6706c7832810012f92d3fc8685b93e ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.5.5.7.3.1 Server Authentication 1.3.6.1.5.5.7.3.2 Client Authentication Cert is an End Entity certificate ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) CertUtil: The revocation function was unable to check revocation because the revocation server was offline. CertUtil: -verify command completed successfully.

Same here.

The bug didn't affect Windows systems. Are those undetected computers in the same network with no firewall between computers and virtual appliance? Also just to make sure, SELinux is disabled, isn't it? It's just Ubuntu server 14.4.2 LTS guest on Hyper-V 2012 host. Windows guest detected all Machines on network. I can Access network and Internet from Ubuntu guest ping and ping any host on network. SELinux was enabled. I disabled it. Restarted server and only era is in detected list. So far...

We can only wait for them to reply. My luck is that I'm just testing v6 for now.

Yes but only RD Sensor appears to be having problem. They've apparently only fixed Windows version. Not Linux.

It's Rogue Detection Sensor 1.0.728.0 for Linux distributions that's in question, not Agent.

I have solution, but I also found it on forum later... https://forum.eset.com/topic/4116-ra6-linux-https-ssl-ubuntu-14/?hl=ubuntu

It would appear this is still BUG on Linux distributions. There is KB Solution ID: SOLN3674 and on the bottom of page it says: I have installed ESET Rogue Detection Sensor in my virtual environment, but rogue computers are not detected—how can I resolve this issue? Early builds of ESET Rogue Detection Sensor (RD Sensor) had a known issue that prevented them from finding rogue computers when RD Sensor was installed on a virtual machine. This issue has been resolved in version 6.1.28 and later of RD Sensor, released Feb. 25th, 2015. Visit the ESET Rogue Detection Sensor download page to get the latest version of RD Sensor. My Ubuntu 14.04. is virtual machine...any update from support?

Just a hint, maybe It won't show any "rogue" client since I haven't loaded license? UPDATE: I've added license key, but still ERA does not detect any client on network. Could it be that I have to make changes to iptables?

I've installed Rogue Detection Sensor on Ubuntu 14.04. server using 3.7 Component installation on Linux. However there are no computers detected but ERA server itself. Can someone from support suggest what should I do? Thanks.

Yes. But It won't work since Tomcat web server and ERA webapp are not configured to use HTTPS. I'm close to solution, after I'm done I'll post new topic on how to install ERA v6 on ubuntu server...

How can I make ERA web console secure. I've installed Server, Agent and WebConsole on Ubuntu 14.04. server using 3.7 Component installation on Linux. After I access ERA WebConsole on hxxp://IP_ADDRESS:8080/era i get information "Using unencrypted connection! Please configure the webserver to use HTTPS". Thanks for reply!

My plan is to install Apache HTTP Proxy and Squid3 on same machine (virtual appliance). Will this information be in "All-in-one installer" installation only or will it set this value in policy for agent and client?

As suggested try things first in test environment. My experience has been negative since first steps and I'm upgrading from v5. Basically your only option is to do clean install since upgrade does not offer any advantage and creates more problems if you are upgrading on same machine. Policies are not upgradable from older versions to v6 so after that we decided to wait and follow forum for other people feedback. Unfortunately, we don't see that ESET will change v6 dramatically to be like v5 fast, intuitive and efficient. This leaves us in unpleasant situation to search for alternative that will offer same things for budget we had for ESET. Best luck!

I've tried it myself: 1, selected a client and then "New task" from the menu - 2 clicks. 2, selected SysInspector log request - 2 clicks 3, clicked Finish - 1 click. Why then KB says different? Maybe we started to count clicks in different menus

I see you have domain...imagine having to do all this in workgroup like me...at the moment our decision is to switch to alternative solution next year. Until then we are forced to stay with v5 server and clients.

My clients have either disabled internet access or disabled most of internet behaviour, like file download. Why do you expect clients to have full access to internet to download installer for endpoint? And how can you rely on client to have secure download of endpoint product?

hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3692 21 click to get SysInspector log.