Default chained certificate configuration in SSL


 

+

Search Tips   |   Advanced Search

 

Overview

When a WAS process starts for the first time, the SSL runtime initializes the default keystores and truststores specified in the SSL configuration.


Default keystore and truststore properties

WAS creates the key.p12 default keystore file and the trust.p12 default truststore file during profile creation. A default, chained certificate is also created in the key.p12 file at this time. The root signer, or public key, of the chained certificate is extracted from the key.p12 file and added to the trust.p12 file. If the files do not exist during process startup, they are recreated during startup.

You can identify keystore and truststore defaults because of their suffixes:

Also, in the SSL configuration, set the fileBased attribute to true so that the runtime only uses the default keystores and truststore.

On a base application server, default key and truststores are stored in the node directory of the configuration repository. For example, the default key.p12 and trust.p12 stores are created with the AppSrv01 profile name, the Node01Cell name, and the Node01 node name.

key.p12 and trust.p12 are located in...

$PROFILE_HOME/config/cells/cell/nodes/node/key.p12

The default password is WebAS for all default keystores generated by WAS.


Default chained certificate

The default self-signed certificate is created during profile creation for both the server and client for a profile.

To recreate the certificates with different information...

  1. Delete the *.p12 files in /config and /etc
  2. Change the four properties below to the values you want the certificates to contain
  3. Restart the processes

This causes the server certificate in /config and the client certificate in /etc to differ.

The certificate properties below that exist in the ssl.client.props file do not exist in the server configuration. However, we can use these values in the server configuration by adding them as custom security properties in the admin console. The certificate properties appear in the ssl.client.props file, but do not appear in the server configuration.

We can modify these values in the server configuration by adding them as custom properties in the admin console. Go to...

Security | Global security | Custom properties

...to change the following properties:

com.ibm.ssl.defaultCertReqAlias=default_alias
com.ibm.ssl.defaultCertReqSubjectDN=cn=${hostname},ou=Node01,ou=Node01Cell,o=IBM,c=US
com.ibm.ssl.defaultCertReqDays=365
com.ibm.ssl.defaultCertReqKeySize=1024
com.ibm.ssl.rootCertSubjectDN=cn=${hostname},ou=Root Certificate, ou=Node01, ou=Node01Cell,o=IBM,c=US
com.ibm.ssl.rootCertValidDays=7300
com.ibm.ssl.rootCertAlias=root
com.ibm.ssl.rootCertKeySize=1024

You must then delete the default chained certificate and restart the dmgr (DMGR), node and all of the servers. If the default certificate does not exist, WAS automatically generates a new default certificate using the properties listed above.

If a default_alias value already exists, the runtime appends _#, where the number sign (#) is a number that increases until it is unique in the keystore. ${hostname} is a variable that is resolved to the host name where it was originally created. The default expiration date of chained certificates is one year from their creation date.

The runtime monitors the expiration dates of chained certificates using the certificate expiration monitor. These chained certificates are automatically replaced along with any signer certificates when they are within the expiration threshold, which is typically 30 days before expiration. You can increase the default key size beyond 1024 bits only when the Java runtime environment policy files are unrestricted (that is, not exported).


Default keystore and truststore configurations for new Base Application Server processes

The following sample code shows the default SSL configuration for a base application server. 

<repertoire xmi:id="SSLConfig_1" 
            alias="NodeDefaultSSLSettings" 
            managementScope="ManagementScope_1">

<setting xmi:id="SecureSocketLayer_1" 
         clientAuthentication="false" 
         securityLevel="HIGH" 
         enabledCiphers="" 
         jsseProvider="IBMJSSE2" 
         sslProtocol="SSL_TLS" 
         keyStore="KeyStore_1" 
         trustStore="KeyStore_2" 
         trustManager="TrustManager_1" 
         keyManager="KeyManager_1"/>
</repertoire>


Default keystore

In the following sample code, the keystore object that represents the default keystore is similar to the XML object. 

<keyStores xmi:id="KeyStore_1" 
           name="NodeDefaultKeyStore" 
           password="{xor}349dkckdd=" 
           provider="IBMJCE" 
           location="${WAS_INSTALL_ROOT}/config/cells/Node01Cell/nodes/Node01/key.p12" 
           type="PKCS12" 
           fileBased="true"  
           hostList="" 
           initializeAtStartup="true" 
           managementScope="ManagementScope_1"/>

The NodeDefaultKeyStore keystore contains the personal certificate that represents the identity of the secure endpoint. Any keystore reference can use the ${WAS_INSTALL_ROOT} variable, which is expanded by the runtime. The PKCS12 default keystore type is in the most interoperable format, which means that it can be imported into most browsers. The Node01Cell password is encoded. The management scope determines which server runtime loads the keystore configuration into memory, as shown in the following code sample: 

<managementScopes 
      xmi:id="ManagementScope_1" scopeName=" (cell):Node01Cell:(node):Node01" 
      scopeType="node"/>

Any configuration objects that are stored in security.xml whose management scopes are outside the current process scope are not loaded in the current process. Instead, the management scope is loaded by servers that are contained within the Node01 node. Any application server that is on the specific node can view the keystore configuration.

When you list the contents of the key.p12 file to show the chained certificate, note that the common name (CN) of the distinguished name (DN) is the host name of the resident machine. This listing enables you to verify the host name by its URL connections. Additionally, we can verify the host name from a custom trust manager.


Contents of default keystore

The following sample code shows the contents of the default key.p12 file in a keytool list:

$ keytool -list -v -keystore $PROFILE_HOME/config/cells/Node01Cell/nodes/Node01/key.p12 -storetype PKCS12 -storepass mypass

Keystore type: PKCS12
Keystore provider: IBMJCE

Your keystore contains 1 entry
Alias name: default
Creation date: Dec 31, 1969
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=myhost.mpls.setgetweb.com, OU=Node01Cell, OU=Node01, O=IBM, C=US
Issuer: CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US
Serial number: 4e48f29aafea6
Valid from: 2/7/08 1:03 PM until: 2/6/09 1:03 PM
Certificate fingerprints:
    MD5: DB:FE:65:DB:40:13:F4:48:A4:CE:2F:4F:60:A5:FF:2C
    SHA1: A1:D4:DD:4B:DE:7B:45:F7:4D:AA:6A:FC:92:38:78:53:7A:99:F1:DC
Certificate[2]:
Owner: CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US
Issuer: CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US
Serial number: 4e48e5fd4eae3
Valid from: 2/7/08 1:03 PM until: 2/2/28 1:03 PM
Certificate fingerprints:
    MD5: A5:9B:05:78:CF:AB:89:94:C9:2E:F1:87:34:B3:FC:75
    SHA1: 43:74:B6:C7:FA:C1:0F:19:F2:51:2B:17:60:0D:34:93:55:BF:D5:D2

*******************************************

The alias name "default" and the entry type "keyEntry" indicate that the private key is stored with the public key, which represents a complete personal certificate. The certificate is owned by

CN=myhost.mpls.setgetweb.com, OU=Node01Cell, OU=Node01, O=IBM, C=US
and it is issued by the default root certificate, which is owned by

CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US

By default, the certificate is valid for one year from the date of creation.

Additionally, in some signer-exchange situations, the certificate fingerprint ensures that the sent certificate has not been modified. The fingerprint, which is a hash algorithm output for the certificate, is displayed by the WAS runtime during an automated signer exchange on the client side. The client fingerprint must match the fingerprint that is displayed on the server. The runtime typically uses the SHA1 hash algorithm to generate certificate fingerprints.


Default truststore

In the following sample code, the keystore object represents the default trust.p12 truststore. The truststore contains signer certificates that are necessary for making trust decisions: 

<keyStores xmi:id="KeyStore_2" 
           name="NodeDefaultTrustStore"  
           password="{xor}349dkckdd=" 
           provider="IBMJCE" 
           location="${WAS_INSTALL_ROOT}/config/cells/Node01Cell/nodes/Node01/trust.p12" 
           type="PKCS12"  
           fileBased="true" 
           hostList="" 
           initializeAtStartup="true" 
           managementScope="ManagementScope_1"/>


Contents of default truststore

The following sample code shows the contents of the default trust.p12 truststore in a keytool listing. By default, for the sample chained certificate, the root certificate signer is included in the trust store. The root signer alias name and the trustedCertEntry entry type indicate that the certificate is the public key. The private key is not stored in this truststore. In addition, all truststores contain the default datapower certificate.

$ keytool.sh -list -v -keystore $PROFILE_HOME/config/cells/Node01Cell/nodes/Node01/trust.p12 -storetype PKCS12 -storepass *****

Keystore type: PKCS12
Keystore provider: IBMJCE
Your keystore contains 2 entries
Alias name: root
Creation date: Dec 31, 1969
Entry type: trustedCertEntry
Owner: CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US
Issuer: CN=myhost.mpls.setgetweb.com, OU=Root Certificate, OU=Node01Cell, OU=Node01, O=IBM, C=US
Serial number: 4e48e5fd4eae3
Valid from: 2/7/08 1:03 PM until: 2/2/28 1:03 PM
Certificate fingerprints:
MD5: A5:9B:05:78:CF:AB:89:94:C9:2E:F1:87:34:B3:FC:75
SHA1: 43:74:B6:C7:FA:C1:0F:19:F2:51:2B:17:60:0D:34:93:55:BF:D5:D2

*******************************************
*******************************************
Alias name: datapower
Creation date: Dec 31, 1969
Entry type: trustedCertEntry
Owner: OU=Root CA, O="DataPower Technology, Inc.", C=US
Issuer: OU=Root CA, O="DataPower Technology, Inc.", C=US
Serial number: 0
Valid from: 6/11/03 1:23 PM until: 6/6/23 1:23 PM
Certificate fingerprints:
MD5: 18:AC:86:D1:9A:90:A2:AE:8B:28:F9:A8:75:C8:A9:DB
SHA1: A9:BA:A4:B5:BC:26:2F:5D:2A:80:93:CA:BA:F4:31:05:F2:54:14:17



Subtopics


Secure installation for client signer retrieval
Certificate expiration monitoring

 

Related concepts

Secure communications using SSL