Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure communications
Create an SSL configuration
Overview
SSL configuration attributes control the behavior of client and server SSL endpoints, including...
- quality of protection
- trust and key manager settings
SSL configurations with unique names and specific management scopes are created on the inbound and outbound tree in the configuration topology.
Decide at which scope define an SSL configuration, for instance, the cell, node group, node, server, cluster, or endpoint scope, from the least specific to the most specific scope. When you define an SSL configuration at the node scope, for example, only those processes within that node can load the SSL configuration; however, any processes at the endpoint in the cell can use an SSL configuration at the cell scope, which is higher in the topology.
Decide which scope to associate with the new SSL configuration. For example, an SSL configuration for a hardware cryptographic device might require a keystore that is available only on a specific node, or you might need an SSL configuration for a connection to a particular SSL host and port.
The security.xml file is restricted.
When making changes security.xml, use an ID that administrator role authorization. If you are using a user ID with operator role authorization, you can perform a node synchronization, but changes made to the security.xml file are not synchronized.
Create an SSL configuration
- Create a new SSL configuration alias...
Security | SSL certificate and key management | Manage endpoint security configurations | [Inbound | Outbound] | Related Items | SSL configuration | New
If the scope is already associated with a configuration and alias, the SSL configuration alias and certificate alias are noted in parentheses. If not explicitly associated, the scope inherits the configuration properties of the first scope above it.
The cell scope, at the top of the topology, must be associated with an SSL configuration.
- Type an SSL configuration name to serve as the alias.
- Select a truststore name from the drop-down list.
A truststore holds signer certificates that validate certificates sent by remote connections during an SSL handshake.
- Select a keystore name from the drop-down list.
A keystore contains...
- Personal certificates that represent a signer identity
- The private key used to encrypt and sign data
If you change the keystore name, to refresh the list of certificates from which you can choose a default alias, click...
Get certificate aliases
WAS uses a server alias for inbound connections and a client alias for outbound connections.
- Choose a default server certificate alias for inbound connections.
Select the default only when we have not specified an SSL configuration alias elsewhere and have not selected a certificate alias. A centrally managed SSL configuration tree can override the default alias.
- Choose a default client certificate alias for outbound connections. Select the default only when the server SSL configuration specifies an SSL client authentication.
- Review the identified management scope for the SSL configuration.
Make the management scope in this field identical to the link you selected in Step 2. To change the scope, click a different link in the topology tree and continue at Step 3.
- Click Apply if you intend to configure Additional Properties.
- Click Quality of protection (QoP) settings under Additional Properties. QoP settings define the strength of the SSL encryption, the integrity of the signer, and the authenticity of the certificate.
- Select a client authentication setting to establish an SSL configuration for inbound connections and for clients to send their certificates, if appropriate.
None The server does not request that a client send a certificate during the handshake. Supported The server requests that a client send a certificate. If the client does not have a certificate, the handshake might still succeed. Required The server requests that a client send a certificate. If the client does not have a certificate, the handshake fails. The signer certificate that represents the client must be in the truststore that you select for the SSL configuration. By default, servers within the same cell trust each other because they use the common truststore, trust.p12, that is located in the cell directory of the configuration repository. However, if you use keystores and truststores that you create, perform a signer exchange before you select either Supported or Required.
- Select a protocol for the SSL handshake.
Protocol Supports Notes SSL_TLS TLSv1, SSLv3, and SSLv2 Default TLSv1 TLS and TLSv1 For handshake, SSL server connection must support this protocol. SSLv3 SSL and SSLv3 For handshake, SSL server connection must support this protocol. Do not use the SSLv2 protocol for the SSL server connection. Use it only when necessary on the client side.
- Select one of the following options:
Predefined JSSE provider Recommended. Required for use by the channel framework SSL channel. When FIPS is enabled, IBMJSSE2 is used in combination with the IBMJCEFIPS crypto provider.
Custom JSSE provider Type a provider name in the Custom provider field.
- Select from among the following cipher suite groups:
Strong WAS can perform 128-bit confidentiality algorithms for encryption and support integrity signing algorithms. A strong cipher suite can affect the performance of the connection. Medium WAS can perform 40-bit encryption algorithms for encryption and support integrity signing algorithms. Weak WAS supports integrity signing algorithms, but does not perform encryption. Passwords and other sensitive information that cross the network are visible to an IP sniffer. Custom Select specific ciphers.
- To view a list of the available ciphers for each cipher strength, select...
Update selected ciphers
- Click OK to return to the new SSL configuration panel.
- Click Trust and key managers under Additional Properties.
- Select a default trust manager for the primary SSL handshake trust decision.
IbmPKIX For certificate revocation list checking using CRL distribution points in the certificates or the online certificate status protocol (OCSP). IbmX509 For when you do not require certificate revocation list checking, but do need increased performance. Configure a custom trust manager to perform CRL checking, if necessary.
- Define a custom trust manager, if appropriate.
We can define a custom trust manager that runs with the default trust manager you select. The custom trust manager must implement the JSSE interface...
javax.net.ssl.X509TrustManager
...and, optionally, the interface...
com.ibm.wsspi.ssl.TrustManagerExtendedInfo
...to obtain product-specific information.
- Click...
Security | SSL certificate and key management | Manage endpoint security configurations | SSL_configuration | Trust and key managers | Trust managers | New
- Type a unique trust manager name.
- Select the Custom option.
- Type a class name.
- Click OK. When you return to the Trust and key managers panel, the new custom trust manager displays in the Additional ordered trust managers field. Use the left and right list boxes to add and remove custom trust managers.
- Select a key manager for the SSL configuration.
By default, IbmX509 is the only key manager unless you create a custom key manager.
If you choose to implement your own key manager, you can affect the alias selection behavior because the key manager is responsible for selecting the certificate alias from the keystore. The custom key manager might not interpret the SSL configuration as the WAS key manager IbmX509 does.
To define a custom key manager, click...
Security | Secure communications | SSL configurations | SSL_configuration | Trust and key managers | Key managers | New
- Click OK to save the trust and key manager settings and return to the new SSL configuration panel.
- Click Save to save the new SSL configuration.
Results
We can override the default trust manager when you configure at least one custom trust manager and set the com.ibm.ssl.skipDefaultTrustManagerWhenCustomDefined property to true. Click Custom Property on the SSL configuration panel. However, if you change the default, you leave all the trust decisions to the custom trust manager, which is not recommended for production environments. In test environments, use a dummy trust manager to avoid certificate validation. Remember that these environment are not secure.
What to do next
In this release of WAS, you can associate SSL configurations with protocols using one of the following methods:
- Set the SSL configuration on the thread programmatically
- Associate the SSL configuration with an outbound protocol, and target host and port.
- Associate the SSL configuration directly using the alias.
- Manage the SSL configurations centrally by associating them with SSL configuration groups or zones that are scoped for endpoints.
Related
SSL certificate and key management
SSL configurations for selected scopes
SSL configurations collection
SSL configuration settings
Certificate authority (CA) client configuration
Certificate authority (CA) client configuration collections
Create a chained personal certificate in SSL
Recover deleted certificates in SSL
Renewing a certificate in SSL
Revoke a CA certificate in SSL
Use a CA client to create a personal certificate to be used as the default personal certificate
Create a CA certificate in SSL
Develop the WSPKIClient interface for communicating with a certificate authority
Create a custom trust manager configuration for SSL
Create a custom key manager for SSL
Associate an SSL configuration dynamically with an outbound protocol and remote secure endpoint
SSL client certificate authentication
Quality of protection (QoP) settings
ssl.client.props client configuration file
Automate SSL configurations using scripting
SSLConfigCommands command group