WAS v8.5 > Secure applications > Secure communications > Secure communications using SSL > Default chained certificate configuration in SSL

Secure installation for client signer retrieval in SSL

Each profile contains a unique chained certificate signed by a long lived root certificate. The root certificate was created when the profile was created. 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 WAS environment. That is, they do not contain the root signer for these servers. Options for establishing this trust:

Best practice: Do not use the dummy keystore and truststore files in a production environment. These files contain the same certificates, and are used everywhere, which is not secure. Change the passwords for the keystore and truststore so that it does not use the WebAS default password.

For clients to perform an in-band signer exchange, specify the ssl.client.props file as a com.ibm.SSL.ConfigURL property in the SSL configuration. For managed clients, this is done automatically. Signers are designated either as in-band during the connection or out-of-band during runtime. You must also set...

We can configure certificate expiration monitoring.


Use the signer exchange prompt to retrieve signers from a client

When the client does not already have a signer to connect to a process, we can enable the signer exchange prompt. The signer exchange prompt displays once for each unique certificate and for each node. After the signer for the node is added, the signer remains in the client truststore. The following sample code shows the signer exchange prompt retrieving a signer from a client: 

cd 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, OU=cellname, OU=nodename, O=IBM, C=US
Issuer DN:     CN=myhost.austin.ibm.com, OU=Root Certificate, OU=cellname, OU=nodename, 
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=cellname,
OU=nodename, O=IBM, C=US Issuer DN:  CN=myhost.austin.ibm.com, OU=Root
Certificate, OU=cellname, OU=nodename, 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 Deployment Manager "dmgr" is STARTED

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 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 sent by the server. If you look at the certificate on the server, verify the same SHA-1 digest displays.

To disable the prompt...


Use the retrieveSigners utility to download signers for a client

We can run the retrieveSigners utility to retrieve all of the signers from the remote keystore, for use in a specified client keystore.

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.


Obtain signers for clients and servers from a previous release

When a client from a release prior to version 7.0 connects to the current release, the client must obtain signers for a successful handshake. Clients using previous releases of WAS cannot obtain signers as easily as in the current release. We can copy the deployment manager common truststore to your back-level client or server, and then re-configure the SSL configuration to directly reference that truststore. This common truststore of type PKCS12 is located in the /config/cells/cell_name/nodes/<node_name> directory in the configuration repository and has a default password of WebAS.

To collect all of the signers for the cell in a single trust.p12 keystore file, complete following steps:

  1. Copy the trust.p12 keystore file on the server and replicate it on the client. The client references the file directly from the sas.client.props and soap.client.props files that specify the SSL properties for previous releases.

  2. Change the client-side keystore password so that it matches the default cell name associated with the copied keystore.

  3. Change the default keystore type for the trust.p12 file to PKCS12 in the client configuration.

The following two code samples show you a before and an after view of the changes to make.

Default SSL configuration of sas.client.props for a previous release 

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=JKS
SSL configuration changes 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=cellname com.ibm.ssl.trustStoreType=PKCS12

We can run the PropsFilePasswordEncoder script, located in the /bin directory to encode the password.

We 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 WAS prior to v7.0, 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.


Subtopics


Related concepts:

Default chained certificate configuration in SSL


+

Search Tips   |   Advanced Search