carmik 0 Posted November 15, 2021 Posted November 15, 2021 (edited) This is a rather strange case: we have had Eset protect 8.1 running as a VA. We decided to update it to 9, but first we enabled advanced security, following the details in https://help.eset.com/esmc_admin/70/en-US/advanced_security.html but without step 10 (ie, without deleting and revoking our old CA and certificates), since there were quite a few clients (on shelf for example) that would remain with the old CA/certificates. All our clients were running 8.1 (either ES or EA). Things seemed to be going ok. Both the server certificate was updated all right as well as a number of clients. Out of around 150 systems, 100 were updated in the first 2 hours or so. This happened on the start of November. Today we noticed though that one out of three clients remain with the old CA/certificates: That would not be a problem if among these 56 systems there were not systems already active. We see the following problems: 1) New systems on which we installed agent (MSI version) with the .ini file containing keys of the old CAs/certificates would not appear in the console. I'm not sure that was supposed to happen, if I understand correctly the policy to replace certificates is still in place... The problem was solved by creating a new .ini (from create GPO or SSCM script) and using that alongside the MSI installer.... 2) Most (if not all) of the 56 systems have stopped contacting our server. So, if I understand correctly, they are unable to retrieve the policy to update the CA/certificates. How do I fix this problem? EDIT: Some additional info: Certification authorities (up old, below new): Going to status overview there seems to be a warning in certificates (might be normal, since the old ones have not been revoked yet), see: Edited November 15, 2021 by carmik
carmik 0 Posted November 15, 2021 Author Posted November 15, 2021 Server settings -> Connection: Server Port: 2222 Webconsole Port: 2223 Advanced Security: enabled Certificate: Subject (CN=Server certificate for host *; [SN:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX14201]), Issuer (CN=Server Certification Authority;), Valid from (31/10/2021, 12:00:00 π.μ.), Valid to (31/10/2026, 11:59:59 μ.μ.), Subject Alternative names (DNS:*)
ESET Staff MartinK 384 Posted November 15, 2021 ESET Staff Posted November 15, 2021 I can image two separate issues but cannot be precise as it require more data to be provided: Either ESET PROTECT's certificate was changed in a way that existing clients do not trust this certiifcate - i.e. those clienst might not received new CA certificate in time. This might be the reason why new installer helped - as it bundles CA certificate required for verification of this certificate Clients are not connecting due to other reasons: for example TLS incompatibility. My expectation is that first scenario is the case - solution might be to temporarily revert/use original ESET PROTECT certificate, at least until both new and old CA certificate are distributed to all clients.
carmik 0 Posted November 15, 2021 Author Posted November 15, 2021 How can I go about reverting this safely?
carmik 0 Posted November 16, 2021 Author Posted November 16, 2021 @MartinKI am seriously starting to think other AV platforms here, considering all quirks I've been finding and the time I'm spending trying to properly manage the ESET products... Regarding to your points, I really don't understand why two thirds of my clients (and all my clients are the same) did the certificate switch properly and the other third stopped connecting to the console altogether... And frankly I don't care on why this happened, it simply shouldn't. How can I fix this properly with the minimal impact on the use of my work time? I don't care if I have to disable advanced security in the process, as it seems it did more damage than any good.
Recommended Posts