Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure communications > Secure communications using SSL

Secure Sockets Layer node, application server, and cluster isolation

Secure Sockets Layer (SSL) enables you to ensure that 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, you can isolate communication between severs that should not be allowed to communicate with each other over secure ports.

Before you attempt to isolate communications controlled by WAS, have a good understanding of the deployment topology and application environment.

To isolate a node, application server, or cluster, you must be able to control the signers that are contained in the truststores that are 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 they the node shares the same root signer, all of the server in that node can connect to each other because they share the same root signer. However, 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.

Authenticate 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. See Enable SSL 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 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, the configuration applies to the application server and individual end point scopes below the node scope. See Associate SSL configurations centrally with inbound and outbound scopes, Select an SSL configuration alias directly from an endpoint configuration, and Associate an SSL 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 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, consider how much to isolate the application servers. We cannot isolate the application servers from the node agents or the dmgr. 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 dmgr. 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.

Establishing node SSL isolation

By default, WAS installation uses a single chained 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.

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 dmgr. To isolate the node, ensure that the following conditions are met:

• The dmgr must initiate connections to any process
• The node agent must initiate connections to the dmgr 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 dmgr

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. See Associate SSL configurations centrally with inbound and outbound scopes.

Establishing application server SSL isolation

Isolating application server processes from one another is more challenging than isolating nodes. We must consider the following application design and topology conditions:

• An application server process might need to communicate with the node agent and dmgr
• Isolating application server 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 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

Establishing 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, you 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 described for servers above, you can easily 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. self-signed certificate, and a trust.p12 that is located in the config/cells/ <cellname>/clusters/ <clustername>" />

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 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 dmgr (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 dmgr (cell signer).
• Node agent A and Node agent B can communicate with themselves, the dmgr, and both clusters.

For more information, see Associate an SSL 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 easily 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 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.
Dynamic outbound selection of SSL configurations
Central management of SSL configurations
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

+

Search Tips   |   Advanced Search