Secure Sockets Layer (SSL) configurations contain the attributes
that you need to control the behavior of client and server SSL endpoints.
You create SSL configurations with unique names within specific management
scopes on the inbound and outbound tree in the configuration topology.
This task shows you how to define SSL configurations, including quality
of protection and trust and key manager settings.
Before you begin
You must decide at which scope you need to 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.
You must also decide which scope to associate with the new SSL configuration, according to
the
Avoid trouble: The security.xml file is restricted.
Therefore, if you need to make changes to the security.xml file, verify
that your user ID has administrator role authorization. If you are
using a user ID with operator role authorization, you can perform
a node synchronization, but any changes that you made to the security.xml
file are not synchronized.
About this task
You can create an SSL configuration with the administrative console or with the createSSLConfig wsadmin command.
This task describes how to create an SSL configuration with the administrative console.
Procedure
- Click
- Select an SSL configuration link on either the Inbound
or Outbound tree, depending on the process you are configuring.
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
you might need an SSL configuration for a connection to a particular SSL host and port. For more
information, see Dynamic outbound
selection of Secure Sockets Layer configurations.
If the scope is already associated with
a configuration and alias, the SSL configuration alias and certificate alias are noted in
parentheses.
- If the parenthetical information is not included, then the
scope is not associated. Instead, 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.
- Click SSL configurations.
You can view and select any
of the SSL configurations that are configured at this scope. You can also view and select these
configuration at every scope that is lower on the topology.
- Click New to display the SSL configuration panel.
You cannot select links for Additional Properties until you
type a configuration name and click Apply.
- 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.
- 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 new truststore, which is a keystore
whose role is to establish trust during the connection.
- 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 WebSphere® Application
Server uses to encrypt and sign data.
- If you change the keystore name, click Get certificate
aliases to refresh the list of certificates from which you can
choose a default alias. WebSphere Application Server
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 new keystore.
- Choose a default server certificate alias for inbound connections.
Select the default only when you 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. If you want to change the scope, you must
click a different link in the topology tree and continue at Step 3.
- Click Apply if you intend to configure Additional
Properties. If not, go to Step 24.
- 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.
- Select a client authentication setting to establish an
SSL configuration for inbound connections and for clients to send
their certificates, if appropriate.
- If you select None, the server does not request that a client send a
certificate during the handshake.
- If you 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 you 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 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 one or more protocols for the SSL handshake.
By default, the product uses a single SSL handshake protocol, SSL_TLSv2
. With
SSL_TLSv2
, connections can accept the TLSv1
,
TLSv1.1
, TLSv1.2
, TLSv1.3
protocols. The
SSL_TLSv2
protocol supports all handshake protocols except for
SSLv2
on the server side. You can change the default from
SSL_TLSv2
to a different single protocol or to a customized list of protocols.
- To specify a single protocol, click Predefined protocols and select an
SSL protocol from the Select protocol list.
In
version 8.5.5.21, the name of this setting changed from Protocol to
Predefined protocols.
Some single SSL protocol values represent
multiple SSL configurations. For example, SSL_TLSv2
allows the
TLSv1
, TLSv1.1
, and TLSv1.2
protocols to be
used.
- To specify a custom list of multiple SSL protocols, click
Custom protocol list, select protocols from the list, and click
Add. The custom protocol list shows up in the security configuration as a
comma-separated list.
You can select from the following protocols:
SSL_TLSv2
, the default protocol, supports client protocols
TLSv1
and SSLv3
.
TLSv1
supports TLS
and TLSv1
. The SSL server
connection must support this protocol for the handshake to proceed.
SSLv2
SSLv3
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
-
TLSv1.3
Important:
- Do not use the SSLv2 protocol for the SSL server connection. Use it only when necessary on the
client side.
- For V8.5.5.20 only, the following information applies: TLSv1.3 appears in the list of selectable
protocols when your application server id running on a JVM where the TLSv1.3 protocol is supported.
The TLSv1.3 protocol is not included with any other protocol at this time. If you are using TLSv1.3,
that is the only protocol that is accepted.
TLSv1.3
is supported on AIX®, Windows, and Linux®. For Solaris,
where your application server id is running on a JVM, the TLSv1.3
protocol is NOT
supported.
- Select a JSSE provider.
- A predefined Java™ Secure Socket Extension (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.
- Select from among the following cipher suite groups.
- Strong: WebSphere Application Server 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: WebSphere Application Server can perform 40-bit encryption algorithms for
encryption and support integrity signing algorithms.
- Weak: WebSphere Application Server 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: you can select specific ciphers. Any time you change the
ciphers that are listed from a specific cipher suite group, the group name changes to Custom.
- Click Update selected ciphers to view a list of
the available ciphers for each cipher strength.
- Click OK to return to the new SSL configuration
panel.
- Click Trust and key managers.
- Select a default trust manager for the primary SSL handshake
trust decision.
- Choose IbmPKIX when you require certificate revocation
list (CRL) checking using CRL distribution points in the certificates
or the online certificate status protocol (OCSP).
- Choose IbmX509 when you do not require CRL checking
but do need increased performance. You can configure a custom trust
manager to perform CRL checking, if necessary.
- Define a custom trust manager, if appropriate.
You
can define a custom trust manager that runs with the default trust
manager you 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.
- 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 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.
Important: 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 WebSphere Application Server
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
Important: You 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 WebSphere Application Server,
you can associate SSL configurations with protocols using one of the
following methods: