Beginning with IBM Storage Protect version 8.1.2, automatic SSL encryption was introduced. Since then, a Master Encryption Key is automatically generated during the installation of the ISP server and stored in the key database dsmkeydb.kdb. Also during the installation, the cert256.arm certificate is generated and stored in the key database cert.kdb.
The master encryption key in dsmkeydb.kdb is the private key and the cert256.arm file stored in the key database cert.kdb is the public key.
SSL communication only takes place via the key databases dsmkeydb.kdb and cert.kdb. The cert256.arm file is no longer actively used. In some cases, it may be necessary to manually import the cert256.arm certificate into the client's key database dsmcert.kdb using the dsmcert command (dsmcert -add -server). However, this usually happens automatically.
Key | Key Database | Key Type |
Master Encryption Key | dsmkeydb.kdb | Private Key |
cert256.arm File | cert.kdb | Public Key |
All relevant files are located in the ISP server instance directory.
The ISP certificate cert256.arm has expired, works as designed?
When we asked the IBM support, they confirmed that yes, this is "works as designed", the certificates expire after 10 years without warning. This is exactly what happened with two of our customers. One of them was "lucky" because it "only" affected the Library Manager. Unfortunately, the other customer was not so lucky. On the affected ISP server with version 8.1.12.000, all kinds of clients were backed up, including many SAP systems (BACKINT) with storage agents. Normal operation was only possible after about 1.5 days, because after the renewal of the cert256.arm file, all client certificates were also invalid.
What happens when the IBM Storage Protect server certificate cert256.arm expires?
The answer is very simple, the server continues to run, but it can no longer be accessed.
The server must then be shut down hard.
If you then start the server in the foreground, the message ANR8583E with the return code 401 GSK_ERROR_BAD_DATE appears for every session.
How to check the expiry date of an IBM Storage Protect server certificate?
First of all, it is important to know that the cert256.arm certificate is not used for SSL communication.
The SSL communication takes place via the key database cert.kdb, into which the server certificate cert256.arm (public key) was imported after generation.
Therefore, it is first important that the correct certificate in the key database cert.kdb is checked for the expiry date.
This can be determined with the following gsk8capicmd_64 commands:
Command to read out the cert.kdb:
gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Command to read out the cert.kdb with details on the label "TSM Server SelfSigned SHA Key":
gsk8capicmd_64 -cert -details -db cert.kdb -stashed -label "TSM Server SelfSigned SHA Key"
In this example, the certificate expired on January 6, 2023 3:18:50 PM.
Renew IBM Storage Protect self-signed certificate cert256.arm
To renew the self-signed certificate cert256.arm, the following steps are required:
1. Stop the ISP-Server
2. Create a copy of the following files:cert256.armcert.kdbcert.sthcert.rdbcert.crl
3. Delete only the file cert256.arm
4. Delete the old server certificate from the key database with the following command:
gsk8capicmd_64 -cert -delete -db cert.kdb -stashed -label "TSM Server SelfSigned SHA Key"
5. Start ISP server in the foreground (maintenance)
A recommendation at this point is to start dsmserv in maintenance mode (dsmserv maintenance).
During the start-up process, a new certificate with the label "TSM Server SelfSigned SHA Key" is generated and stored in the key database cert.kdb.
In addition, a new cert256.arm file is created.A recommendation at this point is to start dsmserv in maintenance mode (dsmserv maintenance).
6. UPDATE ADMIN SESSIONSECURITY=TRANSITIONAL
Now, via the console of the server that was started in the foreground, the administrator must be set to SESSIONSECURITY=TRANSITIONAL, which is to be used for logging in when the system has been restarted normally (in the background).
Console: UPDATE ADMIN admin_name SESSIONSEC=TRANS
7. Stop the ISP server in the foreground with HALT and start it again normally.
8. Set all active ADMINs, NODESs, SERVERs and STAs to SESSIONSECURITY=TRANSITIONAL.
9. Update the server-to-server communication with the option FORCESYNC=YES.
10. Renew all client certificates (for admins and nodes).
If an UPDATE with SESSIONSECURITY=TRANSITIONAL is not enough, the newly created certificate cert256.arm must be copied to the clients. This point is certainly the most time-consuming of all and requires the most time for this action.
The certificate files including the key database of the client are located in the installation directory.
Windows:
…\baclient
Unix/Linux:
…/client/ba/bin resp. bin64
This certificate can be added to the client's key database with the following command:
dsmcert -add -server <servername> -file <path_to_cert256.arm>
Update on this subject by IBM
IBM has provided the following technote on this topic:
IT42905: HOW TO RENEW AN IBM SPECTRUM PROTECT SERVER SSL CERTIFICATE
You can vote to push the topic "Expired server certificates" at IBM's priority list in the IBM Ideas portal here:
If you find yourself in this situation and need help, or if you simply want to check your certificates, we will be happy to advise you.
