5.5.6.2.1.1 Creating a server key store
This will show how to:
Create a keyfile.jks file
Create a self-signed certificate in the keyfile.jks file.
Export the signer certificate from the keyfile.jks to a cert.arm file.
5.5.6.2.1.2 Creating a client trust store
This will show how to
Create a trust.jks
Add the signer certificate exported from the keyfile.jks to the new
trust.jks file.
Follow the steps in section 5.5.6.2.1.1 to create the ServerKeyFile. The
self-signed certificate will only have to be created once in the
ServerKeyFile. Then export the certificate as a cert.arm file to be used
later in the ServerTrustFile, ClientKeyFile, and ClientTrustFile. You will
then need to take one additional step not listed in section 5.5.6.2.1.1 to
add the certificate back into the ServerKeyFile just created. To do this,
go to signer certificates and add the cert.arm file.
The instructions for section 5.5.6.2.1.2 "Creating a client trust store"
will be the same for the trust and client files (ServerTrustFile,
ClientKeyFile and ClientTrustFile). The cert.arm exported from the
ServerKeyFile is what gets added to the other ServerTrustFile,
ClientKeyFile and ClientTrustFiles as a signer certificate.
To make these files accessible to Admin Server, open the "Security
Center" in the administrative console. From the General tab, press the
Default SSL Configuration button. Enter the proper path/file names in the
fields provided for the ServerKeyFile and ServerTrustFile and press the OK
button.
The sas.server.props file will be automatically updated to use the
new server keyrings once WebSphere has been restarted. But you must modify
the sas.client.props file manually to point to the ClientKeyFile
and ClientTrustFiles complete with passwords.
In order to have the new keyrings take effect you will stop and restart
WebSphere.
Problems:
If the Admin Server will not start after making the changes and you see
these messages in the tracefile.
[01.12.13 15:20:48:501 CST] 4db20d01
ORBRas W com.ibm.CORBA.iiop.Util Util
P=447690:O=0:CT JORB0012: Pass by reference has been set to: true
(NoLocalCopies = true)
[01.12.13 15:20:53:529 CST] 4db20d01 ORBRas
X com.ibm.CORBA.iiop.IIOPConnection send P=447690:O=0:CT The
following exception was logged
javax.net.ssl.SSLHandshakeException: handshake failure
Confirm that the changes were properly updated in the
sas.server.props file. You may just have to try restarting
WebSphere a second time if the first attempt did not update the properties
file. Also confirm the keyfile paths, file permission's, and passwords are
correct.
If the Admin Server starts but the Admin Console or App Servers will not
start, confirm that the keyfile paths and passwords are correct in the
sas.client.props file as well as file permission's.
For remote consoles:
If your remote console is used solely to access the server where you have
replaced your key files, you will have to copy the ClientKeyFile.jks and
ClientTrustFile.jks to the remote system. Then the sas.client.props file
can be updated to point to these new files.
If you use your remote console to connect to the server where you have
replaced you key files as well as to servers where they haven't being
replaced, then you will have to copy the cert.arm file. Import the
cert.arm file in both client jks files being used. These files are listed
in the remote sas.client.props file.
NOTE:
It should be possible to create only 1 keystore file (jks file) complete
with self-signed cert and signer cert and have server key, server trust,
client key and client trust use this one file. There is currently a defect
opened to allow this to happen but as of this writing it will not work for
the Admin Server. |