WAS v8.5 > Script the application serving environment (wsadmin) > Scripting for security > Configure security with scripting > Secure communications using wsadmin Create an SSL configuration at the node scope using scripting
A Secure Socket Layer (SSL) configuration references many other configuration objects. To help 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 AdminTask.
Before starting this task, wsadmin must be running. See the Starting the wsadmin scripting client article for more information.
The security.xml file is restricted. To make changes to the security.xml file, verify the user ID has administrator role authorization. For a user ID with operator role authorization, we can perform a node synchronization, but any changes made to the security.xml file are not synchronized. To use the information in this task effectively, familiarize yourself with the instructions in the Creating an SSL configuration topic.
Perform the following task to create an Secure Socket Layer (SSL) configuration at the node scope:
- 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, to see which management scopes have already been defined. If the one we need does not exist you 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 that we can use. To create a different scope, use the createManagementScope command of AdminTask 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.
Jacl:
$AdminTask listKeyStores -all true
Jython:
AdminTask.listKeyStores('-all true')
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)
- 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.
Jacl:
$AdminTask createSSLConfig -interactive
Jython:
AdminTask.createSSLConfig ('[-interactive]')
Example output:
Create a 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 }
- Save the configuration changes. See the Saving configuration changes with the wsadmin article for more information.
Results
The name of the SSL configuration object 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>
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:
- Set the SSL configuration on the thread programmatically.
- Associate the SSL configuration with an outbound protocol or a target host and port.
- Directly associating the SSL configuration using the alias.
- Centrally managing the SSL configurations by associating them with SSL configuration groups or zones so they are used based upon the group from where the end point exists.
Related concepts:
SSL configurations Dynamic outbound selection of Secure Sockets Layer configurations Central management of SSL configurations
Related
Create an SSL configuration Start the wsadmin scripting client using wsadmin.sh Save configuration changes with wsadmin txml_sync