Secure Sockets Layer node, application server, and cluster isolation
SSL enables us to ensure any client that attempts to connect to a server during the handshake first performs server authentication. Using SSL configurations at the node, application server, and cluster scopes, we can isolate communication between servers that should not be allowed to communicate with each other over secure ports.
To isolate a node, application server, or cluster, control the signers contained in the truststores associated with the SSL configuration. When 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. Because the node shares the same root signer, all of the servers in that node can connect to each other because they share the same root signer. However, if we use self-signed certificates, the server that created the personal certificate controls the signer, although we do have to manage the self-signed certificates. If we obtain certificates from a certificate authority (CA), we must 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 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 that the server can control its connections by deciding which client certificates it can trust. See: Enable Secure Sockets Layer client authentication for a specific inbound endpoint.
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 allow us to create SSL configurations, key stores, and trust stores at a particular scope. Because of the inheritance hierarchy of WAS cells, if we select only the properties needed for an SSL configuration, only these properties are defined at your selected scope or lower. For example, if we configure at the node scope, the configuration applies to the application server and individual end point scopes following the node scope. See:
- Associate SSL 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 we configure the key stores, which contain cryptographic keys, we must work at the same scope at which we define the SSL configuration and not at a higher scope. For example, if we 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 we decide to create a certificate for the application server, then store that keystore on the application server in the application server directory.
When we configure the trust stores, which control trust decisions on the server, consider how much we want 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 easily. 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. We 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 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 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.
Figure 1.
When we 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 we 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. See Associate SSL 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.
- 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 we configure outbound SSL configurations dynamically, we can accommodate these conditions. When defining a specific outbound protocol, target host, and port for each different SSL configuration, we can override the scoped configuration.
Figure 2 shows how we might isolate an application server 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,*. 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 that is located in...
- config/cells/<cellname>/clusters/<clustername>
Figure 3.
In the example, cluster1 might contain web applications, and cluster2 might contain EJB applications. Considering the various protocols, we 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
We 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.
See Associate an SSL configuration dynamically with an outbound protocol and remote secure endpoint .
Although an overview of isolation methods from an SSL perspective is presented, we 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 topic to describe all of the factors consider to achieve complete isolation.
Related: