6

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

2 Answers2

9

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.

covener
  • 17,402
  • 2
  • 31
  • 45
  • Does IHS server expect all the files and only the files in this format ? I have a .jks file. How do i use that ? – Jess Oct 09 '15 at 20:28
  • Yes, i did the conversion. `gsk7cmd -keydb -convert -db ihs_ssl.jks -old_format JKS -new_format cms –stash` here is the syntax just incase some one needs it handy. It will prompt for password. – Jess Oct 15 '15 at 20:16
  • Note: gsk7cmd won't run on Java 11. It's init code tries to create a File for java.ext.dirs, which was removed in 11, and even if you set it, the JVM will exit. – r590 Aug 18 '21 at 18:02
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.

mellow-yellow
  • 1,670
  • 1
  • 18
  • 38