I created certificate request posted this request to authority, got back signed cert. using iKeyman I have added all signers certificates and successfully received signed certificate into my key database. I saw how request was removed when personal cert was added. I closed iKeyman, and when I opened it again Personal cert. was no longer listed? and of cause I cannot received again, because request does not exists anymore. How I can recreate same request, or there any other way of adding personal cert to my key database.
Update from comments 15 Sept 2015
runmqakm -cert -list
showed list of certificates
OS - Windows Server 2008 R2
IKeyman version 8.0.382.CMS provider version 2.45.
Account under which all operations where performed is a local admin.
My output:
C:\ProgramData\IBM\MQ\ssl>runmqakm -cert -list all -db key.kdb
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Source database password : ******
Certificates found
* default, - personal, ! trusted, # secret key
! XXX-Root-CA
! XXX-Intermediate-CA
! XXX-Issuing-CA
! ibmwebspheremqusapp1u
C:\ProgramData\IBM\MQ\ssl>runmqakm -certreq -list all -db key.kdb
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Source database password : ******
No certificate requests were found
You are correct that the KDB has no personal cert and no outstanding CSR. However, if the cert with the label ibmwebspheremqusapp1u
is the one that is supposed to be the personal cert, it is now loaded as a trusted cert. There is no way to recover the private key from the KDB as described and if there's no backup file, that cert is irrecoverable. The best you can hope for is that the CA is one which allows customers to re-key a certificate.
It is not possible to arrive at this state without having issued a runmqakm -cert -add
. The expected command would have been a runmqakm -cert -receive
which would combine the response from the CA with the original outstanding CSR and create a complete personal certificate. Either that was done, or else this isn't the KDB in which that CSR was created, because as you point out, there are no outstanding CSRs.
Assuming there's no GSKit bug causing this and that this is the same KDB in which the CSR was created, then at some point after successfully receiving the CSR the personal cert was deleted and the response from the CA re-added using runmqakm -cert -add
. The alternatives are that the CSR was explicitly deleted (which I'm guessing you'd remember if that was the case) or else GSKit has a nasty and dangerous bug which you are so far the only person to discover.
It's difficult from this side of the screen to definitively determine GSKit bug or user error, however it is possible from your end to a) prevent this from ever happening again; and b) possibly make that definitive determination. "How do I do that," you ask?
Always back up a KDB or JKS before issuing commands against it once it has a private key, CSR or a personal certificate in it. You can always restore the trusted certs but a private key or anything that contains one is one-of-a-kind and irreplaceable. Don't risk losing it by operating against the only copy in existence.
For example, after submitting the CSR and on receipt of the response from the CA, copy the key.*
files to key.[timestamp].*
and mark the backup files as read-only before receiving the CSR back in. If the receive
succeeds then you are good to go. If not, you can copy the backups over the bad kdb, or into a new set of kdb files (never operate on the backups!) and attempt to recreate the problem to determine whether it's a bug or user error.
The backup KDB with the outstanding CSR will always get you back to the state you were in right after creating the CSR so you can retrace your steps as many times as necessary. If you can reliably recreate the error and believe it's a GSKit bug, open a PMR with IBM. It's an unlikely scenario but I know it happens because I once discovered a GSKit bug that blows away the entire keystore. Hence my slavish adherence to a backup-before-changing strategy. Like you, I too learned it the hard way.