Secure Sockets Layer node, appserver, and cluster isolation

Secure Sockets Layer node, appserver, and cluster isolation

SSL enables you to ensure that any client that attempts to connect to a server during the handshake first performs server authentication. You can isolate communications between servers that must not communicate with each other over secure ports using SSL configurations at the node, appserver, and cluster scopes.
Before you attempt to isolate communications controlled by WebSphere Application Server, have a good understanding of the deployment topology and application environment. To isolate a node, appserver, or cluster, be able to control the signers that are contained in the trust stores that are associated with the SSL configuration. When the client does not contain the server signer, it cannot establish a connection to the server. If you use self-signed certificates, the server that created the personal certificate controls the signer, although you do have to manage the self-signed certificates. If you obtain certificates from a certificate authority (CA), obtain multiple CA signers because all of the servers can connect to each other if they share the same signer.
Authenticating only the server-side of a connection is not adequate protection when isolate a server. Any client can obtain a signer certificate for the server and add it to its trust store. SSL client authentication must also be enabled between servers so that the server can control its connections by deciding which client certificates it can trust. For more information, see Enabling Secure Sockets Layer client authentication for a specific inbound endpoint, which applies as well to enabling SSL client authentication at the cell level.
Isolation also requires that you use centrally managed SSL configurations for all or most endpoints in the cell. Centrally managed configurations can be scoped, unlike direct or end point configuration selection, and they enable you to create SSL configurations, key stores, and trust stores at a particular scope. Because of the inheritance hierarchy of WAS cells, if you select only the properties that we need for an SSL configuration, only these properties are defined at your selected scope or lower. For example, if you configure at the node scope, the configuration applies to the appserver and individual end point scopes below the node scope. For more information, see Associating Secure Sockets Layer configurations centrally with inbound and outbound scopes, Selecting an SSL configuration alias directly from an endpoint configuration, and Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint
When you configure the key stores, which contain cryptographic keys, work at the same scope at which you define the SSL configuration and not at a higher scope. For example, if you create a key store that contains a certificate whose host name is part of the distinguished name (DN), then store that keystore in the node directory of the configuration repository. If you decide to create a certificate for the appserver, then store that keystore on the appserver in the appserver directory.
When you configure the trust stores, which control trust decisions on the server, consider how much you want to isolate the appservers. You cannot isolate the appservers from the node agents or the deployment manager. However, you can configure the SOAP connector end points with the same personal certificate or to share trust. Naming persistence requires IIOP connections when they pass through the deployment manager. Because appservers always connect to the node agents when the server starts, the IIOP protocol requires that WAS establish trust between the appservers and the node agents.

Establishing node SSL isolation

By default, WebSphere Application Server uses a single self-signed certificate for each node so you can isolate nodes easily. A common trust store, which is located in the cell directory of the configuration repository, contains all of the signers for each node that is federated into the cell. After federation, each cell process trusts all of the other cell processes because every SSL configuration references the common trust store. You can modify the default configuration so that each node has its own trust store, and every appserver on the node trusts only the node agent that uses the same personal certificate. You must also add the signer to the node trust store so that WebSphere Application Server can establish trust with the deployment manager. To isolate the node, ensure that the following conditions are met:

The deployment manager must initiate connections to any process

The node agent must initiate connections to the deployment manager and its own appservers

The appservers must initiate connections to the applications servers on the same node, to its own node agent, and the deployment manager

Figure 1 shows Node Agent A contains a key.p12 keystore and a trust.p12 trust store at the node level of the configuration repository for node A. Figure 1.

When you associate an SSL configuration with this keystore and truststore, you break the link with the cell-scoped trust store. To isolate the node completely, repeat this process for each node in the cell. WAS SSL configurations override the cell scope and use the node scope instead so that each process at this scope uses the SSL configuration and certificate alias that you selected at this scope. You establish proper administrative trust by ensuring that nodeA signer is in the common trust store and the cell signer is in the nodeA trust store. The same logic applies to node B as well. For more information, see Associating Secure Sockets Layer configurations centrally with inbound and outbound scopes.

Establishing appserver SSL isolation
Isolating appserver processes from one another is more challenging than isolating nodes. You must consider the following application design and topology conditions:

An appserver process might need to communicate with the node agent and deployment manager

Isolating appserver processes from each other might disable single sign-on capabilities for horizontal propagation

If you configure outbound SSL configurations dynamically, you can accommodate these conditions. When you define a specific outbound protocol, target host, and port for each different SSL configuration, you can override the scoped configuration. Figure 2 shows how you might isolate an appserver completely, although in practice this approach would be more complicated. Figure 2.

The dynamic configuration enables server1 on Node A to communicate with server 1 on Node B only over IIOP. The dynamic outbound rule is IIOP,nodeBhostname,*. For more information, see Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint

Establishing cluster SSL isolation

You can configure appservers into clusters instead of scoping them centrally at the node or dynamically at the server to establish cluster SSL isolation. While clustered servers can communicate with each other, appservers outside of the cluster cannot communicate with the cluster, thus isolating the clustered servers. For example, you might need to separate applications from different departments while maintaining a basic level of trust among the clustered servers.
Use the dynamic outbound SSL configuration method described for servers above, you can extend the isolated cluster as needed. Figure 3 shows a sample cluster configuration where cluster 1 contains a key.p12 with its own self-signed certificate, and a trust.p12 that is located in the config/cells/<cellname>/clusters/<clustername> directory.Figure 3.
In the example, cluster1 might contain web applications, and cluster2 might contain EJB applications. Considering the various protocols, you decide to enable IIOP traffic between the two clusters. Your task is to define a dynamic outbound SSL configuration at the cluster1 scope with the following properties:
IIOP,nodeAhostname,9403|IIOP,nodeAhostname,9404|IIOP,nodeBhostname,9403|IIOP,nodeBhostname,9404
You must create another SSL configuration at the cluster1 scope that contains a new trust.p12 file with the cluster2 signer. Consequently, outbound IIOP requests go either to nodeAhostname ports 9403 and 9404 or to nodeBhostname ports 9403 and 9404. The IIOP SSL port numbers on these two appserver processes in cluster2 identify the ports. As you review Figure 3, notice the following features of the cluster isolation configuration:

The trust.p12 for cluster1 contains signers that allow communications with itself (cluster1 signer), between both node agents (nodeAsigner and nodeBsigner), and with the deployment manager (cell signer).

The trust.p12 for cluster2 contains signers that allow communications with itself (cluster2 signer), between both node agents (nodeAsigner and nodeBsigner), and with the deployment manager (cell signer).

Node agent A and Node agent B can communicate with themselves, the deployment manager, and both clusters.

For more information, see Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint .
Although this article presents an overview of isolation methods from an SSL perspective, also ensure that non-SSL ports are closed or applications require the confidentiality constraint in the deployment descriptor. For example, you can set the CSIv2 inbound transport panel to require SSL and disable the channel ports that are not secure from the server ports configuration.
Also, enable SSL client authentication for SSL to enforce the isolation requirements on both sides of a connection. Without mutual SSL client authentication, a client can obtain a signer for the server programmatically and thus bypass the goal of isolation. With SSL client authentication, the server would require the client's signer for the connection to succeed. For HTTP/S protocol, the client is typically a browser, a Web Service, or a URL connection. For the IIOP/S protocol, the client is typically another appserver or a Java client. WebSphere Application Server must know the clients to determine if SSL client authentication enablement is possible. Any applications that are available through a public protocol must not enable SSL client authentication because the client may fail to obtain a certificate to authenticate to the server.
It is beyond the scope of this article to describe all of the factors consider to achieve complete isolation.

Related concepts

Dynamic outbound selection of Secure Sockets Layer configurations
Central management of Secure Sockets Layer configurations

Related tasks

Associating Secure Sockets Layer configurations centrally with inbound and outbound scopes
Selecting an SSL configuration alias directly from an endpoint configuration
Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint