Secure communications using SSL

WAS v8.5 > Secure applications > Secure communications
Secure communications using SSL

The SSL protocol provides authenticity, signing, and encryption for the transport layer, ensuring secure connections between clients and servers.
Data is encrypted public keys and decrypted using private keys.
WAS distributes X.509 public certificates containing distinguished names and expiration times, signed by either...

A certificate authority
A root certificate in NodeDefaultRootStore or DmgrDefaultRootStore (chained certificates)
Self-signed

Keystores hold personal certificates which contain both public and private keys. Truststores holds signer certificates, which contain just the public key.
Exchange signers to establish trust in a personal certificate for a specific entity, such as an LDAP.
Use SSL configurations to manage SSLContext objects...

SSLContext alias
handshake protocol version
keystore reference
truststore reference
key manager
trust managers
cipher suite
certificate alias

SSL selection types

Type Description
Programmatic Set an SSL configuration on the running thread prior to an outbound connection. WAS ensures that most system protocols, including IIOP, JMS, HTTP, and LDAP, accept the configuration.
Dynamic Associate an SSL configuration dynamically with a specific target host, port, or outbound protocol using a predefined selection criteria. When it establishes the connection, WAS checks to see if the target host and port match a predefined criteria that includes the domain portion of the host. Additionally, we can predefine the protocol for a specific outbound SSL configuration and certificate alias selection. Dynamic outbound selection of Secure Sockets Layer configurations is based on connection information being available for the server so the server can match up the outbound protocol, host, or port when the creation of the client socket takes place in...
com.ibm.websphere.ssl.protocol.SSLSocketFactory

For WebSphere admin connectors like SOAP and Remote Method Invocation (RMI), connection information is placed on the thread and is available for dynamic outbound selection to take place. The dynamic outbound selection process replies on connection information setup when SSL properties are retrieved.
When the outbound connection is being made from customer written applications, parts of the connection information may not be available. Some of these applications make API calls to a protocol to make the connection. To complete the process the API ultimately then calls one of the createSocket() methods in...
com.ibm.websphere.ssl.protocol.SSLSocketFactory

All of the connection information for dynamic outbound selection might not be available, and you may have to adjust the dynamic outbound selection connection filter and fill in an asterisk (*) for the missing part of the connection information. As an example, the openConnection() call on a URL object ultimately calls createSocket(java.net.Socket socket, String host, int port, boolean autoClose). The connection information can be built with the host and port provided, but there is no protocol provided. In this case, a wild card, asterisk (*), should be used for the protocol part of the dynamic selection connection information.
Most of the createSocket() methods take a host or IP address and a port as parameters. The dynamic outbound selection connection filter can be built with the host and port. The default method, createSocket(), without any parameters does not contain any information to build the outbound selection connection filter unless the socket factory was instantiated with connection information, If no connection information is available, then you should consider using one of the other methods of selecting a SSL configuration describes in this topic, "Programmatic selection" can be good choice.
Direct Select an SSL configuration using a specific alias, as in past releases. This method of selection is maintained for backwards compatibility because many applications and processes rely on alias references.
Scope Associate an SSL configuration and its certificate alias, located in the keystore associated with that SSL configuration, with a WAS management scope. This approach is recommended to manage SSL configurations centrally. We can manage endpoints more efficiently because they are located in one topology view of the cell. The inheritance relationship between scopes reduces the number of SSL configuration assignments that set.
Each time associate an SSL configuration with a cell scope, the node scope within the cell automatically inherits the configuration properties. However, when we assign an SSL configuration to a node, the node configuration overrides the configuration the node inherits from the cell. Similarly, all of the application servers for a node automatically inherit the SSL configuration for that node unless you override these assignments. Unless you override a specific configuration, the topology relies on the rules of inheritance from the cell level down to the endpoint level for each application server.
If the applications are relying on SSL configurations that were set as individual settings for each SSL configuration in the topology, but the application servers have inherited the SSL configuration as deployed from the cell level down to the endpoint level, then there is the possibility of communication errors occurring among servers (for example, handshake errors). You need to ensure the applications are operating consistent with the central management of SSL configurations.
The topology view displays an inbound tree and outbound tree. We can make different SSL configuration selections for each side of the SSL connection based on what that server connects to as an outbound connection and what the server connects to as an inbound connection.

Precedence order...

Programmatic selection.
If an application sets an SSL configuration on the running thread using the com.ibm.websphere.ssl.JSSEHelper API, the SSL configuration is guaranteed the highest precedence.
Dynamic selection criteria for outbound host and port or protocol.
Direct selection.
Scope selection.
Guarantees the endpoint that you select is associated with an SSL configuration and is inherited by every scope beneath it that does not override this selection.

Default chained certificate configuration

By default, WAS creates a unique chained certificate for each node. The chained certificate is signed with a root, a self-signed certificate stored in the DmgrDefaultRootStore or NodeDefaultRootStore. WAS no longer relies on a self-signed certificate or the default or dummy certificate shipped with the product. The key.p12 default keystore and the trust.p12 truststore are stored in the configuration repository within the node directory. The default root certificate is stored in the root-key.p12 in the configuration repository under the node directory.
When you federate a base application server, the following situations occur:

The keystore and truststore are included
The signer certificate is added to the deployment manager common truststore, located in the cell directory of the configuration repository.

All of the nodes put their signer certificates from the default root certificate 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, 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, a truststore with the name suffix DefaultTrustStore and a rootstore with the name suffix DefaultRootStore. These default suffixes instruct the WAS runtime to add the root signer of the personal certificate to the common truststore. If a truststore name does not end with DefaultKeyStore, the keystores root signer certificates are not added to the common truststore when we federate the server. We can change the default SSL configuration, but ensure the correct trust is established for administrative connections, among others. See also: Web server plug-in default configuration in SSL.

Certificate expiration monitoring

Certificate monitoring ensures the default chained certificate for each node is not allowed to expire. The certificate expiration monitoring function issues a warning before certificates and signers are set to expire. Those certificates and signers located in keystores managed by the WAS configuration can be monitored. We can configure the expiration monitor to automatically replace a certificate. A chained certificate will be recreated based on the same data used for the initial creation and sign it with the same root certificate that signed the original certificate. A self-signed certificate or chained certificate is also recreated based upon the same data used for the initial creation.
The monitor also can automatically replace old signers with the signers from the new chained or self-signed certificates in keystores that are managed by WAS. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved.
The expiration monitor is configured to replace chained personal certificates that are signed by a root certificate in DmgrDefaultRootStore or NodeDefaultRootStore. The certificate is renewed using the same root certificate that was used to sign the original certificate. The monitor also can automatically replace old signers with the signers from the new self-signed certificates in keystores that are managed by WAS. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved.

WAS clients: signer-exchange requirements

A new chained certificate is generated for each node during its initial startup. Clients are given the root signers.
We can gain access to the signer certificates of various nodes to which the client must connect with any one of the following options

A signer exchange prompt enables you to import signer certificates that are not yet present in the truststores during a connection to a server.
By default, this prompt is enabled for administrative connections and can be enabled for any client SSL configuration. When this prompt is enabled, any connection that is made to a server where the signer is not already present offers the signer of the server along with the certificate information and a Secure Hash Algorithm (SHA) digest of the certificate for verification. The user is given a choice whether to accept these credentials. If the credentials are accepted, the signer is added to the truststore of the client until the signer is explicitly removed. The signer exchange prompt does not occur again when connecting to the same server unless the personal certificate changes. It is unsafe to trust a signer exchange prompt without verifying the SHA digest. An unverified prompt can originate from a browser when a certificate is not trusted.
We can run a retrieveSigners administrative script from a client prior to making connections to servers.
To download signers, no administrative authority is required. To upload signers, you must have Administrator role authority. The script downloads all of the signers from a specified server truststore into the specified client truststore and can be called to download only a specific alias from a truststore. We can also call the script to upload signers to server truststores. When you select the CellDefaultTrustStore truststore as the specified server truststore and common truststore for a cell, all of the signers for that cell are downloaded to the specified client truststore, which is typically ClientDefaultTrustStore.
We can physically distribute to clients the trust.p12 common truststore located in the cell directory of the configuration repository.
When doing this distribution, however, ensure the correct password has been specified in the ssl.client.props client SSL configuration file. The default password for this truststore is WebAS. Change the default password prior to distribution. Physical distribution is not as effective as the previous options. When changes are made to the personal certificates on the server, automated exchange can fail.

Dynamic SSL configuration changes

The SSL runtime for WAS maintains listeners for most SSL connections. A change to the SSL configuration causes the inbound connection listeners to create a new SSLContext object. Existing connections continue to use the current SSLContext object. Outbound connections automatically use the new configuration properties when they are attempted. Make dynamic changes to the SSL configuration during off-peak hours to reduce the possibility of timing-related problems and to prevent the possibility of the server starting again. If you enable the runtime to accept dynamic changes, then change the SSL configuration and save the security.xml file. Your changes take effect when the new security.xml file reaches each node.
If configuration changes cause SSL handshake failures, administrative connectivity failures also can occur, which can lead to outages. In this case, you must re-configure the SSL connections then perform manual node synchronization to correct the problem. You must carefully complete any dynamic changes. It is highly recommended that you perform changes to SSL configurations on a test environment prior to making the same changes to a production system.

Built-in certificate management

Certificate management that is comparable to iKeyMan functionality is now integrated into the keystore management panels of the dmgr console. Use built-in certificate management to manage personal certificates, certificate requests, and signer certificates located in keystores. Additionally, we can remotely manage keystores. For example, we can manage a file-based keystore located outside the configuration repository on any node from the deployment manager. You also can remotely manage hardware cryptographic keystores from the deployment manager.
With built-in certificate management, we can replace a chained or self-signed certificate along with all of the signer certificates scattered across many truststores and retrieve a signer from a remote port by connecting to the remote SSL host and port and intercepting the signer during the handshake. The certificate is first validated according to the certificate SHA digest, then the administrator must accept the validated certificate before it can be placed into a truststore.
When you make a certificate request, we can send it to a certificate authority (CA). When the certificate is returned, we can accept it within the dmgr console.
Although iKeyMan functionality still ships with WAS, configure keystores from the dmgr console using the built-in certificate management functionality. iKeyMan is still an option when it is not convenient to use the dmgr console.

AdminTask configuration management
The SSL configuration management panels in the dmgr console rely primarily on administrative tasks, which are maintained and enhanced to support the dmgr console function. We can use wsadmin commands from a Java console prompt to automate the management of keystores, SSL configurations, certificates, and so on.

Subtopics

SSL configurations
Keystore configurations
Dynamic outbound selection of Secure Sockets Layer configurations
Central management of SSL configurations
Secure Sockets Layer node, application server, and cluster isolation
Certificate options during profile creation
Default chained certificate configuration in SSL
Dynamic configuration updates in SSL
Management scope configurations
Certificate management using iKeyman prior to SSL
Certificate management in SSL
Use the retrieveSigners command in SSL to enable server to server trust
SSL configurations

Related concepts:

Trust manager control of X.509 certificate trust decisions
Key manager control of X.509 certificate identities

Related

Programmatically specifying an outbound SSL configuration using JSSEHelper API

+
Search Tips | Advanced Search

Type	Description
Programmatic	Set an SSL configuration on the running thread prior to an outbound connection. WAS ensures that most system protocols, including IIOP, JMS, HTTP, and LDAP, accept the configuration.
Dynamic	Associate an SSL configuration dynamically with a specific target host, port, or outbound protocol using a predefined selection criteria. When it establishes the connection, WAS checks to see if the target host and port match a predefined criteria that includes the domain portion of the host. Additionally, we can predefine the protocol for a specific outbound SSL configuration and certificate alias selection. Dynamic outbound selection of Secure Sockets Layer configurations is based on connection information being available for the server so the server can match up the outbound protocol, host, or port when the creation of the client socket takes place in... com.ibm.websphere.ssl.protocol.SSLSocketFactory For WebSphere admin connectors like SOAP and Remote Method Invocation (RMI), connection information is placed on the thread and is available for dynamic outbound selection to take place. The dynamic outbound selection process replies on connection information setup when SSL properties are retrieved. When the outbound connection is being made from customer written applications, parts of the connection information may not be available. Some of these applications make API calls to a protocol to make the connection. To complete the process the API ultimately then calls one of the createSocket() methods in... com.ibm.websphere.ssl.protocol.SSLSocketFactory All of the connection information for dynamic outbound selection might not be available, and you may have to adjust the dynamic outbound selection connection filter and fill in an asterisk () for the missing part of the connection information. As an example, the openConnection() call on a URL object ultimately calls createSocket(java.net.Socket socket, String host, int port, boolean autoClose). The connection information can be built with the host and port provided, but there is no protocol provided. In this case, a wild card, asterisk (), should be used for the protocol part of the dynamic selection connection information. Most of the createSocket() methods take a host or IP address and a port as parameters. The dynamic outbound selection connection filter can be built with the host and port. The default method, createSocket(), without any parameters does not contain any information to build the outbound selection connection filter unless the socket factory was instantiated with connection information, If no connection information is available, then you should consider using one of the other methods of selecting a SSL configuration describes in this topic, "Programmatic selection" can be good choice.
Direct	Select an SSL configuration using a specific alias, as in past releases. This method of selection is maintained for backwards compatibility because many applications and processes rely on alias references.
Scope	Associate an SSL configuration and its certificate alias, located in the keystore associated with that SSL configuration, with a WAS management scope. This approach is recommended to manage SSL configurations centrally. We can manage endpoints more efficiently because they are located in one topology view of the cell. The inheritance relationship between scopes reduces the number of SSL configuration assignments that set. Each time associate an SSL configuration with a cell scope, the node scope within the cell automatically inherits the configuration properties. However, when we assign an SSL configuration to a node, the node configuration overrides the configuration the node inherits from the cell. Similarly, all of the application servers for a node automatically inherit the SSL configuration for that node unless you override these assignments. Unless you override a specific configuration, the topology relies on the rules of inheritance from the cell level down to the endpoint level for each application server. If the applications are relying on SSL configurations that were set as individual settings for each SSL configuration in the topology, but the application servers have inherited the SSL configuration as deployed from the cell level down to the endpoint level, then there is the possibility of communication errors occurring among servers (for example, handshake errors). You need to ensure the applications are operating consistent with the central management of SSL configurations. The topology view displays an inbound tree and outbound tree. We can make different SSL configuration selections for each side of the SSL connection based on what that server connects to as an outbound connection and what the server connects to as an inbound connection.