+

Search Tips   |   Advanced Search

SSL configurations

SSL configurations contain attributes that enable control of the behavior for both client and server SSL endpoints. We can assign SSL configurations to have specific management scopes. The scope an SSL configuration inherits depends upon whether we create it using a cell, node, server, or endpoint link in the configuration topology.

When we create an SSL configuration, we can set the following SSL connection attributes:

We can manage an SSL configuration using any of the following methods:

Using the administrative console, we can manage all of the SSL configurations for WebSphere Application Server. From the administrative console, click...

We can view an SSL configuration at the level it was created and in the inherited scope below that point in the topology. If we want the entire cell to view an SSL configuration, create the configuration at the cell level in the topology.


SSL configuration in the security.xml file

The attributes defining an SSL configuration repertoire entry for a specific management scope are stored in the security.xml file. The scope determines the point at which other levels in the cell topology can see the configuration, as shown in the following example:

The SSL configuration attributes from the previous code sample are described in Table 1.

security.xml attribute Description Default Associated SSL property
xmi:id Unique identifier for this XML entry and determines how the SSL configuration is linked to other XML objects, such as SSLConfigGroup. This system-defined value must be unique. The administrative configuration service defines the default value. None. This value is used only for XML associations.
alias Name of the SSL configuration. Direct selection uses the alias attribute and the node is not prefixed to the alias. Rather, the management scope takes care of ensuring that the name is unique within the scope. CellDefaultSSLSettings com.ibm.ssl.alias
managementScope Management scope for the SSL configuration and determines the visibility of the SSL configuration at runtime. Cell.

The managementScope attribute is not mapped to an SSL property. However, it confirms whether or not the SSL configuration is associated with a process.
type Defines the JSSE or SSL configuration option. JSSE is the SSL configuration type for most secure communications within WAS.

(ZOS) Both JSSE and SSSL are valid options. The z/OS daemon still uses SSSL in this release.

JSSE com.ibm.ssl.sslType
clientAuthentication Whether SSL client authentication is required. false com.ibm.ssl.clientAuthentication
clientAuthenticationSupported Whether SSL client authentication is supported. The client does not have to supply a client certificate if it does not have a client certificate.

When we set the clientAuthentication attribute to true, we override the value set for the clientAuthenticationSupported attribute.

false com.ibm.ssl.client.AuthenticationSupported
securityLevel Cipher suite group. Valid values include STRONG (128-bit ciphers), MEDIUM (40-bit ciphers), WEAK (for all ciphers without encryption), and CUSTOM (if the cipher suite group is customized. When we set the enabledCiphers attribute with a specific list of ciphers, the system ignores this attribute. STRONG com.ibm.ssl.securityLevel
enabledCiphers Specify a unique list of cipher suites. Separate each cipher suite in the list with a space. securityLevel attribute for cipher suite selection. com.ibm.ssl.enabledCipherSuites
jsseProvider JSSE provider IBMJSSE2 com.ibm.ssl.contextProvider
sslProtocol SSL handshake protocol. Valid options include:

  • SSL_TLS - which is SSLv3 and TLSv1
  • SSL - which is SSLv3
  • SSLv2
  • SSLv3
  • TLS - which is TLSv1
  • TLSv1
  • SSL_TLSv2 - which is SSLv3 and TLSv1, TLSv1.1, TLSv1.2
  • TLSv1.1
  • TLSv1.2

The listSSLProtocols command provides more information about which protocol are valid in particular configurations, such as FIPS 140-2 or SP800-131.

SSL_TLSv2 com.ibm.ssl.protocol
keyStore Keystore and attributes of the keyStore instance that the SSL configuration uses for key selection. CellDefaultKeyStore See Keystore configurations.
trustStore Key store that the SSL configuration uses for certificate signing verification. CellDefaultTrustStore A trustStore is a logical JSSE term. It signifies a key store containing signer certificates. Signer certificates validate certificates sent to WAS during an SSL handshake.
keyManager Key manager that WAS uses to select keys from a key store. A JSSE key manager controls the javax.net.ssl.X509KeyManager interface. A custom key manager controls the javax.net.ssl.X509KeyManager and the com.ibm.wsspi.ssl.KeyManagerExtendedInfo interfaces. The com.ibm.wsspi.ssl.KeyManagerExtendedInfo interface provides more information from WAS. IbmX509 com.ibm.ssl.keyManager defines a well-known key manager and accepts the algorithm and algorithm|provider formats, for example IbmX509 and IbmX509|IBMJSSE2. com.ibm.ssl.customKeyManager defines a custom key manager and takes precedence over the other keyManager properties. This class must implement javax.net.ssl.X509KeyManager and can implement com.ibm.wsspi.ssl.KeyManagerExtendedInfo. See was1140.html
trustManager Which trust manager or list of trust managers to use for determining whether to trust the peer side of the connection. A JSSE trust manager implements the javax.net.ssl.X509TrustManager interface. A custom trust manager might also implement com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface to get more information from the WAS environment. The default is IbmPKIX, which can be configured for certificate revocation list (CRL) verification when the certificate contains a CRL distribution point. The other option is IbmX509. com.ibm.ssl.trustManager defines a well-known trust manager, which is required for most handshake situations. com.ibm.ssl.trustManager performs certificate expiration checking and signature validation. We can define com.ibm.ssl.customTrustManagers with additional custom trust managers that are called during an SSL handshake. Separate additional trust managers with the vertical bar (|) character. See was1141.html

Elliptical curve ciphers are enabled by default when using the securityLevel attributes for ciphers. If they are not desired they can be disabled either using a custom cipher list with the enabledCiphers attribute or set the security custom property com.ibm.websphere.ssl.include.ECCiphers to false so they do not show when securityLevel is used.

WebSphere does not allow the RC4 cipher suites in the HIGH cipher list to keep the server more secure by default. It is possible an RC4 cipher was being used by default in SSL handshakes before this change. With the removal of the RC4 ciphers, it is likely an AES cipher is used instead. Users can experience a decrease in performance with the use of more secure AES ciphers.

Client SSL configurations are managed for each profile using using...

Specifying any javax.net.ssl system properties will override the corresponding property in the ssl.client.props file.


Subtopics


  • Create a Secure Sockets Layer configuration
  • Configure Federal Information Processing Standard Java Secure Socket Extension files