+

Search Tips   |   Advanced Search

Create an SSL configuration at the node scope using scripting

A Secure Socket Layer (SSL) configuration references many other configuration objects. To help we make valid selections for the new SSL configuration before we create it, view information about existing configuration objects. Information about existing objects is also useful when we create a node scoped SSL configuration using the createSSLConfig command of the AdminTask object.

See the Starting the wsadmin scripting client article for more information.

The security.xml file is restricted. Therefore, to make changes to the security.xml file, verify that your user ID has administrator role authorization. If we are using a user ID with operator role authorization, we can perform a node synchronization, but any changes that made to the security.xml file are not synchronized.

To use the information in this task effectively, familiarize ourself with the instructions in the Creating a Secure Sockets Layer configuration topic.

Perform the following task to create an Secure Socket Layer (SSL) configuration at the node scope:


Tasks

  1. List the existing configuration objects. Perform any of the following:

    • List some of the configuration objects that you may need when we create a new SSL configuration.

      For example, we want to see which management scopes have already been defined. If the one we need does not exist we will need to create it.

      • Jacl:

        $AdminTask listManagementScopes {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02}
      • Jython: 
        AdminTask.listManagementScopes ('[-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02]')

      This shows an existing cell scope and existing node scope we can use. To create a different scope, use the createManagementScope command of the AdminTask object to define a different one. The valid scope parameters are cell, nodegroup, node, server, cluster, and endpoint. See the Central management of SSL configurations article for more information on scope limitations.

    • List the key stores that exist in the configuration including key stores and trust stores.

      Example output: 

      CellDefaultKeyStore(cells/BIRKT40Cell02|security.xml#KeyStore_1)
CellDefaultTrustStore(cells/BIRKT40Cell02|security.xml#KeyStore_2)
CellLTPAKeys(cells/BIRKT40Cell02|security.xml#KeyStore_3)

      The previous example only lists the key stores for the default management scope which is also known as the cell scope. To obtain key stores for other scopes, specify the scopeName parameter, for example:

      • Jacl:

        $AdminTask listKeyStores {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 }
      • Jython: 
        $AdminTask listKeyStores ('[-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02]')

      Example output: 

      CellDefaultKeyStore(cells/BIRKT40Cell02|security.xml#KeyStore_1)
CellDefaultTrustStore(cells/BIRKT40Cell02|security.xml#KeyStore_2)
CellLTPAKeys(cells/BIRKT40Cell02|security.xml#KeyStore_3)
NodeDefaultKeyStore(cells/BIRKT40Cell02|security.xml#KeyStore_1134610924357)
NodeDefaultTrustStore(cells/BIRKT40Cell02|security.xml#KeyStore_1134610924377)
    • List specific trust or key managers. Be sure to display the object name for the trust managers. You will need the object name for the SSL configuration because we can specify multiple trust manager instances.

      • Jacl:

        $AdminTask listTrustManagers {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 -displayObjectName true }
      • Jython: 
        AdminTask.listTrustManagers ('[-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 -displayObjectName true]')

      Example output: 

      IbmX509(cells/BIRKT40Cell02|security.xml#TrustManager_1)
IbmPKIX(cells/BIRKT40Cell02|security.xml#TrustManager_2)
IbmX509(cells/BIRKT40Cell02|security.xml#TrustManager_1134610924357)
IbmPKIX(cells/BIRKT40Cell02|security.xml#TrustManager_1134610924377)

  2. Create the node-scoped SSL configuration in interactive mode. Now that we have the information we need to choose from, we need to decide if these objects are sufficient or if we need to create new ones. For now, we will reuse what we've already got in the configuration and save creating new instances to task documents specific to those objects.

    Example output: 

    Create an SSL Configuration.

*SSL Configuration Alias (alias): BIRKT40Node02SSLConfig
Management Scope Name (scopeName): (cell):BIRKT40Cell02:(node):BIRKT40Node02
Client Key Alias (clientKeyAlias): default Server Key Alias (serverKeyAlias): default SSL Type (type): [JSSE]
Client Authentication (clientAuthentication): [false]
Security Level of the SSL Configuration (securityLevel): [HIGH]
Enabled Ciphers SSL Configuration (enabledCiphers):
JSSE Provider (jsseProvider): [IBMJSSE2]
Client Authentication Support (clientAuthenticationSupported): [false]
SSL Protocol (sslProtocol): [SSL_TLS]
Trust Manager Object Names (trustManagerObjectNames): (cells/BIRKT40Cell02|security.xml#TrustManager_1)
*Trust Store Name (trustStoreName): NodeDefaultTrustStore
Trust Store Scope (trustStoreScopeName): (cell):BIRKT40Cell02:(node):BIRKT40Node02
*Key Store Name (keyStoreName): NodeDefaultKeyStore
Key Store Scope Name (keyStoreScopeName): (cell):BIRKT40Cell02:(node):BIRKT40Node02
Key Manager Name (keyManagerName): IbmX509
Key Manager Scope Name (keyManagerScopeName): (cell):BIRKT40Cell02:(node):BIRKT40Node02

Create SSL Configuration

F (Finish)
C (Cancel)

Select [F, C]: [F] F
WASX7278I: Generated command line: $AdminTask createSSLConfig {-alias BIRKT40Node02SSLConfig -scopeName 
(cell):BIRKT40Cell02:(node):BIRKT40Node02 -clientKeyAlias default -serverKeyAlias default 
-trustManagerObjectNames (cells/BIRKT40Cell02|security.xml#TrustManager_1) -trustStoreName 
NodeDefaultTrustStore -trustStoreScopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 -keyStoreName 
NodeDefaultKeyStore -keyStoreScopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 -keyManagerName 
IbmX509 -keyManagerScopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 }

  3. Save the configuration changes. See the Saving configuration changes with the wsadmin article for more information.
  4. In a network deployment environment only, synchronize the node. See the Synchronize nodes with the wsadmin tool article for more information.

The name of the SSL configuration object that we created, for example, (cells/BIRKT40Cell02|security.xml#SSLConfig_1136652770753), appears in the security.xml file.

Example security.xml file output: 

<repertoire xmi:id="SSLConfig_1136652770753" alias="BIRKT40Node02SSLConfig" type="JSSE" 
managementScope="ManagementScope_1134610924357">
<setting xmi:id="SecureSocketLayer_1136652770924" clientKeyAlias="default" serverKeyAlias="default" 
clientAuthentication="false" securityLevel="HIGH"  jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" 
keyStore="KeyStore_1134610924357" trustStore="KeyStore_1134610924377" trustManager="TrustManager_1" 
keyManager="KeyManager_1134610924357"/>
</repertoire>


What to do next

Once we create the SSL configuration object, the next step is to use it. There are several different ways that we can associate SSL configurations with protocols, for example:


Related:

  • SSL configurations
  • Dynamic outbound selection of Secure Sockets Layer configurations
  • Central management of SSL configurations
  • Create a Secure Sockets Layer configuration
  • Start the wsadmin scripting client
  • Save wsadmin configuration changes
  • Synchronize nodes