Management and Security powered by Landesk

> Configuration > Agent configuration > Agent security > Agent security and trusted certificates

Agent security and trusted certificates

Management Suite uses a certificate-based authentication model. Device agents authenticate to authorized core servers, preventing unauthorized cores from accessing clients. Each core server has a unique certificate and private key that Management Suite Setup creates when you first install the core or rollup core server.

These are the private key and certificate files:

  • <keyname>.key: The .key file is the private key for the core server, and it only resides on the core server. If this key is compromised, the core server and device communications won't be secure. Keep this key secure. For example, don't use e-mail to move it around.
  • <keyname>.crt: The .crt file contains the public key for the core server. The .crt file is a viewer-friendly version of the public key that you can view to see more information about the key.
  • <hash>.0: The .0 file is a trusted certificate file and has content identical to the .crt file. However, it's named in a manner that lets the computer quickly find the certificate file in a folder that contains many different certificates. The name is a hash (checksum) of the certificate's subject information. To determine the hash filename for a particular certificate, view the <keyname>.crt file. There is a .ini file section [LDMS] in the file. The hash=value pair indicates the <hash> value.

An alternate method for getting the hash is to use the openssl application, which is stored in the \Program Files\LANDesk\Shared Files\Keys folder. It will display the hash associated with a certificate using the following command line:

openssl.exe x509 -in <keyname>.crt -hash -noout

All keys are stored on the core server in \Program Files\LANDesk\Shared Files\Keys. The <hash>.0 public key is also in the ldlogon folder and needs to be there by default. <keyname> is the certificate name you provided during Management Suite Setup. During Setup, it's helpful to provide a descriptive key name, such as the core server's name (or even its fully qualified name) as the key name (example: ldcore or ldcore.org.com). This will make it easier to identify the certificate/private key files in a multi-core environment.

You should back up the contents of your core server's Keys folder in a safe, secure place. If for some reason you need to reinstall or replace your core server, you won't be able to manage that core server's devices until you add the original core's certificates to the new core.

Managed device certificates

With Ivanti® Management Suite version 2016, agent installation automatically generates a certificate on each managed device. These certificates aren't valid on the core until they're approved (Configure > Client access). Unapproved devices won't be able to communicate through a Cloud Services Appliance.

Ivanti® Management Suite version 2016 also introduces a new client certificate-based security model for Windows-based devices. When this security model is active, only devices with valid certificates can decrypt secure core server data.

Because this security model isn't compatible with agents from older Management Suite (9.x) versions, it isn't enabled by default. However, Ivanti strongly recommends that you enable this security model once your managed devices are all using version 2016 or later agents. For more information, see Client certificate-based security.

On managed devices, certificates are stored here:

  • C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker

There are three files:

  • broker.key: Private key. This should be protected. Only administrators have rights to it.
  • broker.csr: Certificate signing request sent to the core to be signed.
  • broker.crt: Public key in X509 certificate format.

 


Was this article useful?    

The topic was:

Inaccurate

Incomplete

Not what I expected

Other