KES 11.1 and up intercepting KACE Konea 7.2 certificate

  • 25 June 2020
  • 5 replies

I am in the process of upgrading a segment of our production environment from KES to Last year a number of machines were successfully upgraded to KES and even KES 11.2, however, back in April 2020 we discovered that any machine that had been upgraded to KES 11.1 or 11.2 was no longer checking in to our KACE K1000 Systems Management Appliance. We use this appliance to monitor machine metrics and deploy software. Earlier this year we upgraded the Kace Agent from 6.4 to 7.2, and in this new version a separate .pem certificate gets saved to C:\ProgramData\Dell\KACE\ and is used by the locally installed agent to communicate with the appliance.

We believe that as soon as a machine that has Kace Agent 7.2 installed is upgraded to KES 11.1 or 11.2, Kaspersky intercepts and replaces the certificate used to facilitate that communication. As soon as the endpoint comes back from the restart to install KES 11.1/11.2, it loses communication, and if we look in the KACE Agent log, we see activity like this start to loop indefinitely:

This behavior shows that when the KACE Agent starts it sees that the certificate has been signed by an unknown authority and will not allow it to connect. This happens only after the client restarts after installing a KES client higher than 11.0. As far as I know there is nowhere in the Endpoint or Security Center that highlights if/when Kaspersky replaces the certificate. The only known fix at this time is to regenerate the certificate manually client-side, which is not feasible for an organization of my size.

I have whitelisted C:\ProgramData\Dell\KACE everywhere in the Kaspersky Security Center policy that I could find. I added the URL of our K100 Systems Management Appliance to the list of Trusted Domains. I even repackaged our Kaspersky Endpoint deployment entirely with install.cfg so that our policy comes installed with the endpoint on the off chance that Kaspersky is intercepting the cert before KES has a chance to check into our server.

We checked with KACE Support to confirm what locations need to be whitelisted (and they already were). I have opened a few tickets with KL Support and am simply told that enabling/configuring this option here or that one there should do the trick, but it never does. I have spent an inordinate amount of time troubleshooting this issue and I am sick and tired of this.

Has anyone else had to get these two technologies to work together or have any tips?

5 replies

Userlevel 6
Badge +5

try it with disabled "scan encrypted connections" - coming with KES11.1 and ist enabled by default.
Policy - “general settings” - “network options”


if that works: configure an exception for the communication of the application


Hi Alex,

Thank you for the response. When you say “configure an exception for the communication of the application,” what do you mean specifically? Is there a specific option that if configured a certain way should allow this? I ask because I’ve already added every .exe in the C:\ProgramData\Dell\KACE directory as “Trusted applications”, also added that directory and every exe manually as “Scan Exclusions”, added the URL of our appliance in the list of “Trusted Domains.” Do you know of any other places in the policy that this can be whitelisted?

I forgot to mention in the original post, but it seems that if you manually regenerate the certificate after Kaspersky intercepts it, Kaspersky leaves the regenerated certificate alone. I’m not sure why this would be the case.

Userlevel 6
Badge +5

the settings in “trusted zone” have no effect on “scan encrypted connections”.
you have to add exclusions in the policy here (sorry, i only have a german version right now)


but first i would recommend deactivating “scan encrypted network” and testing the connection. 
maybe the problem is somewhere else.


Hey Alex,

Thank you for that information.

It looks like you’re looking at the Trusted Domains section of Network Settings, in which the domain name of our appliance is already added as an exception. I can test with IP as well. I will also test with disabling the “scan encrypted connections” feature altogether just to possibly rule Kaspersky out though this behavior has only been observed to occur after a machine has been updated to KES 11.1 or higher.


So I’ve confirmed that in most cases where KES 11.1 is pushed to a machine, the .pem certificate is intercepted and altered as the hash of the .pem file in C:\ProgramData\Dell\KACE\ is changed after KES 11.1 is deployed. The value of the .pem certificate hash taken before KES 11.1 or KES 11.2 is deployed is standard across our production environment, but gets changed to a random value in many cases after deployment, and it’s in these instances that the machines lose connection with our KACE appliance. I’ve done everything I can think of:

  • whitelisting the correct SHA256 hash of the .pem certificate as a scan exclusion
  • adding each of the KACE program directories as scan exclusions
  • adding each manual EXE in those program directories as Trusted applications
  • adding our Trusted Root Certificate Authorities to the Trusted system certificate store
  • adding the domain name of our system appliance to the list of Trusted Domains. 

I have configured everything I can think of (please correct me if I’m wrong). It is very frustrating how much I have to wrestle with my company’s own antivirus application so that it doesn’t break another critical piece of infrastructure and it is frustrating when I escalate this to Kaspersky Support I’m mostly greeted with shrugs and suggestions of things I've already tried. I don’t understand how there isn’t a clear answer to this problem and with each passing week it is becoming harder and harder to justify to my company the retaining of Kaspersky Endpoint Security as our AV provider considering how difficult it is to manage or get support.