Each profile in the WebSphere Application Server environment contains a unique self-signed certificate that was created when the profile was created. This certificate replaces the default dummy certificate that ships with WebSphere Application Server in releases prior to version 6.1. When a profile is federated to a deployment manager, the signer for that self-signed certificate is added to the common truststore for the cell.
By default, clients do not trust servers from different profiles in the WebSphere Application Server environment. That is, they do not contain the signer for these servers. There are some things that you can do to assist in establishing this trust:
C:\WASX_e0540.11\AppServer\profiles\AppSrv01\bin\serverStatus -all ADMU0116I: Tool information is being logged in file C:\WASX_e0540.11\AppServer\profiles\AppSrv01\logs\serverStatus.log ADMU0128I: Starting tool with the AppSrv01 profile ADMU0503I: Retrieving server status for all servers ADMU0505I: Servers found in configuration: ADMU0506I: Server name: dmgr *** SSL SIGNER EXCHANGE PROMPT *** SSL signer from target host 192.168.1.5 is not found in truststore C:\WebSphere\AppServer\profiles\AppSrv01\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, O=IBM, C=US Issuer DN: CN=myhost.austin.ibm.com, O=IBM, C=US Serial number: 1128544457 Expires: Thu Oct 05 15:34:17 CDT 2006 SHA-1 Digest: 91:A1:A9:2D:F2:7D:70:0F:04:06:73:A3:B4:A4:9C:56:9D:A8:A3:BA MD5 Digest: 88:72:C5:88:00:1C:A7:FA:D6:EB:04:88:AC:A1:C9:13 Add signer to the truststore now? (y/n) y A retry of the request may need to occur. ADMU0508I: The Deployment Manager "dmgr" 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.
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 self-signed certificate configuration.
The typical remote keystore to reference is CellDefaultTrustStore.
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.C:\WASX_e0540.11\AppServer\profiles\AppSrv01\bin\retrieveSigners.bat CellDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner CWPKI0308I: Adding signer alias "CN=myhost.austin.ibm.com, O=IBM, C=US" to local keystore "ClientDefaultTrustStore" with the following SHA digest: 91:A1:A9:2D:F2:7D:70:0F:04:06:73:A3:B4:A4:9C:56:9D:A8:A3:BA CWPKI0308I: Adding signer alias "default" to local keystore "ClientDefaultTrustStore" with the following SHA digest: 40:20:CF:BE:B4:B2:9C:F0:96:4D:EE:E5:14:92:9E:37:8D:51:A5:47Use the –autoAcceptBootstrapSigner option to enable WebSphere Application Server automatically to retrieve and accept the signer for administrative connections. The SHA-1 digest is printed while the signer is added so you can verify the digest after the operation is complete.
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=file\:/// C\:/SERV1_601_0208/AppServer/profiles/AppSrv01/etc/DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.keyStoreType=JKS com.ibm.ssl.trustStore=file\:/// C\:/SERV1_601_0208/AppServer/profiles/AppSrv01/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=file\:/// C\:/SERV1_601_0208/AppServer/profiles/AppSrv01/etc/DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.keyStoreType=JKS com.ibm.ssl.trustStore=file\:/// C\:/SERV1_601_0208/AppServer/profiles/AppSrv01/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 6.1, 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.