Create a Secure Sockets Layer configuration

SSL configurations contain the attributes needed to control the behavior of client and server SSL endpoints. Create SSL configurations with unique names within specific management scopes on the inbound and outbound tree in the configuration topology. This task shows how to define SSL configurations, including quality of protection and trust and key manager settings.

Decide at which scope we 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 defining 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, according to the processes that the configuration affects. For example, an SSL configuration for a hardware cryptographic device might require a keystore that is available only on a specific node, or we might need an SSL configuration for a connection to a particular SSL host and port.

The security.xml file is restricted. To make changes, verify that the user ID has administrator role authorization. If we are using a user ID with operator role authorization, we can perform a node synchronization, but any changes that made to the security.xml file are not synchronized.

Tasks

1. Click...
   Security > SSL certificate and key management > Manage endpoint security configurations

2. Select an SSL configuration link on either the Inbound or Outbound tree, depending on the process we are configuring.

   • Existing SSL configuration and certificate aliases are noted in parentheses.

   • If parenthetical SSL configuration and certificate alias information is not included, then the scope is not associated, and the scope inherits the configuration properties of the first scope above it that is associated with an SSL configuration and certificate alias. The cell scope must be associated with an SSL configuration because it is at the top of the topology and represents the default SSL configuration for the inbound or outbound connection.

3. Click SSL configurations.

   We can view and select any of the SSL configurations configured at this scope. We can also view and select these configuration at every scope that is lower on the topology.

4. Click New to display the SSL configuration panel.

   We cannot select links for Additional Properties until you type a configuration name and click Apply.

5. Type an SSL configuration name.

   This field is required. The configuration name is the SSL configuration alias. Make the alias name unique within the list of SSL configuration aliases that are already created at the selected scope. The new SSL configuration uses this alias for other configuration tasks.

6. Select a truststore name from the drop-down list.

   A truststore name refers to a specific truststore that holds signer certificates that validate the trust of certificates sent by remote connections during an SSL handshake. If there is no truststore in the list, create a keystore configuration for a preexisting keystore file to create a new truststore, which is a keystore whose role is to establish trust during the connection.

7. Select a keystore name from the drop-down list.

   A keystore contains the personal certificates that represent a signer identity and the private key that WAS uses to encrypt and sign data.

   • If we change the keystore name, click Get certificate aliases to refresh the list of certificates from which we can choose a default alias.

     WAS uses a server alias for inbound connections and a client alias for outbound connections.

   • If there is no keystore in the list, see create a keystore configuration for a preexisting keystore file to create a new keystore.

8. 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.

9. Choose a default client certificate alias for outbound connections.

   Select the default only when the server SSL configuration specifies an SSL client authentication.

10. Review the identified management scope for the SSL configuration.

    Make the management scope in this field identical to the link we selected in Step 2. To change the scope, click a different link in the topology tree and continue at Step 3.

11. Click Apply if we intend to configure Additional Properties.

    If not, go to Step 24.

12. Click Quality of protection (QoP) settings.

    QoP settings define the strength of the SSL encryption, the integrity of the signer, and the authenticity of the certificate.

13. Select a client authentication setting to establish an SSL configuration for inbound connections and for clients to send their certificates, if appropriate.

    • If we select None, the server does not request that a client send a certificate during the handshake.

    • If we select Supported, the server requests that a client send a certificate. However, if the client does not have a certificate, the handshake might still succeed.

    • If we select Required, the server requests that a client send a certificate.

      However, if the client does not have a certificate, the handshake fails.

    Important: The signer certificate that represents the client must be in the truststore that we select for the SSL configuration. By default, servers within the same cell trust each other because they use the common truststore, trust.p12, located in the cell directory of the configuration repository. However, if we use keystores and truststores that we create, perform a signer exchange before we select either Supported or Required.

14. Select a protocol for the SSL handshake.

    • The default protocol, SSL_TLS, supports client protocols TLSv1 and SSLv3.

    • The TLSv1 protocol supports TLS and TLSv1. The SSL server connection must support this protocol for the handshake to proceed.
    • SSLv2
    • SSLv3

    • The SSLv3 protocol supports SSL and SSLv3. The SSL server connection must support this protocol for the handshake to proceed.
    • TLS is TLSv1
    • TLSv1
    • SSL_TLSv2 is SSLv3 and TLSv1, TLSv1.1, TLSv1.2
    • TLSv1.1
    • TLSv1.2

    Important: Do not use the SSLv2 protocol for the SSL server connection. Use it only when necessary on the client side.

15. Select one of the following options:

    • A predefined JSSE provider.

      The IBMJSSE2 provider is recommended for use on all platforms which support it. It is required for use by the channel framework SSL channel. When Federal Information Processing Standard (FIPS) is enabled, IBMJSSE2 is used in combination with the IBMJCEFIPS crypto provider.

    • A custom JSSE provider. Type a provider name in the Custom provider field.

16. Select from among the following cipher suite groups:

    • Strong: WAS can perform 128-bit confidentiality algorithms for encryption and support integrity signing algorithms. However, 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 can support integrity signing algorithms but not to perform encryption. Select this option with care because passwords and other sensitive information that cross the network are visible to an Internet Protocol (IP) sniffer.

    • Custom: we can select specific ciphers. Any time we change the ciphers listed from a specific cipher suite group, the group name changes to Custom.

17. Click Update selected ciphers to view a list of the available ciphers for each cipher strength.

18. Click OK to return to the new SSL configuration panel.

19. Click Trust and key managers.

20. Select a default trust manager for the primary SSL handshake trust decision.

    • Choose IbmPKIX when we require certificate revocation list (CRL) checking using CRL distribution points in the certificates or the online certificate status protocol (OCSP).

    • Choose IbmX509 when we do not require CRL checking but do need increased performance. We can configure a custom trust manager to perform CRL checking, if necessary.

21. Define a custom trust manager, if appropriate.

    We can define a custom trust manager that runs with the default trust manager we select. The custom trust manager must implement the JSSE javax.net.ssl.X509TrustManager interface and, optionally, the com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface to obtain product-specific information.

    1. Click...
       Security | SSL certificate and key management | Manage endpoint security configurations | SSL_configuration | Trust and key managers | Trust managers | New

    2. Type a unique trust manager name.

    3. Select the Custom option.

    4. Type a class name.

    5. Click OK. When we return to the Trust and key managers panel, the new custom trust manager displays in the Additional ordered trust managers field. Use the list boxes to add and remove custom trust managers.

22. Select a key manager for the SSL configuration. By default, IbmX509 is the only key manager unless we create a custom key manager.

    If we choose to implement our own key manager, we 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

    

23. Click OK to save the trust and key manager settings and return to the new SSL configuration panel.

24. Click Save to save the new SSL configuration.

Important: We can override the default trust manager when we 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 we 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, we 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

Subtopics

• SSL certificate and key management
  
• SSL configurations for selected scopes
  
• SSL configurations collection
  
• SSL configuration settings
  
• Secure Sockets Layer client certificate authentication
  
• Certificate authority (CA) client configuration
  
• Certificate authority (CA) client configuration collections
  

• Writable SAF Keyring settings
  
• Create a chained personal certificate in SSL
  
• Recovering deleted certificates in SSL
  
• Renewing a certificate in SSL
  
• Revoking 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
  
• Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint
  
• Quality of protection (QoP) settings
  
• ssl.client.props client configuration file
  

Automating SSL configurations using scripting

SSLConfigCommands