Understanding IBM cms keystore

Question

I have an IBM HTTP Server which is already using cms keystore. When deployment team created the keystore of type cms the ikeyman tool generated 4 files (key.kdb, key.sth, key.crl, key.rdb). I don't know which one is the keystore and what are the other files exactly. I need to know what they are as i'm recently almost working with IBM products. I hear that the key.sth is a stash file but i don't know it's meaning acctually. I would really appreciate if anyone can help me in that

Answer 1

You should treat them as an atomic set of files and never copy a subset. You always reference just the *.kdb from configuration or with the certificate management tools.

The *.kdb contains the private keys, certificiates, and CA's. It is encrypted with a password that can be stashed in the *.sth file.

The *.rdb contains information about outstanding certificate requests. It's critical that you maintain this 1:1 with the KDB.

The *.crl contains revocation info. It is generally not interesting, unless it gets corrupted/mismatched in which case it can cause runtime errors.

The *.sth is a way to store an obfuscated password to a file. Runtime tools can use this password instead of prompting for one interactively. It obviously has to be protected if you have private keys in the corresponding KDB.

The set all put together is similar to a PKCS12 file in other tools.

Answer 2

From ftp://ftp.software.ibm.com/software/webserver/appserv/library/v80/GSK_CapiCmd_UserGuide.pdf

How is a CMS key database organized? A CMS keystore consists of a file with extension .kdb and optionally two other files with extension .rdb and .crl respectively.

A key record in a .kdb file is either a certificate on its own or a certificate plus its encrypted private key information. Private keys cannot be stored in a CMS keystore without a corresponding certificate.

When a certificate request is created, a .rdb file with the same file stem as the key database file is created. This file is used to store the requested key pair, along with the PKCS#10 certificate request data. The request entry is only deleted from the request key database when a signed certificate is obtained from a signing authority and received into the key database. The signed certificate is matched up with the private key in the .rdb file and together they are added to the .kdb file as a certificate with private key information.

A .crl file is also created, purely for legacy reasons (in the past it contained Certificate Revocation Lists (CRLs)). This file is no longer used and is always empty.