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.
WebSphere Application Server ships Java SE7. By default Java SE 7 enables Server Name Indication (SNI). SNI is an extension to the TLS protocol. SNI allows a client to specify the hostname it is attempting to connect to. Exceptions are thrown if the certificate returned does not match the expected hostname.
In some proxy environments this will cause errors. The client is expecting to receive the proxy's certificate, but instead receives the certificate of endpoint server.
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), signed by a root certificate in NodeDefaultRootStore or DmgrDefaultRootStore, 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 within 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.
CA, chained, 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 Adding the correct SSL Signer certificates to the plug-in keystore
For more information about keystores, see Keystore configurations for SSL.
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 a chained certificate's 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 chained certificate for each node. The chained certificate is signed with a root, a self-signed certificate stored in the DmgrDefaultRootStore or NodeDefaultRootStore. WebSphere Application Server no longer relies on a self-signed certificate or 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. The default root certificate is stored in the root-key.p12 in the configuration repository under the node directory.
All of the nodes put their signer certificates from the default root certificate 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, a truststore with the name suffix DefaultTrustStore and a rootstore with the name suffix DefaultRootStore. These default suffixes instruct the WebSphere Application Server runtime to add the root signer of the personal certificate to the common truststore. If a truststore name does not end with DefaultKeyStore, the keystores root 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 chained certificate configuration in SSL and Web server plug-in default configuration in SSL.
Certificate monitoring ensures that the default chained certificate for each node is not allowed to expire. The certificate expiration monitoring function issues a warning before certificates and signers are set to expire. Those certificates and signers that are located in keystores managed by the WebSphere Application Server configuration can be monitored. You can configure the expiration monitor to automatically replace a certificate. A chained certificate will be recreated based on the same data used for the initial creation and sign it with the same root certificate that signed the original certificate. A self-signed certificate or chained certificate is also recreated based upon the same data that is used for the initial creation.
The monitor also can automatically replace old signers with the signers from the new chained or self-signed certificates in keystores that are managed by WebSphere Application Server. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved. For more information, see Certificate expiration monitoring in SSL.
The expiration monitor is configured to replace chained personal certificates that are signed by a root certificate in DmgrDefaultRootStore or NodeDefaultRootStore. The certificate is renewed using the same root certificate that was used to sign the original certificate.
The monitor also can automatically replace old signers with the signers from the new self-signed certificates in keystores that are managed by WebSphere Application Server. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved. For more information, see Certificate expiration monitoring in SSL.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 chained or 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.