Central management of Secure Sockets Layer configurations
By default, SSL configurations for servers are managed from a central location in the topology view in the console. You can associate an SSL configuration and certificate alias with a management scope. This method is the most efficient method to manipulate and modify configurations when the server topology changes.
In prior releases, SSL configurations are managed in the server.xml file for each process. You have to edit individual server.xml documents to modify individual SSL configuration aliases in the configuration topology. In this release of WAS, management control of SSL configurations offers more flexibility and options. You can make coarse-grained changes using the cell-scope and fine-grained changes using a particular endpoint name, as defined in the serverindex.xml file for a specific appserver process.
Because SSL configuration associations manifest inheritance behaviors, you can simplify the number of associations by referencing only the highest level management scope that needs a unique configuration. Obviously, the security environment influences issues such as SSL configuration uniqueness, and SSL configuration and certificate alias placement in the topology.
To configure the inbound and outbound topologies, which must be done separately in the console, click Security > SSL certificates and key management > Manage endpoint security configurations > Inbound | Outbound.
The topology view provides the scoping mechanism. The SSL configuration inherits its visibility, which is its display in the topology, at the scope where you created the configuration and at all the scopes beneath this parent scope. When you create an SSL configuration at a specific node, the configuration can be seen by that node agent and by every appserver that is part of that node. Any appserver or node that is not part of this particular node cannot see this SSL configuration. You can configure different certificate aliases and SSL configurations for inbound versus outbound connections.
Default centrally managed SSL configuration
While it is easier to manage SSL configurations centrally in the topology view of the console, you can also use wsadmin scripting within AdminTasks. You can manage SSL configuration associations in the configuration element of the security.xml file. The sslConfigGroup configuration object is the mechanism that is used to associate a connection direction and management scope with a specific SSL configuration and certificate alias. The default sslConfigGroups cell attribute has a predefined inbound and outbound cell-scoped configuration that each endpoint in the cell inherits. Because rules of precedence must guide you when you select SSL configurations, see Secure communications using Secure Sockets Layer before you modify the configurations.
<sslConfigGroups xmi:id="SSLConfigGroup_1" name="myhostCell01" direction="inbound" certificateAlias="default" sslConfig="SSLConfig_1" managementScope="ManagementScope_1"/> <sslConfigGroups xmi:id="SSLConfigGroup_2" name="myhostCell01" direction="outbound" certificateAlias="default" sslConfig="SSLConfig_1" managementScope="ManagementScope_1"/> <managementScopes xmi:id="ManagementScope_1" scopeName="(cell):myhostCell01" scopeType="cell"/>In the previous sample code, the sslConfigGroups attribute references the cell management scope. For this example, the following list shows the precedence order for selecting management scopes, from the highest order of precedence to the lowest. Each time an endpoint scope is defined, it uses the specified SSL configuration and certificate alias.
- Endpoint scope
- Cluster scope
- Server scope
- Node scope
- Nodegroup scope
- Cell scope
For more information on configuring management scopes, see Associating Secure Sockets Layer configurations centrally with inbound and outbound scopes, Associating a Secure Sockets Layer configuration dynamically with an outbound protocol and remote secure endpoint , and Selecting an SSL configuration alias directly from an endpoint configuration.
Related concepts
Secure communications using Secure Sockets Layer