WAS v8.5 > Secure applications > Secure communications > Secure communications using SSL
Secure Sockets Layer node, application server, and cluster isolation
To isolate a node, application server, or cluster, review signers contained in your SSL configuration's truststores. If the client does not contain the server signer, it cannot establish a connection to the server.
By default, WebSphere uses chained certificates, and each node has a unique root certificate signer. All servers in the node can connect to each other because they share the same root signer.
Authenticating only the server-side of a connection is not adequate protection when we need to 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 the server can control its connections by deciding which client certificates it can trust.
Isolation also requires that we 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 you 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, your configuration applies to the application server and individual end point scopes following the node scope. For more information, see...
- Associate Secure Sockets Layer configurations centrally with inbound and outbound scopes
- Select an SSL configuration alias directly from an endpoint configuration
- Associate an SSL configuration dynamically with an outbound protocol and remote secure endpoint
When you configure the key stores, you must 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 containing 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 application server, then store that keystore on the application server in the application server directory.
When you configure the trust stores, which control trust decisions on the server, you must consider how much to isolate the application servers. We cannot isolate the application servers from the node agents or the deployment manager. However, we 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 application servers always connect to the node agents when the server starts, the IIOP protocol requires that WAS establish trust between the application servers and the node agents.
Establish node SSL isolation
By default, WAS installation uses a single chained certificate for each node so we can isolate nodes are. A common trust store, 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.
We can modify the default configuration so that each node has its own trust store, and every application server 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 WAS can establish trust with the deployment manager. To isolate the node, ensure 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 application servers
- The application servers 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.
When 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 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 Associate Secure Sockets Layer configurations centrally with inbound and outbound scopes.
Establish application server SSL isolation
Isolating application server processes from one another is more challenging than isolating nodes. You must consider the following application design and topology conditions:
- An application server process might need to communicate with the node agent and deployment manager
- Isolating application server processes from each other might disable single sign-on capabilities for horizontal propagation
If you configure outbound SSL configurations dynamically, we can accommodate these conditions. When you define a specific outbound protocol, target host, and port for each different SSL configuration, we can override the scoped configuration.
Figure 2 shows how you might isolate an application server completely, although in practice this approach would be more complicated.
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 Associate an SSL configuration dynamically with an outbound protocol and remote secure endpoint
Establish cluster SSL isolation
We can configure application servers 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, application servers outside of the cluster cannot communicate with the cluster, thus isolating the clustered servers. For example, we might need to separate applications from different departments while maintaining a basic level of trust among the clustered servers. Using the dynamic outbound SSL configuration method previously described for servers, we 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 located in the config/cells/cellname/clusters/<clustername> directory.
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 containing 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 application server 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.
Although this article presents an overview of isolation methods from an SSL perspective, you must also ensure that non-SSL ports are closed or applications require the confidentiality constraint in the deployment descriptor. For example, we 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 application server or a Java client. WAS must know the clients to determine if SSL client authentication enablement is possible. Any applications 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 you must consider to achieve complete isolation.
Related concepts:
Dynamic outbound selection of Secure Sockets Layer configurations
Central management of SSL configurations
Associate Secure Sockets Layer configurations centrally with inbound and outbound scopes
Select an SSL configuration alias directly from an endpoint configuration
Associate an SSL configuration dynamically with an outbound protocol and remote secure endpoint