keystores and certificate verification in Service Desk Manager

Products

CA Service Desk Manager CA Service Management - Service Desk Manager

Issue/Introduction

This article discusses the multiple ways that keystores may be used within the Service Desk application and how to tell which keystore and certificate is being used.

Environment

CA Service Desk Manager (all versions)

Resolution

There are generally two distinct keystores.

SSL Keystore:

The first are any keystores that are used to define the SSL configurations for SDM and xFlow. These are arbitrary and can be defined however one sees fit.

Access to this particular keystore can be performed using the keytool command.

A common way to create this keystore is to use the SSL configurator utility, though one can also manually create the keystore using the java keytool command.

The keystore name is "casm.keystore" and one can view the contents of this keystore by running the following.

In an Admin command prompt, cd to the location of the SSL configurator, usually C:\CASM-SSL-Configurator-17.4.0, then run:

keytool.exe -list -v -keystore casm.keystore

You may need to prefix with the path to keystore, ie:

"C:\Program Files\CA\SC\JRE\11.0.18\bin\keytool.exe" -list -v -keystore casm.keystore

For the password, enter the same password you had been prompted with when creating this keystore.

In the following example, the SSL configurator utility was used to create a self-signed certificate for testing. The above command will show:

C:\CASM-SSL-Configurator-17.4.0>"C:\Program Files\CA\SC\JRE\11.0.18\bin\keytool.exe" -list -v -keystore casm.keystore
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: SM-SERVER-ALIAS
Creation date: Aug 8, 2023
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=SM-SERVER.DOMAIN.COM
Issuer: CN=SM-SERVER.DOMAIN.COM

Of particular value is the above alias. As this certificate was applied to configure SSL for SDM and xFlow, a simple way to check for this is to examine the following components:

SDM Tomcat: Look for the server.xml in NX_ROOT\bopcfg\www\CATALINA_BASE\conf

In this file, you should see references to the above "casm.keystore", ie:

    <Connector SSLEnabled="true" maxThreads="200" port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation">
      <SSLHostConfig ciphers="<omitted>" honorCipherOrder="true" protocols="TLSv1.2" sslProtocol="TLSv1.2">
        <Certificate certificateKeyAlias="SM-SERVER-ALIAS" certificateKeystoreFile="C:\CASM-SSL-Configurator-17.4.0/casm.keystore" certificateKeystorePassword="XXXX" certificateKeystoreType="PKCS12"/>
      </SSLHostConfig>
    </Connector>

SDM IIS: The certificate is imported directly into IIS. To view, go into IIS Manager, and on the server, choose "Server Certificates" to view the defined certificates (which should include the self signed certificate.

To view the binding configuration, access "Default Web Site" and choose "Bindings" Double click on the defined "https" entry, port 443, and you will see the binding definition and the associated certificate (alias is for the self-signed certificate)

xFlow: There are a series of "config.txt" files that will be deployed in the xFlow services folders:

C:\Program Files\CA\xFlow\APPS\Services\collabmicroservice-17.0.479\COLLABMICROSERVICE_config.txt
C:\Program Files\CA\xFlow\APPS\Services\incidentmicroservice-17.0.479\INCIDENTMICROSERVICE_config.txt
C:\Program Files\CA\xFlow\APPS\Services\insightmicroservice-17.1.706\INSIGHTMICROSERVICE_config.txt
C:\Program Files\CA\xFlow\APPS\Services\pushmicroservice-17.0.479\PUSHMICROSERVICE_config.txt
C:\Program Files\CA\xFlow\APPS\Services\searchmicroservice-17.0.479\SEARCHMICROSERVICE_config.txt

The files will largely read similarly, containing the specific keystore, and password to use. The above INCIDENTMICROSERVICE_config.txt will read something like this:

-Dhttps.port=9444 -Dplay.server.https.keyStore.path="C:\CASM-SSL-Configurator-17.4.0/casm.keystore" -Dplay.server.https.keyStore.password=XXXX

This indicates to start the given Incident Microservice on port 9444 using the above keystore path and password.

NX.Keystore:

The second kind of keystore one may encounter is the internal NX.keystore.

The NX.keystore is a keystore file that is controlled internally by Service Desk to keep track of certain certificates used to connect and integrate with various products. It is used to store the root CA cert file used to verify the SSL certificates that the mail host named in maileater uses, as well as any certificates that are deployed through PAM and Catalog and any other products that may integrate directly with Service Desk.

The NX.keystore is NOT used to store any SSL certificates that are used to implement SSL on the Tomcat/IIS Server or xFlow.

To view the contents of the NX.keystore, one must run a specific perl script, known as pdm_keystore_mgr.pl, which replaces the java keytool command. While NX.keystore is technically a keystore that could theoretically be read by the java keytool command, the password to this keystore is stored as an encrypted entry in the NX.env variable NX_KEYSTORE_REF. The pdm_keystore_mgr.pl has its own functionality to decrypt the nx.keystore password and it is not possible to access the NX.keystore by any other means apart from the pdm_keystore_mgr.pl. The encrypted password is also the main reason why one cannot use the NX.keystore to contain any SSL based certificates used in Tomcat, IIS, or xFlow.

To view the functionality of the pdm_keystore_mgr.pl script, run the following:

In an Admin Command prompt, run "nxcd bin"

Run the command

pdm_perl pdm_keystore_mgr.pl -h

This will list the above pdm_keystore_mgr.pl and its parameters.

Example: One has defined the following setup in a maileater mailbox:

As part of the configuration of this mailbox, a folder would have been created called C:\SSL-cert and the CA Certificate (Certificate Authority Certificate) placed into this location, under file "rootCA-google.cer"A

After the mailbox has been defined and created, one then goes into the SDM install bin folder (run "nxcd bin") then run the following command to view the certificates in the internal nx.keystore:

pdm_perl pdm_keystore_mgr.pl -list

The result that appears is:

C:\PROGRA~2\CA\SERVIC~1\bin>pdm_perl pdm_keystore_mgr.pl -list
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: nx_keystore
Creation date: Aug 8, 2023
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:

<OMITTED>

Alias name: rootca-google.cer
Creation date: Aug 9, 2023
Entry type: trustedCertEntry

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE

<OMITTED>

What we are interested in is the highlighted alias, which matches the certificate that was added as the CA Certificate in the above mailbox configuration. When the above mailbox is created or update, SDM will then import the above CA Certificate into the nx.keystore automatically if it is not present, without any further user intervention.