WebSphere Application Server uses Java Secure Sockets Extension (JSSE) as the SSL implementation for secure connections.
JSSE handles the handshake negotiation and protection capabilities that are provided by SSL to ensure secure connectivity exists across most protocols
CA and self-signed X.509 certificates reside in Java keystores. Typically, each JSSE configuration has two Java keystore references: a keystore and a truststore.
The keystore reference represents a Java keystore object that holds personal certificates.
The truststore reference represents a Java keystore object that holds signer certificates.
A personal certificate without a private key is an X.509 certificate that represents the entity that owns it during a handshake.
Personal certificates contain both public and private keys.
A signer certificate is an X.509 certificate that represents a peer entity or itself.
Signer certificates contain just the public key and verify the signature of the identity that is received during a peer-to-peer handshake.
Default self-signed certificate configuration
By default, WebSphere Application Server creates a unique self-signed certificate for each node.
WebSphere Application Server no longer relies on the default or dummy certificate that is shipped with the product. The key.p12 default keystore and the trust.p12 truststore are stored in the configuration repository within the node directory.
All of the nodes put their signer certificates in this common truststore (trust.p12).
Additionally, after you federate a node, the default SSL configuration is automatically modified to point to the common truststore, which is located in the cell directory. The node can now communicate with all other servers in the cell.All default SSL configurations contain a keystore with the name suffix DefaultKeyStore and a truststore with the name suffix DefaultTrustStore.
These default suffixes instruct the WebSphere Application Server runtime to add the signer of the personal certificate to the common truststore. If a keystore name does not end with DefaultKeyStore, the keystore signer certificates are not added to the common truststore when you federate the server.
You can change the default SSL configuration, but you must ensure that the correct trust is established for administrative connections, among others.
For more information, see Default self-signed certificate configuration and Web server plug-in default configuration
WebServer Plug-In default Configuration
When you create a new Web server definition, WebSphere Application Server associates the Web server plug-in with a Certificate Management Services (CMS) keystore for a specific node. The keystore contains all of the signers for the current cell with the self-signed certificate, which belongs to the node. The plug-in can communicate securely to WebSphere Application Server, even when the plug-in is configured with Secure Sockets Layer (SSL) client authentication enabled.
When you set the Web server definition to webserver1 on node myhostNode01, WebSphere Application Server creates the keystore configuration. The keystore is scoped to the webserver1 server, which makes it visible to this server only. Other processes cannot use this keystore definition
The default password for the keystore is WebAS. You can change the default keystore password by using either the administrative console or the appropriate AdminTask command.
The following sample code shows the AdminTask command that you can use to create this CMS keystore.
$AdminTask createCMSKeyStore /config/cells/myhostCell01/nodes/myhostNode01
/servers/webserver1/plugin-key.kdb myhost.austin.ibm.com
Note the following characteristics of the previous example:
- You can create only one CMSKeyStore entry for each management scope. If a CMS keystore already exists for scope (cell):myhostCell01:(node):myhostNode01:(server):webserver1, then you cannot create another CMSKeyStore entry
- The Uniform Resource Identifier (URI) for the keystore name is /config/cells/myhostCell01/nodes/myhostNode01/servers/webserver1/plugin-key.kdb
- The host name in the plug-in location is myhost.austin.ibm.com. WebSphere Application Server uses this name to create a self-signed certificate, if a self-signed certificate does not already exist for that particular node. If a self-signed certificate already exists for the node, then the certificate is put into the CMS keystore and all the signers from the cell are added, by default.
When additional nodes are federated, the signers for these nodes are not automatically added to each Web server for the CMS keystore. For the Web server plug-in to be able to communicate with a newly federated node, you must manually exchange signers with the CMSKeyStore keystore. Use the administrative console keystore certificate management function to exchange signers. For more information, see Extracting a signer certificate from a personal certificate.
Extracting a signer certificate from a personal certificate:
Procedure :
- Click Security > SSL certificate and key management > Manage endpoint security configurations > {Inbound | Outbound} > ssl_configuration > Key stores and certificates > keystore .
- Under Additional Properties, click Personal certificates.
- Select a personal certificate.
- Click Extract.
- Type the full path for the certificate file name. The signer certificate is written to this certificate file.
- Select a data type from the list.
- Click Apply.
Results : The signer portion of the personal certificate is stored in the file that is provided.
What to do next : This signer can now be imported into other keystores.
Adding a signer certificate to a keystore
Signer certificates establish the trust relationship in SSL communication. You can extract the signer part of a personal certificate from a keystore, and then you can add the signer certificate to other keystores.
Before you begin
The keystore that you want to add the signer certificate to must already exist.
addSignerCertificate
The addSignerCertificate command add a signer certificate from a certificate file to a keystore.
Required parameters
- -keyStoreName
- Specifies the name that uniquely identifies the keystore configuration object. (String, required)
- -certificateAlias
- Specifies the name that uniquely identifies the certificate request in a keystore. (String, required)
- -certificateFilePath
- Specifies the full path of the request file that contains the certificate. (String, required)
- -base64Encoded
- Specifies that the certificate is a Base64 encoded ASCII data file type if the value is set to true. Set the value of this parameter to false if the certificate is a binary DER data file type. (Boolean, required)
Optional parameters
- -keyStoreScope
- Specifies the scope name of the keystore. (String, optional)
$AdminTask addSignerCertificate {-keyStoreName testKeyStore -certificateAlias default -certificateFilePath <file path> -base64Encoded true}
About this task
Complete the following steps in the administrative console:
Procedure
- Click Security > SSL certificate and key management > Manage endpoint security configurations > Inbound | Outbound > SSL_configuration_name > Key stores and certificates.
- Select a keystore from the list of keystores.
- Click Add signers.
- Enter an alias for the signer certificate in the Alias field
- Enter the full path to the signer certificate file in the File name field.
- Select a data type from the list in the Data type field.
- Click Apply.
Results
When these steps are completed, the signer from the certificate file is stored in the keystore. You can see the signer in the keystore files list of signer certificates. Use the keystore to establish trust relationships for the SSL configurations.
Exchanging signer certificates
To establish trust relationships, you can exchange signer certificates between keystores. When you exchange signer certificates, you are extracting a personal certificate from one keystore and adding it to another keystore as a signer certificate.
Before you begin
To exchange signer certificates, there must be two keystores.
About this task
Complete the following steps in the administrative console:
Procedure
- Click Security > SSL certificate and key management > Manage endpoint security configurations > {Inbound | Outbound} > ssl_configuration > Key stores and certificates.
- Select two keystores from the list of keystores.
- Click Exchange signers.
- Select any of the certificates in the first personal certificates list, and click Add. After adding, the signer part of the selected personal certificate appears in the other (second) keystore signers list.
- Select any of the certificates in the second personal certificates list, and click Add. After adding, the signer part of the selected personal certificate appears in the other (first) keystore signers list.
- Optional: If you need to remove any of the certificates from either of the signers lists, highlight one or more of the certificates, and click Remove.
- Click Apply and Save.
Results
The signer certificate appears in the list for each keystore.
What to do next
The extracted signer certificate is available to both keystores during the connection handshake.
AdminTask object includes the following commands:
