The Secure Sockets Layer (SSL) protocol provides transport layer security including authenticity, data signing, and data encryption to ensure a secure connection between a client and server that uses WebSphere Application Server. The foundation technology for SSL is public key cryptography, which guarantees that when an entity encrypts data using its public key, only entities with the corresponding private key can decrypt that data.
WebSphere Application Server uses Java Secure Sockets Extension (JSSE) as the SSL implementation for secure connections. JSSE is part of the Java 2 Standard Edition (J2SE) specification and is included in the IBM implementation of the Java Runtime Extension (JRE). JSSE handles the handshake negotiation and protection capabilities that are provided by SSL to ensure secure connectivity exists across most protocols. JSSE relies on X.509 certificate-based asymmetric key pairs for secure connection protection and some data encryption. Key pairs effectively encrypt session-based secret keys that encrypt larger blocks of data. The SSL implementation manages the X.509 certificates.
Secure communications for WebSphere Application Server require digitally-signed X.509 certificates. The contents of an X.509 certificate, such as its distinguished name and expiration, are either signed by a certificate authority (CA) or are self-signed. When a trusted CA signs an X.509 certificate, WebSphere Application Server identifies the certificate and freely distributes it. A certificate must be signed by a CA because the certificate represents the identity of an entity to the general public. Server-side ports that accept connections from the general public must use CA-signed certificates. Most clients or browsers already have the signer certificate that can validate the X.509 certificate so signer exchange is not necessary for a successful connection.
You can trust the identity of a self-signed X.509 certificate only when a peer in a controlled environment, such as internal network communications, accepts the signer certificate. To complete a trusted handshake, you must first send a copy of the entity certificate to every peer that connects to the entity. Self-signed certificates are less expensive than CA-signed certificates because they do not require signer exchange for a secure connection.
CA and self-signed X.509 certificates reside in Java keystores. JSSE provides a reference to the keystore in which a certificate resides. You can select from many types of keystores, including Java Cryptographic Extension (JCE)-based and hardware-based keystores. Typically, each JSSE configuration has two Java keystore references: a keystore and a truststore. The keystore reference represents a Java keystore object that holds personal certificates. The truststore reference represents a Java keystore object that holds signer certificates.
A personal certificate without a private key is an X.509 certificate that represents the entity that owns it during a handshake. Personal certificates contain both public and private keys. A signer certificate is an X.509 certificate that represents a peer entity or itself. Signer certificates contain just the public key and verify the signature of the identity that is received during a peer-to-peer handshake.
For more information, see Extracting a signer certificate from a personal certificate
For more information about keystores, see Keystore configurations.
When you configure an SSL connection, you can exchange signers to establish trust in a personal certificate for a specific entity. Signer exchange enables you to extract the X.509 certificate from the peer keystore and add it into the truststore of another entity so that the two peer entities can connect. The signer certificate also can originate from a CA as a root signer certificate or an intermediate signer certificate. You can also extract a signer certificate directly from a self-signed certificate, which is the X.509 certificate with the public key.
In this example, the truststore for Entity A contains three signers. Entity A can connect to any peer as long as one of the three signers validates its personal certificate. For example, Entity A can connect to Entity B or Entity C because the signers can trust both signed personal certificates. The truststore for Entity-B contains one signer. Entity B is able to connect to Entity C only, and only when the peer endpoint is using certificate Entity-C Cert 1 as its identity. The ports that use the other personal certificate for Entity C are not trusted by Entity B. Entity C can connect to Entity A only.
In the example, the self-signed configuration seems to represent a one-to-one relationship between the signer and the certificate. However, when a CA signs a certificate, it typically signs many at a time. The advantage of using a single CA signer is that it can validate personal certificates that are generated by the CA for use by peers. However, if the signer is a public CA, you must be aware that the signed certificates might have been generated for another company other than your target entity. For your internal communications, private CAs and self-signed certificates are preferable to public CAs because they enable you to isolate the connections that you want to occur and prevent those that you do not want to occur.
In previous releases of WebSphere Application Server, you can reference an SSL configuration only by selecting the SSL configuration alias directly. Each secure endpoint was denoted by an alias attribute that references a valid SSL configuration within a repertoire of SSL configurations. When you made a single configuration change, you had to re-configure many alias references across the various processes. Although the current release still supports direct selection, this approach is no longer recommended.
The current release provides improved capabilities for managing SSL configurations and more flexibility when you select SSL configurations. In this release, you can select from the following approaches: Dynamic outbound selection of Secure
Sockets Layer configurations is based on connection information being
available for the server so that 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 being setup when SSL properties are retrieved
similar to what is described in Programmatically specifying an outbound SSL configuration using JSSEHelper API.
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.
The API ultimately then calls one of the createSocket() methods in
com.ibm.websphere.ssl.protocol.SSLSocketFactory to complete the process.
gotcha: 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.
By default, WebSphere Application Server creates a unique self-signed certificate for each node. WebSphere Application Server no longer relies on the default or dummy certificate that is shipped with the product. The key.p12 default keystore and the trust.p12 truststore are stored in the configuration repository within the node directory.
All of the nodes put their signer certificates 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, which is 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 and a truststore with the name suffix DefaultTrustStore. These default suffixes instruct the WebSphere Application Server runtime to add the signer of the personal certificate to the common truststore. If a keystore name does not end with DefaultKeyStore, the keystore signer certificates are not added to the common truststore when you federate the server. You can change the default SSL configuration, but you must ensure that the correct trust is established for administrative connections, among others.
For more information, see Default self-signed certificate configuration and Web server plug-in default configuration.
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.
With built-in certificate management, you can replace a 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.