Jump to content

How to renew the KSC certificate correctly [KSC for Windows]


Antipova Anna

Recommended Posts

Antipova Anna

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.

Problem:

KSC certificate renewal or replacement is made incorrectly because the option to instantly replace the server certificate is used.

There is an article in Online help dedicated to the klsetsrvcert utility (https://support.kaspersky.com/KSC/13.2/en-US/227838.htm). If you follow the instructions according to the example indicated in the article  "klsetsrvcert -t C -i <inputfile> -p <password> -o NoCA", it may lead to the fact that administration agents (nagents) do not receive a new certificate, and you have to use the klmover utility.

Cause:

After the certificate is renewed with "-t C" option, network agents do not receive a new certificate and have no connection to the server.

Solution:

Run the certificate renewal script using the "-t CR" option (CR  Replace the common reserve certificate for ports 13000 and 13291) and the "-f" option in the <dd.mm.yyyy> format where we indicate the date 34 weeks ahead the current one. The time we set aside for changing the certificate to a backup one will allow a new certificate to be distributed to all nagents.

-t <type>

Type of certificate to be replaced. Possible values of the <type> parameter:

  • C—Replace the common certificate for ports 13000 and 13291.
  • CR—Replace the common reserve certificate for ports 13000 and 13291.
  • M—Replace the certificate for mobile devices on port 13292.
  • MR—Replace the mobile reserve certificate for port 13292.
  • MCA—Mobile client CA for auto-generated user certificates.

-f <time>

Schedule for changing the certificate, using the format "DD-MM-YYYY hh:mm" (for ports 13000 and 13291).

Use this parameter if you want to replace the common or reserve certificate before it expires.

Specify the time when managed devices must synchronize with Administration Server on a new certificate.

For example, consider the command "klsetsrvcert.exe -f "DD-MM-YYYY hh:mm" -t CR -g nb.loc". Since this command was used in October, a backup certificate would be created and distributed to all nagents within a month. Thus, the certificate should have been applied on November 1, 2022. 

image.thumb.png.8afbf914ca31f6096fb65edb939ba151.png

Let's check if the backup certificate has applied to the host. To do this, using the klscflag utility, enter the command: klscflag.exe -ssvget -pv 1103/1.0.0.0 -s KLNAG_SECTION_CERTDATA -n KLNAG_SSL_SERVER_CERT_RESERVE -ss '|ss_type = \"SS_LOCAL_MACHINE\";'

The certificate has been delivered.
If the backup certificate is not yet delivered to the destination host, we will see the following result of this command:

image.thumb.png.b21b87325bf8e2ba8fb49a21fbd4b6a1.png

Known problems:

The problem with issuing a certificate with a length of 2048 bits on KSC 14. 

NWC 14 issue

This problem occurs after updating KSC to version 14, it is related to the fact that the Web Console version 14 requires a certificate with an RSA key length of 2048 bits, but when updating the administration server, the old certificate with a length of 1024 bits remains in use. To fix this error, you need to issue a backup certificate with a length of 2048 bits, and wait until it is applied as the main one.

For KSC14, there is a problem of issuing a 1024-bit backup certificate. This is due to an error in the klsetsrvcert utility. To solve it, you need to replace the utility's exe file in KSC setup directory and execute the command with the -o option "RsaKeyLen:2048".

For example: klsetsrvcert.exe -t CR -g localhost -o "RsaKeyLen:2048"


Error - Failed to establish connection with the remote device:

image.thumb.png.d0bbe2ca3151d73c52f0d8b0d0c9bd67.png

This error occurs because we are trying to execute 2 consecutive commands on the same line. The first command is "-t CR -g nb.loc" and the second is "-f '20-12-2023 00:00'". Since the administration server restarts after executing the first command, the second command waits for some timeout before executing. But since in some user configurations, restarting the service can take a long time, the second part is performed when the server has not started yet. Which leads to the above error.

In order to fix this behavior, you need to run the commands separately, according to this scenario:

  1. Run .\klsetsrvcert.exe -t CR -g nb.loc
  2. Wait until the administration server service starts completely (you can check by connecting the console).
  3. Run .\klsetsrvcert.exe -f '20-12-2023 00:00'

image.thumb.png.99065d7d7dfadb89255cf1afcd113cd5.png

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...