Each profile in the WebSphere® Application Server environment contains a unique chained certificate signed by a unique long lived root certificate that was created when the profile was created. This certificate replaces the default self-signed certificate that ships with WebSphere Application Server Version 6.1 as well as the default dummy certificate that ships in releases prior to Version 6.1. When a profile is federated to a deployment manager, the signer for the root signing certificate is added to the common truststore for the cell, establishing trust for all certificates signed by that root certificate.
By default, clients do not trust servers from different profiles in the WebSphere Application Server environment. That is, they do not contain the root signer for these servers. There are some things that you can do to assist in establishing this trust:
/QIBM/UserData/WebSphere/AppServer/V7/Base/profiles/default/bin/serverStatus -all ADMU0116I: Tool information is being logged in file /QIBM/UserData/WebSphere/AppServer/V7/Base/profiles/default/logs/serverStatus.log ADMU0128I: Starting tool with the default profile ADMU0503I: Retrieving server status for all servers ADMU0505I: Servers found in configuration: ADMU0506I: Server name: server1 *** SSL SIGNER EXCHANGE PROMPT *** SSL signer from target host 192.168.1.5 is not found in truststore /QIBM/UserData/WebSphere/AppServer/V7/Base/profiles/default/etc/trust.p12. Here is the signer information (verify the digest value matches what is displayed at the server): Subject DN: CN=myhost.austin.ibm.com, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Issuer DN: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Serial number: 2510775664686266 Expires: Thu Feb 19 15:58:49 CST 2009 SHA-1 Digest: 2F:96:70:23:08:58:6F:66:CD:72:61:E3:46:8B:39:D4:AF:62:98:C3 MD5 Digest: 04:53:F8:20:A2:8A:6D:31:D0:1D:18:90:3D:58:B9:9D Subject DN: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Issuer DN: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Serial number: 2510773295548841 Expires: Tue Feb 15 15:58:46 CST 2028 SHA-1 Digest: 2F:96:70:23:08:58:6F:66:CD:72:61:E3:46:8B:39:D4:AF:62:98:C3 MD5 Digest: 04:53:F8:20:A2:8A:6D:31:D0:1D:18:90:3D:58:B9:9D Add signer to the truststore now? (y/n) y A retry of the request may need to occur. ADMU0508I: The Application Manager Manager "server1" is STARTEDTo automate this process, see retrieveSigners command.
When a prompt occurs to accept the signer, a socket timeout can occur and the connection might be broken. For this reason, the message A retry of the request may need to occur. displays after answering the prompt. The message informs the user to resubmit the request. This problem should not happen frequently, and it might be more prevalent for some protocols than others.
A retry of the request may need to occur if the socket times out while waiting for a prompt response. If the retry is required, note that the prompt will not be re-displayed if (y) is entered, which indicates the signer has already been added to the trust store.
Verify the displayed SHA-1 digest, which is the signature of the certificate that is sent by the server. If you look at the certificate on the server, verify that the same SHA-1 digest displays.
You can disable the prompt when you do not want it to display by running the retrieveSigners utility to retrieve all of the signers for a particular cell. You can download or upload the signers from any remote keystore to any local keystore by referencing a common truststore with this client script. For more information, see Default chained certificate configuration in SSL.
The typical remote keystore to reference is NodeDefaultTrustStore.
The truststore contains the signers that enable the client to connect to its processes. The retrieveSigners utility can point to any keystore in the target configuration, within the scope of the target process, and can download the signers (certificate entries only) to any client keystore in the ssl.client.props file.To collect all of the signers for the cell in a single trust.p12 keystore file, complete following steps:
The following two code samples show you a before and an after view of the changes to make.
com.ibm.ssl.protocol=SSL com.ibm.ssl.keyStore=/QIBM/UserData/WebSphere/AppServer/V7/Base/ profiles/default/etc/ DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.keyStoreType=JKS com.ibm.ssl.trustStore= /QIBM/UserData/WebSphere/AppServer/V7/Base/profiles/default/etc/DummyClientTrustFile. jks com.ibm.ssl.trustStorePassword= {xor}CDo9Hgw\= com.ibm.ssl.trustStoreType=JKSSSL configuration changes that are required to common truststore file in the /etc directory of the client
com.ibm.ssl.protocol=SSL com.ibm.ssl.keyStore=/QIBM/UserData/WebSphere/AppServer/V7/Base/ profiles/default/etc/ DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.keyStoreType=JKS com.ibm.ssl.trustStore=/QIBM/UserData/WebSphere/AppServer/V7/Base/profiles/default/etc/ trust.p12 com.ibm.ssl.trustStorePassword=myhostNode01Cell com.ibm.ssl.trustStoreType=PKCS12
You can also make these changes in the soap.client.props file and specify the key.p12 file in place of the DummyClientKeyFile.jks file. However, you must also change the keyStorePassword and keyStoreType values to match those in the default key.p12 file.
In releases of WebSphere Application Server prior to version 7.0, you must edit the SSL configuration on the server to replace the common truststore. The trust.p12 file, which is used by the server, also must contain the default dummy certificate signer for connections among servers at previous release levels. You might need to manually extract the default certificate from the DummyServerKeyFile.jks file and then import the certificate into the trust.p12 file that you added to the configuration.