A Secure Socket Layer (SSL) configuration references many
other configuration objects. To help you make valid selections for
the new SSL configuration before you create it, view information about
existing configuration objects. Information about existing objects
is also useful when you create a node scoped SSL configuration using
the createSSLConfig command of the AdminTask object.
Before you begin
Before starting this task, the wsadmin tool must be running.
See the Starting the wsadmin scripting client article for more information.
Evitar Problemas: The security.xml file is restricted.
Therefore, if you need to make changes to the security.xml file, verify
that your user ID has administrator role authorization. If you are
using a user ID with operator role authorization, you can perform
a node synchronization, but any changes that you made to the security.xml
file are not synchronized.
gotcha
About this task
To use the information in this task effectively, familiarize
yourself 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:
Procedure
- List the existing configuration objects. Perform any of
the following:
- List some of the configuration objects that you may need when
you create a new SSL configuration.
For example, you want to see
which management scopes have already been defined. If the one you
need does not exist you will need to create it.
Using Jacl:
$AdminTask listManagementScopes {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02}
Using Jython:
AdminTask.listManagementScopes ('[-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02]')
This shows an existing cell scope and existing node scope that
you can use. If you want 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.
Using Jacl:
$AdminTask listKeyStores -all true
Using 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:
Using Jacl:
$AdminTask listKeyStores {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 }
Using 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 you can specify multiple trust manager
instances.
Using Jacl:
$AdminTask listTrustManagers {-scopeName (cell):BIRKT40Cell02:(node):BIRKT40Node02 -displayObjectName true }
Using 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.
Using Jacl:
$AdminTask createSSLConfig -interactive
Using 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.
- In a network deployment
environment only, synchronize the node. See the Synchronizing nodes
with the wsadmin tool article for more information.
Results
The name of the SSL configuration object that you 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 you create the SSL configuration object, the next step
is to use it. There are several different ways that you 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 that they are used based
upon the group from where the end point exists.