Default self-signed certificate configuration
Default keystore and truststore properties
When a WAS process starts for the first time, the SSL runtime initializes the default keystores and truststores that are specified in the SSL configuration.
WAS creates the key.p12 default keystore file and the trust.p12 default truststore file during profile creation. A default, self-signed certificate is also created in the key.p12 file at this time. The signer or public key 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:
- DefaultKeyStore
- DefaultTrustStore
Also, in the SSL configuration, set the fileBased attribute to true so that the runtime uses the default keystores and truststores only.
On a base appserver, 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. The key and truststores are located in the following directories:
C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\Node01Cell\nodes\Node01\key.p12 C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\Node01Cell\nodes\Node01\trust.p12The default password is WebAS for all default keystores generated by WAS. Change the default password after the initial configuration for a more secure environment.
Default self-signed certificate
The default self-signed certificate is created during profile creation for both the server and client for that profile.
Use caution since the new self-signed certificates created must have the signers added to the common truststore. This should be done through the console.
If you want to set up SSL client authentication between the client and server, perform a signer exchange. The certificate properties below that exist in the ssl.client.props file do not exist in the server configuration. However, you can use these values in the server configuration by adding them as custom security properties in the console. The certificate properties appear in the ssl.client.props file, but do not appear in the server configuration. However, you can modify these values in the server configuration by adding them as custom properties in the console. Click Security > Secure administration, applications, and infrastructure > Custom properties to change the following properties:
com.ibm.ssl.defaultCertReqAlias=default_alias com.ibm.ssl.defaultCertReqSubjectDN=cn=${hostname},o=IBM,c=US com.ibm.ssl.defaultCertReqDays=365 com.ibm.ssl.defaultCertReqKeySize=1024If a default_alias value already exists, the runtime appends _#, where the number sign (#) is a number that increments 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 self-signed certificates is one year from their creation date.
The runtime monitors the expiration dates of self-signed certificates using the Certificate Expiration Monitor. These self-signed certificates are automatically replaced along with the 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. For more information, see Certificate expiration monitoring.
Default keystore and truststore configurations for new deployment manager processes
Default SSL configurations
The following sample code shows the default SSL configurations for a deployment manager:
<repertoire xmi:id="SSLConfig_1" alias="CellDefaultSSLSettings" 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 keystores and truststores
In the following sample code, the keystores and truststores for a deployment manager are referenced by the previous SSL configurations:
<keyStores xmi:id="KeyStore_1" name="CellDefaultKeyStore" password="{xor}123skfkdkid=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/key.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_2"/> <keyStores xmi:id="KeyStore_2" name="CellDefaultTrustStore" password="{xor}123skfkdkid=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/trust.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_2"/> <managementScopes xmi:id="ManagementScope_2" scopeName="(cell):Cell01" scopeType="cell"/>In the sample code, the default key and truststores are located in the cell directory of the configuration repository. Because the scopeType management scope is set to the cell level, every process in the cell can see the key and truststores. If the physical location of the keystore is lower in the node directories hierarchy, the keystore is not visible to other nodes.
The trust.p12 truststore for the deployment manager is referred to as common because it can be seen by all of the processes. In fact, when a base appserver is federated into a network deployment environment, the SSL configurations for nodes whose truststores end in DefaultTrustStore automatically change and point to the CellDefaultTrustStore common truststore. For every keystore that ends in DefaultKeyStore, the signer from the self-signed certificate is added to the common truststore. After federation, all of the default SSL configurations reference the common truststore and trusted secure communications are established for all of the server processes.
Clients that need to communicate with servers in the cell can run the retrieveSigners script that references the CellDefaultTrustStore. The script obtains all of the signers for the cell, including the self-signed certificate for the deployment manager. For more information, see Secure installation for client signer retrieval.
Default key and truststore configurations for a ND cell with one federated node
When the key.p12 file is defined in the configuration repository, the deployment manager can locally manage the keystore and synchronize to the node that owns it. The key.p12 file physically exists in the Node01 directory of the repository, which makes it available to that node and the deployment manager only.
After federation, the NodeDefaultTrustStore is not referenced by default SSL configurations. However, the truststore remains in the configuration code if you decide that a node must not trust other servers in the same cell; thus, it must not use the common CellDefaultTrustStore truststore. If you switch back to the node-specific truststore, you can add the signers from only the nodes you want to trust to obtain a higher level of isolation, even within the same cell.
Default SSL configurations The following sample code shows the CellDefaultSSLSettings SSL configuration for the deployment manager and the NodeDefaultSSLSettings SSL configuration for the federated node:
<repertoire xmi:id="SSLConfig_1" alias="CellDefaultSSLSettings" 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> <repertoire xmi:id="SSLConfig_1128545825854" alias="NodeDefaultSSLSettings" managementScope="ManagementScope_1128545825854"> <setting xmi:id="SecureSocketLayer_1128545825854" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1128545825854" trustStore="KeyStore_2" trustManager="TrustManager_1128545825854" keyManager="KeyManager_1128545825854"/> </repertoire>
Default key and truststores
The following sample code shows the default key and truststores configurations:
<keyStores xmi:id="KeyStore_1" name="CellDefaultKeyStore" password="{xor}123skfkdkid=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/key.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1"/> <keyStores xmi:id="KeyStore_2" name="CellDefaultTrustStore" password="{xor}123skfkdkid=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/trust.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1"/> <keyStores xmi:id="KeyStore_1128545825854" name="NodeDefaultKeyStore" password="{xor}349dkckdd=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/nodes/Node01/key.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1128545825854"/> <keyStores xmi:id="KeyStore_1128545825874" name="NodeDefaultTrustStore" password="{xor}349dkckdd=" provider="IBMJCE" location="${USER_INSTALL_ROOT}/config/cells/Cell01/nodes/Node01/trust.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1128545825854"/>
Default management scopes
The management scope for a federated node is node-specific. In general, configuration objects that are scoped for a particular node can reference only that scope. WAS only uses the default key and truststores in the nodes to which they are scoped. Configuration objects can maintain their uniqueness even when multiple node configurations are located in the same security.xml file. The following sample code shows how the management scope also can define the NodeDefaultKeyStore and NodeDefaultTrustStore keystores that are added from multiple nodes.
<managementScopes xmi:id="ManagementScope_1" scopeName="(cell):Cell01" scopeType="cell"/> <managementScopes xmi:id="ManagementScope_1128545825854" scopeName="(cell):Cell01:(node):Node01" scopeType="node"/>
Contents of the default truststore
After federation, the CellDefaultTrustStore () common truststore contains two signers: the deployment manager signer and the federated node signer. In the following sample code, the deployment manager and node host are the same:
keytool -list \ -keystore c:\WebSphere\AppServer\profile\AppSrv01\config\cells\Cell01\trust.p12 \ -storepass Cell01 \ -storetype PKCS12 \ -v Alias name: default_signer Entry type: trustedCertEntry Owner: CN=myhost.austin.ibm.com, O=IBM, C=US Issuer: CN=myhost.austin.ibm.com, O=IBM, C=US Valid from: 10/5/05 3:34 PM until: 10/5/06 3:34 PM Certificate fingerprints: SHA1: 91:A1:A9:2D:F2:7D:70:0F:04:06:73:A3:B4:A4:9C:56:9D:A8:A3:BA ******************************************* ******************************************* Alias name: default Entry type: trustedCertEntry Owner: CN=myhost.austin.ibm.com, O=IBM, C=US Issuer: CN=myhost.austin.ibm.com, O=IBM, C=US Valid from: 10/18/05 4:06 PM until: 10/18/06 4:06 PM Certificate fingerprint: SHA1: 33:6E:9E:10:65:04:CE:7A:6C:C3:B1:79:8B:9A:05:49:AC:E5:67:F3In cases where nodes are federated from remote hosts, the CN contains the host name of the remote hosts. This node configuration enables a custom trust manager to perform host name verification using the remote certificates that it receives during the connection. The custom trust manager must implement com.ibm.wsspi.ssl.TrustManagerExtendedInfo to gain access to the remote host name from the runtime.
Sub-topics
Secure installation for client signer retrieval
Certificate expiration monitoring
Web server plug-in default configuration
Related concepts
Secure communications using SSL
Related Reference
Example: Develop a custom trust manager for custom SSL trust decisions