Introduction
In 9.6 and earlier client certificates were used to verify the core and for CSA machines to communicate securely to the core. Starting in 2016.0 and higher LANDESK Management Suite / Ivanti Endpoint Manager uses client certificates for two-way authentication as well as secure communication for sensitive data. This means in 2016 and higher if there is a client certificate issue the clients will fail different functions, like Software Distribution, Provisioning and Vulscans and appear they are not functioning at all.
How the cert request process works
The clients receive a key (.0) file from the core during install and then the machines runs brokerconfig.exe to create a certificate signing request (.csr). That is sent to the core, the core sends back a certificate signed by the cert that corresponds to the key (.0) file used the sign the request.
Verifying certificates
To verify what certs are being used in your environment you can review the Client Connectivity agent setting, here it shows the cert and the corresponding key (.0) file.
As you can see in this environment there are two key (.0) files and their corresponding certs.
In order for either of these certs to work they must be installed in the Trusted Root Certificate Authorities cert store for the local computer.
Situations where certificate clean up is recommended
- In 9.6 the client certificates were hashed with SHA1 and in 2016.0 and higher they are hashed with SHA256. It is recommend to use the latest certificates issued to ensure you are operating at the highest level of security.
- There are situations where a client can be using a certificate that is not trusted by the core, the most common is a side by side migration where the certificates and keys were moved over to the new server but was not installed.
- There are also certain instances where if there are multiple client certificates it can cause issues with provisioning.
Note: You can also clean up your certs just to keep things organized and minimize possible future issues.
Verifying the hash type of your cert
To verify if your current cert was hashed with SHA256 or SHA1 open the .crt or .cer, go to the Details tab and find the signature hash algorithm.
Clean up certs
Once you have determined you need to or want to clean up your certs here are few different locations that will need to be cleaned up. You will need to identify the .0 files in your environment that need to be deleted.
- The first locations are on the core machine itself, the certificates and keys are located in the \Program Files\LANDesk\Shared Files\keys. For each certificate there should be a .0 file, a .cer file, a .key file and a .crt file in the \Program Files\LANDesk\Shared Files\keys directory. The key (.0) files are also located in the ldlogon directory so they are available for the clients to pick up and create their certificate request. So in order to stop a client from picking up an incorrect key (.0) file it must first be removed from the ldlogon directory.
- You can manually delete those files.
- The other locations are on the clients themselves. For x64 clients the key (.0) files are in the C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs for x86 clients they will be located in C:\Program Files\LANDesk\Shared Files\cbaroot\certs. The certificate the client is using is located in the C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker and C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker folder. When you open the cert you can see what cert it was signed by, it should match the installed certs on the core. If not there is an issue.
- For the clients the easiest way to delete the unwanted key (.0) files and request a new cert is to use a Managed Script. Managed scripts remotely execute and do not rely on the scheduler service or the machines ability to run policies. This is important especially since if the clients are using the wrong cert, they will not pick up and run a policy. Below is a sample script that can be used to delete the .0 files and re-request a broker cert.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; LANDesk(R) Management Suite Custom Script
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; MACHINES - This section is run once for each machine in the target set.
; Commands in this section will be processed in the order they are listed
; in the custom script. This section supports both local (LOCxxx) and remote
; (REMxxx) commands.
[MACHINES]
REMDEL0="C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs\cert1.0"
REMDEL1="C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs\cert2.0"
REMDEL2="C:\Program Files\LANDesk\Shared Files\cbaroot\certs\cert1.0"
REMDEL3="C:\Program Files\LANDesk\Shared Files\cbaroot\certs\cert2.0"
REMEXEC10=<qt/>%LDMS_CLIENT_DIR%\brokerconfig.exe<qt/> -r, STATUS
The script will delete "cert.0" where cert will be replaced with the .0 file name, example 5e207163.0. You may also want to add a cert.* (ex: 5e207163.*) in order to delete any certs that have been renamed to .1 .2 ect., it is not necessary to delete the cert files with .1 .2 or .3 appended as brokerconfig.exe will only use a .0 file to request the cert. There are two locations since x64 and x86 machines have different paths. The last line is requesting a new cert. This cert will be signed with the remaining key (.0) file so it's important to ensure you are deleting all the unwanted certs.
- The last location is within the boot wim files. The boot wims will need to be mounted in order to pull out the incorrect key (.0) files.
- Create the following folders on the root of the C drive:
- Create the following folders on the root of the C drive:
C:\Mount
C:\Mount\BootWIM - Copy the drivers you wish to inject into the C:\Mount\Drivers folder
- Copy \Program Files(x86)\LANDESK\ManagementSuite\landesk\vboot\boot.wim and boot_x64.wim to the C:\Mount folder.
- Open a CMD prompt as Administrator.
- Navigate to "C:\Mount".
- Use the following DISM commands to mount the Boot.wim:
DISM /Mount-Wim /WimFile:C:\Mount\boot.wim /Index:1 /MountDir:C:\Mount\BootWIM
- Remove the unwanted key (.0) file.
- Use the following DISM command to unmount the Boot.wim:
DISM /Unmount-Wim /MountDir:C:\Mount\BootWIM /Commit
It is recommended that you remove the unwanted cert files from the core first, both from the Shared Files\keys directory as well as the ldlogon directory, then proceed to the clients and boot wim files.