Procedure to get .kdb file password | To open .kdb file in ikeyman window

— ny_wk

If you have lost the password to an IBM GSKit .kdb key database but still have its companion .sth stash file, you can recover the original keystore password in seconds. The stash file is a lightly obfuscated copy of the same password that lets servers like IBM HTTP Server start without a human typing the passphrase — and that obfuscation is trivially reversible. This guide shows the safe, supported way to recover a .kdb keystore password so you can open the database in iKeyman (the GSKit GUI) or manage it from the command line.

Important context up front: recovering a stash-protected password is a legitimate operational task only on systems you own or administer. Do not use it to access keystores you are not authorized to manage. Also note that iKeyman is legacy — the modern, fully supported tooling is the command-line utility gsk8capicmd_64 (GSKit 8) or runmqckm on systems that ship it. The technique below works regardless of which front end you use.

What the .kdb and .sth files actually are

IBM GSKit (Global Security Kit) stores SSL/TLS certificates and private keys in a key database. A complete keystore is really a small set of files that must travel together:

• name.kdb — the encrypted key database holding certificates and private keys.
• name.sth — the stash file: an obfuscated copy of the database password, so daemons can open the .kdb unattended at boot.
• name.rdb — the request database (pending certificate requests / CSRs).
• name.crl — an optional cache for certificate revocation lists.

The .sth file exists precisely so a service can start without prompting. That convenience is also why the password inside it is recoverable: the stash is not strong encryption. It is a byte-by-byte XOR mask applied to the plaintext password. Anyone who can read the file can recover the password, which is why .sth files must be protected with strict filesystem permissions (owner-only, 0600).

The problem: opening a .kdb when you lost the password

iKeyman, gsk8capicmd, and runmqckm will all refuse to open a .kdb without the correct password — there is no “reset” that preserves the existing keys. If the original password was never documented but the service still starts cleanly, the answer is sitting right next to the database in the stash file. Recovering it lets you open the keystore in iKeyman, add or renew certificates, and re-stash a new password if you want to rotate it.

Step-by-step: recover the .kdb keystore password

There are two reliable methods. Method A uses IBM's own supported tooling and is the one to prefer in production. Method B is the classic XOR de-stash, useful when the GSKit binaries are not on your PATH or you need to understand exactly what the stash format is.

Step 1 — Locate the keystore files on the server

Find every key database on the host, then confirm a matching stash file lives beside it:

1. Search the filesystem for the database (limit the scope to avoid scanning the whole disk):

   find /opt /etc /home -name '*.kdb' 2>/dev/null

2. For each result, confirm its companion .sth exists in the same directory with the same base name. For example, if the database is /opt/IBM/HTTPServer/certs/webserver.kdb, the stash must be /opt/IBM/HTTPServer/certs/webserver.sth:

   ls -l /opt/IBM/HTTPServer/certs/webserver.*

Why the names must match: GSKit pairs the stash to the database by identical path and base name. A .sth copied from a different keystore will decode to the wrong password.

Step 2 — Work on a copy, never the live files

Before touching anything, copy the keystore files to a safe working directory. This protects the running service from accidental corruption:

1. Make a working copy:

   mkdir -p ~/kdb-recovery && cp -p /opt/IBM/HTTPServer/certs/webserver.* ~/kdb-recovery/

2. The -p flag preserves ownership, permissions, and timestamps so you can see the original (hopefully restrictive) mode on the stash file.

Step 3 (Method A) — Read the password with the supported GSKit utility

GSKit ships a command that prints the stashed password directly. This is the cleanest approach because it uses IBM's own code path. Locate the binary first — it lives under the GSKit install, commonly /usr/local/ibm/gsk8_64/bin/ or inside the product (for IBM HTTP Server, <IHS>/bin/):

1. Find the GSKit command-line tool:

   find / -name 'gsk8capicmd_64' 2>/dev/null

2. Print the password held in the stash for a given database:

   gsk8capicmd_64 -keydb -stashpw -db ~/kdb-recovery/webserver.kdb -stash

If your platform uses IBM MQ's wrapper instead, the equivalent is runmqckm -keydb -stashpw -db webserver.kdb -stash. Once you have the password, you can open the database non-interactively to verify it, for example by listing the certificates:

gsk8capicmd_64 -cert -list -db ~/kdb-recovery/webserver.kdb -pw '<recovered-password>'

Step 3 (Method B) — Decode the stash with the XOR mask

When the GSKit binaries are unavailable, you can recover the password directly because the .sth format is simply each plaintext byte XOR-ed with the constant 0xF5, terminated by a null byte. A short, correct Perl one-file script does the job:

1. Create the de-stash script, for example destash.pl:

   use strict; use warnings;
die "Usage: $0 <stash-file.sth>\n" if @ARGV != 1;
my $file = $ARGV[0];
open(my $fh, '<:raw', $file) or die "Can't open $file: $!";
my $stash; read($fh, $stash, 1024); close($fh);
my @bytes = map { $_ ^ 0xF5 } unpack('C*', $stash);
for my $c (@bytes) { last if $c == 0; printf '%c', $c; }
print "\n";

2. Run it against the stash file:

   perl destash.pl ~/kdb-recovery/webserver.sth

3. The recovered password prints to your terminal. If you piped it anywhere, treat that output as a secret and clear your scrollback.

Equivalent in Python (no Perl needed), which makes the format obvious:

1. Decode in one line:

   python3 -c "d=open('webserver.sth','rb').read(); print(bytes(b^0xF5 for b in d).split(b'\\x00')[0].decode())"

Note on the original source script: the legacy version of this script compared bytes against zero using the string operator eq ($c eq 0) and omitted use warnings. Use the numeric comparison $c == 0 and open the file in raw/binary mode (<:raw) so multibyte or high-bit characters are not mangled by text-mode translation. The corrected script above reflects those fixes.

Step 4 — Open the keystore in iKeyman (optional GUI)

With the password in hand, you can open the database in the iKeyman GUI if you prefer a visual tool:

1. Launch iKeyman (it needs an X11 display; export DISPLAY or use X forwarding over SSH with ssh -X):

   /usr/local/ibm/gsk8_64/bin/gsk8ikm_64

2. Choose Key Database File → Open, set the type to CMS, browse to your .kdb, and enter the recovered password.
3. You can now view, import, export, or renew certificates and private keys.

Because iKeyman is deprecated, IBM recommends doing the same operations from the command line with gsk8capicmd_64 on new work — it is scriptable, headless, and the only option on minimal servers.

Common pitfalls when recovering a .kdb keystore password

• Mismatched stash and database. The most common mistake is copying a .sth from one keystore next to a different .kdb. The decode “succeeds” but the password fails to open the database. Always keep the original pairing.
• Text-mode reads corrupting the bytes. Reading the stash without binary mode can translate line-ending bytes and produce a wrong password. Open in raw mode (<:raw in Perl, 'rb' in Python).
• Using string comparison for the null terminator. In Perl, $c eq 0 works only by coincidence; use the numeric $c == 0 to stop at the real null byte.
• Editing the live keystore. Always operate on copies. A half-written .kdb can take down the service that depends on it.
• Leaking the recovered password. The output is the real keystore password. Do not log it, paste it into tickets, or leave it in shell history (history -d or run with a leading space if HISTCONTROL=ignorespace).
• Loose permissions on the stash. If anyone can read the .sth, anyone can read the password. The file should be 0600 and owned by the service account.

Verification: confirm the recovered password works

Never assume the decode is correct — prove it by opening the database with the password:

1. List the certificates using the recovered password. If the command returns the certificate labels, the password is correct:

   gsk8capicmd_64 -cert -list all -db ~/kdb-recovery/webserver.kdb -pw '<recovered-password>'

2. Check certificate expiry while you are in there (handy during an SSL certificate renewal):

   gsk8capicmd_64 -cert -details -db ~/kdb-recovery/webserver.kdb -pw '<recovered-password>' -label '<cert-label>'

3. If you decide to rotate the password, set a new one and write a fresh stash so the service keeps starting unattended:

   gsk8capicmd_64 -keydb -changepw -db ~/kdb-recovery/webserver.kdb -pw '<old>' -newpw '<new>' -stash

The -stash flag regenerates the .sth for the new password. After validating on your copy, deploy the updated files back into the certs directory and restart the service during a maintenance window.

Quick reference: the GSKit keystore file set

Modern equivalent and security note

Two things every systems administrator should internalize. First, iKeyman is legacy; for anything new use gsk8capicmd_64 (or runmqckm with IBM MQ). Second, because the stash is reversible by design, the .sth file is effectively a plaintext password in disguise — its only protection is filesystem permissions. Lock it down, keep it off shared mounts and backups that escape the host, and rotate keystore passwords when staff change. The recovery technique here is a legitimate operations tool; the same property that makes it convenient is exactly why the stash must be guarded.

Key Takeaways

• The .sth stash file is an obfuscated (XOR with 0xF5) copy of the .kdb password — recoverable, not strong encryption.
• Prefer the supported route: gsk8capicmd_64 -keydb -stashpw -db file.kdb -stash to print the password; fall back to a corrected XOR script only when needed.
• Keep the .kdb and .sth paired by identical path and base name, and always work on copies of the live files.
• Always verify by opening the database (-cert -list) with the recovered password before trusting it.
• iKeyman is deprecated — use the GSKit command line, and protect every .sth file with 0600 permissions.

Frequently Asked Questions

How do I open a .kdb file in iKeyman without the password?

You cannot bypass the password, but if the companion .sth stash file exists you can recover the original password from it and then enter that in iKeyman. Run gsk8capicmd_64 -keydb -stashpw -db your.kdb -stash to print it, or decode the stash with the XOR-0xF5 script, then open the CMS database in iKeyman normally.

Is the GSKit .sth stash file encrypted?

No. The stash applies a simple, fixed XOR mask (0xF5) to each character of the plaintext password and ends with a null byte. It is obfuscation for unattended startup, not cryptographic protection, so anyone who can read the file can recover the password. Restrict it to 0600.

What replaces iKeyman for managing key databases?

The supported, scriptable replacement is the command-line utility gsk8capicmd_64 (GSKit 8), or runmqckm on IBM MQ installations. They perform every iKeyman operation — create databases, import/export certificates, change passwords, regenerate the stash — without a GUI or X11 display.

How do I change the keystore password and update the stash?

Use gsk8capicmd_64 -keydb -changepw -db your.kdb -pw '<old>' -newpw '<new>' -stash. The -stash flag rewrites the .sth so dependent services still start unattended with the new password.

For more hands-on Linux and systems-administration walkthroughs, subscribe to our YouTube channel @explorenystream.