Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Running WAS 6.1.xx in a network deployment. The IBM provided plugin keystore's "plugin-key.kdb" password expires on april 26th along with the personal cert inside it.

So no problem right? Create new cert and set new password on the kdb, restash the password and off we go!

Well no! On restart of IBM HTTP Server we see

[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: lib_security: logSSLError: str_security (gsk error 408):  GSK_ERROR_BAD_KEYFILE_PASSWORD
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: lib_security: initializeSecurity: Failed to initialize GSK environment
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_transport: transportInitializeSecurity: Failed to initialize security
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_server: serverAddTransport: Failed to initialize security
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_server: serverAddTransport: HTTPS Transport is skipped
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: lib_security: logSSLError: str_security (gsk error 408):  GSK_ERROR_BAD_KEYFILE_PASSWORD
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: lib_security: initializeSecurity: Failed to initialize GSK environment
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_transport: transportInitializeSecurity: Failed to initialize security
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_server: serverAddTransport: Failed to initialize security
[Tue Apr 24 14:11:22 2012] 00b00004 00000001 - ERROR: ws_server: serverAddTransport: HTTPS Transport is skipped

Here is the thing ... I can open the keystore using the new password with ikeyman and keytool. Using some "slightly dodgy" script, I can reverse the stash file and see that indeed the new password is set.

Then, even if I restore the old keystore files (plugin-key.kdb,plugin-key.crl,plugin-key.sth,plugin-key.rdb) they no longer work either!

So it must be permissions right? Well the permissions are the same as before, if I switch to apache user I can browse right through to the files and read them. I have even chown'ed them to apache:apache and/or chmod 777 and still its the same error!

Does anyone have a clue what is going on here? Its pretty urgent as our site will be without HTTPS in a couple of days if this isn't resolved - thats bad for a retail web site :)

share|improve this question
add comment

3 Answers

The solution to this is documented here: http://ibm.com/support/docview.wss?uid=swg21588312

Did you follow these steps?

share|improve this answer
    
It was in implementing this that problems began. The solution to the greater issue is straight forward as described by that document. However we have now found the error. It seems that in another part of the plugin-cfg.xml there were some typos and having restored a backup the problem is gone. So the problem was nothing to do with the keystores despite what every error in all the IBM logs told us. Beginning to think that is how IBM make their money - send people looking in the wrong place with bad error messages and then they will need a consultant to fix it ;) –  Seer Apr 25 '12 at 9:29
add comment

It can also be that your plugin-key.crl and plugin-key.rdb files are no longer in synch with your plugin-key.kdb file and should be removed. This can be the case in ND environments.

This is related to but not the same issue as: http://www-01.ibm.com/support/docview.wss?uid=swg21177702

Step 3 in this tech note can give a clue to also solving this issue: "If there is an RDB (for example, plugin-key.rdb) and CRL (for example, plugin-key.crl) in the same directory as the plugin-key.kdb and plugin-key.sth file, remove these files from the directory."

share|improve this answer
    
As mentioned in the comments of the last answer - it had zero to do with the keyfiles themselves or even their configuration in the plugin file. A typo in another part of the plugin (within the virtual hosts of a another cluster in fact) was the culprit. This was the very common example of an IBM log sending us on a wild goose chase for an error which in fact didn't exist. If it had of been a problem with the actual keystores, you are right, those would be things to look into and indeed we did remove the crl and rdb files at one point whilst still hunting the goose :) –  Seer May 10 '12 at 8:05
    
I'd be interested to see what "other" typo in plugin-cfg.xml (a file you shouldn't, generally speaking, be editing) results in the security library reporting GSK_ERROR_BAD_KEYFILE_PASSWORD. –  covener Nov 23 '12 at 18:01
add comment

Given what happened, I'd be more concerned on how the plugin-cfg.xml file ended up with "typos"; are there other IT folks who have access to the server that can potentially edit that file? The IHS Plugin file is generated by WAS to tell IHS how to load balance, along with a ton of other settings (timeouts, etc...), most, of not all, of which can be set in the admin console and propogated to the plug-in without the need to manually edit the file.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.