Expert GuideHow to use 3rd party certificates in IBM Storage Protect

Preconditions

In our example, we assume a freshly installed IBM Storage Protect, being set up as follows:

• Instance directory: /tsminst1/
• Home directory: /home/tsminst1/
• Installation directory: /opt/tivoli/tsm/
• Server FQDN: isp01.imperius.mtr (don't ask, you may of course use your own)

We assume that the server is already formatted, can be launched as a foreground process and that the default certificate was created. Also, we assume a working client, which already runs on another host:

• Installation directory: /opt/tivoli/tsm/client/

On the server, we change into the instance user tsminst1 and the instance directory /tsminst1. All commands are to be run in this context unless mentioned otherwise. Let's take a look at the existing situation:

• gsk8capicmd_64 -cert -list -db /tsminst1/cert.kdb -stashed

On a freshly installed server, we should get something like this:

Certificates found
* default, - personal, ! trusted, # secret key
*-    "TSM Server SelfSigned SHA Key"

There is one certificate available, which was created during install/format of IBM Storage Protect.

We find cert256.arm within the instance directory, which contains the self signed certificate created by IBM Storage Protect. In our setup, we installed it into the client's keystore:

gsk8capicmd_64 -cert \
-add \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed -label "TSM Server SelfSigned SHA Key" \
-file /root/files/cert256.arm \
-format ascii`

Now we can take a look at the keystore:

• gsk8capicmd_64 -cert -list -db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb

Which should yield a similar result:

Certificates found
* default, - personal, ! trusted, # secret key
...
!    "TSM Server SelfSigned SHA Key"

A number of Certificate Authority was also contained, which we skipped (Entrust, VeriSign, Thawte). It should now be possible to connect to the server using dsmadmc.

Your own Public Key Infrastructure (PKI)

But now we want to use our own Public Key Infrastructure (PKI) instead of the self signed certificate created by IBM Storage Protect (ISP), which means that we want to create and sign certificates outside of ISP.

We may use an organisation wide or public Certificate Authority (CA), but we would strongly advise against the latter.

We want to end up with three certificates:

• ca.crt - the certificate of our certificate authority, also called root certificate
• intermediate.crt - an intermediary certificate
• isp01.imperius.mtr.01.crt - our server certificate

All files are assumed to use PEM, which is the default format used by openssl. isp01.imperius.mtr is used as server address, which you can change at leisure.

Our certificate authority

To create aforementioned files, we start by creating our own certificate authority, starting with a key:

• openssl genrsa -out ca.key 4096

We now create our own, self signed CA certificate, which is more complicated:

openssl req \
-x509 \
-new \
-nodes \
-extensions v3_ca \
-key ca.key \
-days 1024 \
-out ca.crt \
-sha512 \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=Test Certificate Authority/"

This results in a certificate authority (CA) which can be used for 1024 days.

An intermediary certificate

We create another certificate below the CA, which is often used. There are several reasons for doing so:

1. We may - and should! - place the CA key into a secure vault. This lowers the risk of the whole CA getting compromised.
2. We can partition the certificate space, into, say, VPN, Servers and Mail Encryption. If servers and and clients are set up correctly, clients such as dsmcwill only trust certificates signed by the intermediary certificate.

We start by creating another key:

• openssl genrsa -out intermediate.key 4096

Followed by the intermediary certificate:

openssl req \
-x509 \
-new \
-nodes \
-extensions v3_ca \
-key intermediate.key \
-days 1024 \
-out intermediate.crt \
-sha512 \
-CA ca.crt -CAkey ca.key \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=Test Intermediate Certificate/"

Server certificate

Now we create our last key, the server key:

• openssl genrsa -out isp01.imperius.mtr.01.key 4096

And use it to create the server certificate:

openssl req \
-x509 \
-new \
-nodes \
-key isp01.imperius.mtr.01.key \
-days 1024 \
-out isp01.imperius.mtr.01.crt \
-sha512 \
-CA intermediate.crt -CAkey intermediate.key \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=isp01.imperius.mtr/" \
-addext="subjectAltName=DNS:isp01.imperius.mtr,DNS:isp01.securezone.imperius.mtr" \
-addext="basicConstraints=critical,CA:FALSE" \
-addext="keyUsage=nonRepudiation, digitalSignature, keyEncipherment"

Some extensions are used here, of which subjectAltName allows us to use aliases for our server, in this case isp01.imperius.mtr and isp01.securezone.imperius.mtr.

By now, server key and server certificate are stored in two separate files, which IBM Storage Protect cannot use. We therefore have to convert it into a different format that joins key and certificate into one file (PKCS12). Doing so, we'll have to enter and keep a passphrase. The value of name is arbitrary, but will be needed on import.

openssl pkcs12 -export \
-in isp01.imperius.mtr.01.crt \
-inkey isp01.imperius.mtr.01.key \
-out isp01.imperius.mtr.01.p12 \
-name "server"

Now we have everything what we need. Please note again, that this setup describes a Certification Authority (CA) setup for testing purposes, which you should not use directly to implement your own CA. If you need guidance in designing and creating your own CA, please do not hesitate to use our contact information as provided at the end of this text.

Configuring the server

To configure the server, we're either able to use dsmadmc to connect to the server or to launch it as a foreground process.

As a first step, we check the existing configuration within the instance directory /tsminst1 as *instance user tsminst1:

gsk8capicmd_64 -cert \
-list \
-db /tsminst1/cert.kdb \
-stashed

On a freshly installed IBM Storage Protect, the certificate which was created by the server should appear:

Certificates found
* default, - personal, ! trusted, # secret key
*-    "TSM Server SelfSigned SHA Key"

Now we add the certificate which we created and converted to pkcs:

gsk8capicmd_64 -cert -import \
 -file isp01.imperius.mtr.01.p12 \
 -label "server" \
 -type pkcs12 \
 -target cert.kdb \
 -target_stashed \
 -new_label "Server Certificate"

Now we need to add both the Root- and intermediate certificate, starting with the root certificate:

gsk8capicmd_64 -cert \
-add \
-file ca.crt \
-db cert.kdb \
-stashed \
-label "CA Certificate"

Followed by installing the intermediate certificate:

gsk8capicmd_64 -cert \
-add \
-file intermediate.crt \
-db cert.kdb \
-stashed \
-label "Intermediate Certificate"

If we check the certificate store again, we should get the Server Certificate, Intermediate Certificate, Root Certificate as well as the original self signed certificate:

• gsk8capicmd_64 -cert -list -db cert.kdb -stashed

Expected result:

Certificates found
* default, - personal, ! trusted, # secret key
!    "CA Certificate"
!    "Intermediate Certificate"
*-    "TSM Server SelfSigned SHA Key"
-    "Server Certificate"

Now IBM Storage Protect needs to be told which certificate to use, which is done in ISP itself since version 8.1.20.
We either start the server as a foreground process or connect via dsmadmc and use the necessary command:

• set defaulttlscert "Server Certificate"

IBM Storage Protect should acknowledge:

ANR3882I SET DEFAULTTLSCERT: Certificate with label "Server Certificate" is now the default.

If it fails, please check:

• does the label match the label used in cert.kdb?
• have you imported the correct root and intermediate certificate?

If everything checks out, please restart the server. If restarted as foreground process, you should see a reference to the new certificate:

ANR7800I DSMSERV generated at 04:36:59 on Dec  5 2024.

IBM Storage Protect for Linux/x86_64
Version 8, Release 1, Level 25.000

Licensed Materials - Property of IBM

(C) Copyright IBM Corporation 1990, 2024.
All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corporation.

ANR7801I Subsystem process ID is 3252.
ANR0900I Processing options file /tsminst1/dsmserv.opt.
ANR7814I Using instance directory /tsminst1.
ANR3339I Default Label in key data base is Server Certificate. 
ANR4196W TLS certificate "Server Certificate", will expire on 06/18/2025 01:08:11 PM.

Now the server configuration is done.

Configuring the client

Trying to connect using dsmadmc will inevitably fail, as the client does not trust the server anymore. We have to import the root certificate into the client's keystore:

gsk8capicmd_64 -cert \
-add \
-file ca.crt \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed \
-label "CA Certificate"

We also have to add the intermediate certificate:

gsk8capicmd_64 -cert \
-add \
-file intermediate.crt \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed \
-label "Intermediate Certificate"

Now we check both:

• gsk8capicmd_64 -cert -list -db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb -stashed

In our case, dsmcert.kdb contained a list of preinstalled certificates, but only those we installed are important:

Certificates found
* default, - personal, ! trusted, # secret key
...
!    "TSM Server SelfSigned SHA Key"
!    "CA Certificate"
!    "Intermediate Certificate"

After that we should be able to connect using dsmadmc.

Cleanup

We may cleanup afterwards and remove the self signed certificate as created by IBM Storage Protect itself. We use gsk8capicmd_64 again to remove the certificate on the server:

gsk8capicmd_64 -cert \
-delete \
-db /tsminst1/cert.kdb \
-stashed \
-label "TSM Server SelfSigned SHA Key"

After that, we do the same on the client:

gsk8capicmd_64 -cert \
-delete \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \ 
-stashed \
-label "TSM Server SelfSigned SHA Key"

Conclusion

We were able to show and implement how IBM Storage Protect is configured to use 3rd party certificates as created by a Public Key Infrastructure. Clients and servers now trust each other if they know and use the same CA. It is, however, imperative that you keep a tight control on who is authorized to create and request certificates.